A Camada Ausente: Estruturando Agentes de IA para Hierarquias Organizacionais

Um modelo de referência para como as organizações estruturam seu trabalho com IA

Jose Martinez · 1 de outubro de 2026 · v1.8.1 (medido no Claude Code; revisado com base na documentação da Anthropic em 1 de outubro de 2026)

Em cinco linhas.

1. Organizações são árvores: empresa, linha de atuação, projeto, tarefa. Os projetos do Claude são planos: o chat tem um único bloco de organização de 3.000 caracteres, os projetos no chat e no Cowork não se aninham nem herdam configurações e, dentro de um projeto, uma conta de conector pertence a uma pessoa ou à organização inteira, nunca a um ramo.

1. Por isso, cada projeto recebe uma cópia manual das regras da sua linha de atuação, essas cópias divergem com o tempo e ninguém consegue ver qual regra gerou determinada resposta.

1. A Anthropic já construiu essa árvore duas vezes. O Claude Code aninha instruções por pasta e, desde 1 de outubro de 2026, executa os mods da organização antes dos de uma pessoa. O Claude Tag, no Slack, herda instruções e credenciais da organização para o workspace e depois para o canal. Nenhuma das duas chega ao projeto. O mesmo modelo pode chegar: uma camada de linha de atuação, projetos nascidos de suas pastas, tarefas tipadas, um compilador que rejeita conflitos antes que o modelo os veja e permissões por nó que funcionem no plano Team.

1. Eu medi isso no Claude Code, duas vezes. Uma regra da organização e uma regra de projeto que discordavam entre si, em níveis separados de CLAUDE.md e nenhuma marcada como obrigatória: a regra do projeto venceu 20 de 20 vezes. A mesma regra da organização marcada como imposta, apenas por palavras: venceu 20 de 20. A precedência foi definida pela redação, que qualquer pessoa editando qualquer camada pode alterar, e não pela estrutura.

1. Isso já funciona hoje. Um aplicativo desktop que eu criei roda o Claude Code dentro da árvore. Ele monta cada camada como um CLAUDE.md, limita o Claude ao que a pessoa pode fazer naquele nó, rejeita o conflito no momento em que é escrito e registra cada resposta com suas regras, seus tokens e seu revisor. Nas medições, a árvore carregou de 20% a 34% menos tokens de instrução do que as cópias planas.

Organizações são árvores. A empresa define a política, a linha de atuação estabelece seus padrões, o projeto os aplica a um trabalho específico e a tarefa entrega uma coisa concreta. Todo sistema de qualidade em que já trabalhei é construído assim, e o mesmo vale para a árvore de pastas em quase todo servidor de arquivos corporativo: empresa, linha de atuação, ano e, então, uma pasta por trabalho, nomeada por um número de job que codifica tudo isso.

Projetos de IA são planos. Uso o Claude como exemplo porque é o produto com o qual trabalho todos os dias e porque ele já entrega a solução em duas de suas próprias interfaces. No chat do Claude, os projetos não podem ser aninhados, e as instruções da organização são um único bloco de até 3.000 caracteres que se aplica a todos. No plano Enterprise, administradores podem definir o escopo de permissões por grupo. No Team, as funções se aplicam à organização inteira. Nada documentado no chat ou no Cowork leva instruções até um departamento ou linha de atuação e, dali, para seus projetos. No Enterprise, habilidades e projetos podem ser compartilhados com um grupo, mas isso é distribuição, não herança.

Essa é a camada que falta: aquela entre a organização e o projeto. Este artigo explica o que está faltando, por que isso importa, quanto realmente custa e apresenta um modelo de referência que qualquer plataforma poderia implementar, incluindo suas permissões e sua estrutura de dados.

1. O que existe hoje

Verificado na documentação da Anthropic entre 29 de setembro e 1 de outubro de 2026. O Claude tem quatro interfaces onde o trabalho de uma equipe acontece, e cada uma possui seu próprio modelo de instruções:

As permissões dependem do plano:

A Anthropic construiu metade da árvore para permissões. No Enterprise, funções personalizadas são atribuídas a grupos; "funções personalizadas também controlam quais conectores e quais ferramentas nesses conectores uma função pode usar"; em toda a plataforma, nos níveis de organização, função e usuário, "o nível mais restritivo vence", enquanto as várias funções de um membro se somam; administradores podem "Visualizar função efetiva", com um rótulo "Concedido por"; e grupos podem ter seus próprios limites de gastos. Mas esses são grupos planos, não uma árvore, e nada disso chega às instruções. O mais próximo disso são os plugins: no Enterprise, um proprietário pode tornar um plugin e suas habilidades obrigatórios ou instalados por padrão para um grupo, com uma ordem declarada ("configuração do grupo, depois configuração geral da organização, depois padrão do marketplace"). Isso mira em um grupo de pessoas, não em um projeto, nada é herdado entre projetos e uma habilidade ainda só carrega quando o Claude a julga relevante. O Team tem funções para a organização inteira e compartilhamento pessoa a pessoa; suas configurações de plugin têm, nas palavras da documentação, "nenhuma configuração de grupo". E o Team é justamente o plano feito para empresas de pequeno e médio porte.

A Anthropic construiu a árvore inteira duas vezes, fora dos projetos.

No Claude Code, por pasta. O Claude Code carrega arquivos CLAUDE.md de quatro níveis; "todos os arquivos descobertos são concatenados no contexto em vez de substituírem uns aos outros", ordenados "da raiz do sistema de arquivos até o seu diretório de trabalho", e os arquivos em subdiretórios "carregam sob demanda". O bloco de uma organização pode chegar como um arquivo gerenciado em cada máquina ou como texto vindo do console de administração (a chave claudeMd). A documentação é franca sobre o limite: o Claude trata esses arquivos "como contexto, não como configuração imposta" e "se duas instruções se contradisserem, o Claude poderá escolher uma arbitrariamente."

No Claude Tag, por canal do Slack. O Claude Tag é o Claude dentro do Slack de uma equipe, em beta público nos planos Team e Enterprise. Suas configurações se vinculam a um escopo, e "um escopo é onde um pacote se aplica: acesso padrão ao Slack (a raiz de toda a organização), um workspace ou um único canal." Três coisas que o restante deste artigo pede já estão lá:

• Instruções são herdadas. "Instruções personalizadas por escopo são concatenadas: primeiro o acesso padrão ao Slack, depois o workspace e, por fim, o canal. As instruções de um canal se somam, em vez de substituir, ao que foi definido acima dele."

• Credenciais pertencem ao ramo. Nos canais, o Claude age com contas de serviço que um administrador vincula a um escopo, e "a credencial do escopo mais restrito é usada: o canal supera o workspace, que supera o acesso padrão ao Slack."

• Você pode ver de onde veio o acesso. Cada linha de conector, repositório e plugin diz "Herdado de" um escopo mais amplo ou "Vinculado de" um pacote. Os gastos têm limite para a organização e por canal, e são reportados por canal.

Os limites também estão documentados. A árvore tem o formato do Slack: três níveis fixos, e os canais do Slack não se aninham. As instruções são "orientações, não uma trava imposta", e a documentação não descreve nenhuma verificação de conflitos entre escopos. Não há "registro por ação de cada tarefa e de quem a solicitou". E ela para na borda de um projeto: "Projetos no claude.ai não se aplicam aqui; o Claude não lê as instruções ou o conhecimento de um Projeto no Slack, e um canal não pode ser direcionado a um Projeto."

O que mudou em 1 de outubro de 2026. O Claude Code 2.1.287 ativou os mods, que estavam em acesso antecipado: funções dentro de um plugin que rodam no Claude Code e podem reescrever um prompt ou uma parte do prompt do sistema, bloquear ou reescrever uma chamada de ferramenta, aprovar ou negar uma solicitação de permissão e desenhar painéis na interface. Três coisas sobre eles importam aqui:

• Eles têm uma ordem declarada. Uma proteção nativa e os mods da própria organização rodam primeiro, depois os mods que a pessoa instala. "O primeiro mod é o mais externo: ele vê o evento antes dos outros e o resultado depois deles, e decide se os outros vão rodar ou não." Onde a proteção carrega (uma máquina com configurações gerenciadas ou um login Team ou Enterprise), o mod de uma pessoa não pode alterar "o prompt do sistema, seu CLAUDE.md gerenciado e outras instruções gerenciadas", e não pode aprovar uma chamada de ferramenta que uma regra de negação recusa. Isso é precedência definida por estrutura, que é exatamente o que este artigo pede. É um padrão, não uma trava: quem inicia o Claude Code com --safe-mode roda sem os mods instalados, incluindo os da organização, enquanto hooks gerenciados e regras de negação continuam valendo.

• A ordem tem dois donos. Os mods da organização rodam antes dos da pessoa, ou depois deles, se a organização assim escolher. Não há um nível para linha de atuação. Configurações entregues pelo console de administração "aplicam-se uniformemente a todos os usuários da organização. Configurações por grupo ainda não são suportadas." Uma organização que quer uma política diferente por grupo tem dois caminhos, ambos via TI: implantar um arquivo de configuração distinto nas máquinas de cada grupo ou rodar um gateway auto-hospedado que "entrega configurações gerenciadas por grupo do IdP".

• Eles não chegam ao chat e alcançam o Cowork de forma desigual. "Mods funcionam na CLI do Claude Code e na aba Code do app Claude Desktop." Um mod vem no arquivo hooks/hooks.json de um plugin, e a tabela de suporte a plugins da Anthropic marca esse arquivo como "Ignorado" no chat. A mesma tabela o marca como "Carrega" no Cowork, porque "o Cowork no app Claude Desktop executa suas sessões no Claude Code"; as páginas sobre mods não listam o Cowork, e eu não o testei. O que a organização controla ali é mais frágil: em uma sessão do Cowork, o Claude Code "nunca busca configurações gerenciadas pelo servidor no console de administração do claude.ai, mesmo quando o usuário entra com uma conta Team ou Enterprise", e sessões remotas do Cowork não têm política de dispositivo para ler.

O que está sendo lançado. O Cowork está sendo fundido ao Claude: a central de ajuda agora diz "O Claude Cowork agora é apenas o Claude", primeiro nos planos Pro e Max, enquanto Team e Enterprise "mantêm o chat e o Claude Cowork como são hoje". Em 6 de outubro de 2026, novas tarefas do Cowork no Pro e no Max passam para a nuvem. E uma nova versão de projetos está em beta público no Pro e no Max, começando no Claude Code, com chat, Cowork, Team e Enterprise vindo a seguir; nela, "um projeto é uma conversa" que o Claude divide em threads paralelas. Ainda é um nível único: "Um projeto pertence a um usuário" e "não há controles de nível organizacional para projetos durante o beta."

Portanto, a árvore não é uma ideia nova para a Anthropic. Ela existe por pasta para código e por canal para o Slack e, em ambos, a organização vem primeiro. O lugar onde uma empresa arquiva seu trabalho, o projeto, não tem pai nem uma linha acima dele. Duas outras ofertas da Anthropic apontam na mesma direção e estão fora do escopo deste artigo: o Claude for Government resolve configurações por meio de uma cadeia de tenant, grupo e organização, e o Claude Desktop em provedores terceirizados tem políticas por grupo em beta.

2. Por que isso importa

Projetos não são contêineres. Um trabalho real é um contêiner. Ele tem uma chave (o número do job), um pai (sua linha de atuação), um ciclo de vida (aberto, fechado, arquivado por ano), uma pasta, um cliente, pessoas, regras e entregas. Um projeto do Claude tem um nome em texto livre, nenhuma chave, nenhum pai e nenhum filho, e seu ciclo de vida documentado é arquivar e excluir. O Cowork pode vincular um projeto a uma pasta local, mas só manualmente, um projeto por vez, sem padrão de chave e sem pai. Uma linha de atuação pode abrir centenas de jobs por ano. Isso deixa duas opções ruins: um projeto do Claude feito à mão por job, cada um com sua própria cópia das regras, ou um projeto por linha de atuação, onde o contexto de clientes diferentes fica lado a lado.

O caminho de carga se rompe. Na engenharia estrutural, toda carga precisa de um caminho contínuo até a fundação. Tire um elemento e nada acima dele transfere a força para baixo. Regras se comportam da mesma forma. Quando não há uma camada entre a organização e o projeto, os padrões, modelos e regras de aprovação de uma linha de atuação não têm onde viver. Então cada projeto ganha uma cópia manual.

As cópias divergem. Corrija uma regra em um projeto e os outros mantêm a versão antiga. Cada projeto continua passando na sua própria verificação local. A incompatibilidade só aparece quando alguém compara projetos lado a lado e, em trabalhos regulamentados, geralmente é um auditor. Equipes de infraestrutura conhecem bem essa falha. Na pesquisa de 2026 da Firefly, cerca de um terço dos respondentes associou o desvio de configuração (configuration drift) a incidentes caros em produção, e cerca de um em cada cinco não tinha processo para detectá-lo ou corrigi-lo.

A identidade também é plana. Muitas pessoas trabalham em mais de uma organização, e cada uma precisa de seu próprio contexto isolado. Dentro de qualquer uma delas, no chat e no Cowork, uma conta de conector pertence a uma pessoa, não a um ramo. Funções do Enterprise podem decidir quais conectores um grupo pode usar, e um administrador pode autorizar um conector uma única vez para a organização inteira; um conector personalizado pode até carregar uma credencial compartilhada para todos (em beta). De qualquer forma, a conta é da pessoa ou da organização, nunca de um ramo: um consultor que atende dois clientes não pode vincular o Drive de cada cliente aos projetos daquele cliente. Projetos compartilhados tornam isso mais evidente: "Conectores só estão disponíveis em projetos privados." O Claude Tag mostra que o outro design é possível, com uma conta de serviço vinculada a um canal do Slack, e mostra onde ele para: no projeto. A página do conector do Google da Anthropic descreve uma única conta do Google conectada, e a forma documentada de alterá-la é desconectar e reconectar; três issues abertas (abaixo) pedem mais de uma conta. A fronteira vive na cabeça da pessoa, que é exatamente o tipo de limite manual que falha silenciosamente.

Ninguém consegue ver qual regra foi aplicada. O Claude Enterprise mostra aos administradores uma opção "Visualizar função efetiva" para permissões, e o comando /context do Claude Code lista quais arquivos de memória foram carregados. Um mod do Claude Code agora pode desenhar seu próprio painel, então uma visualização de instruções efetivas é algo que qualquer um pode construir ali. O Claude Tag rotula cada conector e repositório com o escopo do qual foi herdado, mas, para instruções, sua documentação diz para "pedir ao Claude que repita suas instruções de administrador". Nenhuma interface mostra, para uma dada resposta, qual instrução veio de qual camada. Sem procedência, não há trilha de auditoria e, sem trilha de auditoria, não há sistema de qualidade.

As pessoas estão pedindo partes disso. Issues abertas no rastreador público da Anthropic (github.com/anthropics/claude-code), verificadas em 01-10-2026:

Uma sétima, #47741, pedia um CLAUDE.md gerenciado pela organização e foi fechada porque o Claude Code já tem um. Esse é o ponto: as camadas existem no Code e no Slack, e as issues as pedem onde os projetos estão.

3. Quanto custa e o que o token esconde

3.1 Tokens não são a barreira

Mais camadas poderiam significar mais contexto a cada mensagem, e a IA é cobrada por token. Essa explicação só está parcialmente correta. Nos planos Enterprise baseados em uso, o consumo é cobrado pelas tarifas da API, então mais contexto significa mais receita, não menos. No Team, as licenças têm valor fixo, a menos que o uso extra seja ativado, e tokens extras aparecem como membros atingindo seu limite semanal mais cedo. E o Claude Code, cobrado pelos mesmos tokens, já entrega uma cascata de quatro níveis. Se os tokens fossem a barreira, ela não existiria. Medido na seção 3.2, o próprio prompt de sistema e as ferramentas do Claude Code somaram cerca de 30.200 tokens antes de qualquer instrução nossa; as instruções completas de um projeto adicionaram de 3,5% a 5,2% a isso.

3.2 Um exemplo prático

Tags em cada imagem: REAL = medido ou verificado na documentação da Anthropic entre 29 de setembro e 1 de outubro de 2026; EST = simulado; IND = ilustrativo.

Primeiro, as medições. Fiz a mesma pergunta no Claude Code (claude -p, Claude Sonnet 5.5) contra um projeto de demonstração, cinco vezes por condição, e peguei os tokens de entrada que o próprio Claude Code reportou. Rodei no Claude Code 2.1.286 em 30 de setembro e de novo no 2.1.287 em 1 de outubro; as contagens de instruções foram idênticas. Subtraindo uma execução sem nenhuma instrução de projeto, sobra o custo de cada layout:

Duas coisas que a simulação abaixo não conseguiu mostrar. A cascata custa 224 tokens a mais do que o arquivo compilado para as mesmas regras: cada arquivo extra traz overhead, aqui o marcador e o cabeçalho do próprio aplicativo no arquivo de cada nível, mais o enquadramento que o Claude Code faz em torno de cada arquivo que carrega. Mais níveis significam mais overhead. E o Claude Code realmente carregou de 21% a 26% a mais do que o tokenizer público estimou, mesmo multiplicando por 1,30; parte dessa diferença é o mesmo overhead por arquivo. Proporções sobrevivem a isso; valores absolutos em dólares, não, então leia os dólares da simulação como estimativas para baixo.

Depois, simulado na escala de uma empresa. Simulei um mês de tokens de instrução para uma empresa ilustrativa: 40 pessoas em três linhas de atuação, 250 projetos ativos, seis tipos de relatório por linha, 35 mensagens por pessoa por dia útil em sessões de cinco, totalizando 29.400 mensagens. Os tamanhos em tokens foram contados em textos de instrução de amostra com o tokenizer legado público da Anthropic (que a própria Anthropic chama de "uma aproximação muito grosseira" para o Claude 3 em diante) e escalonados em 1,30 para o tokenizer do Claude 4.7+. O bloco da organização é extrapolado de uma amostra de 597 caracteres para o teto de 3.000 caracteres, e o manual da linha é três vezes uma amostra de 953 caracteres. Os preços são os de tabela do Claude Sonnet 5.5 (entrada US$ 2, gravação em cache de 5 minutos US$ 2,50, leitura de cache US$ 0,20 por milhão de tokens). O cache de prompt dura cinco minutos e é atualizado a cada acerto.

• Plano (a solução alternativa de hoje): o bloco da organização, depois a cópia própria de cada projeto do manual da linha, todos os seis modelos de relatório e as especificidades do projeto.

• Árvore: organização, linha, apenas o modelo de relatório em uso, depois as especificidades do projeto, compilado do mais compartilhado para o menos.

Tamanhos por trás da tabela: bloco da organização 830 tokens (3.000 caracteres), manual da linha 729, um modelo de relatório 147, especificidades do projeto 98 (arredondado; os totais foram calculados antes do arredondamento). A simulação ignora o próprio prompt de sistema do Claude, que vem antes do bloco da organização.

Dois alertas honestos. Primeiro, a árvore não economiza tokens por si só. Os −29% vêm das tarefas tipadas: apenas o modelo do relatório sendo escrito é carregado, não todos os seis. Os −62% vêm principalmente de compilar primeiro as camadas mais compartilhadas, para que centenas de projetos compartilhem um prefixo idêntico byte a byte: só a ordenação, com todos os seis modelos ainda carregados, reduz o custo de cache compartilhado de US$ 36 para US$ 18 (−51%), e as tarefas tipadas acrescentam o resto. Essa segunda economia só existe se o cache for compartilhado entre usuários. Na API do Claude, os caches são isolados entre organizações e, dentro de uma, por workspace, então prefixos idênticos são reutilizados entre requisições dentro de um workspace; para o claude.ai isso não está documentado. Isso não acontece no Claude Code como entregue hoje: lá "o cache é efetivamente limitado a uma máquina e um diretório", então duas pessoas em duas pastas de projeto não aproveitam o cache uma da outra. Leia a última coluna como o que uma camada nativa no chat poderia render, não como algo disponível hoje. Uma objeção justa: Skills já carregam sob demanda, então um workspace plano que mova seus modelos para Skills obtém parte dos −29% hoje. O que falta às Skills no chat e no Cowork é escopo e herança: uma skill não pode pertencer a uma linha e fluir para os projetos daquela linha. (No Claude Code, uma skill em uma subpasta carrega para sessões iniciadas nela ou abaixo dela.) Segundo, estes são apenas tokens de instrução e, nessa escala, variam de US$ 14 a US$ 149 por mês dependendo do cache. Histórico de conversa e output dominam as faturas reais. O argumento forte para a árvore é a precisão e, no Team, a capacidade. Não é a nota fiscal.

A medição acima reproduz o efeito de tarefas tipadas em uma árvore real, no Claude Code, em vez de tamanhos presumidos: −20% como cascata e −34% compilado, contra os −29% da simulação. Uma linha com um único tipo de tarefa não economizaria nada com tarefas tipadas.

3.3 A mesma resposta, do Claude real

Fiz a mesma pergunta ao Claude Code quarenta vezes: dez respostas independentes em cada uma de quatro condições, em dois lotes de cinco com um dia de intervalo. A pergunta era se um teste de densidade de campo no subleito seria aprovado, com 112,3 pcf contra uma densidade seca máxima de 115,8 pcf e exigência de 98%. As instruções eram as seis regras da empresa ou um prompt de uma linha de "assistente prestativo", e o idioma era inglês ou espanhol. Todas as quarenta respostas chegaram ao mesmo veredito: 97,0%, reprovado.

O Claude Code reporta dois números de saída: os tokens cobrados e quantos deles foram raciocínio (thinking) que o leitor nunca vê.

Quatro constatações:

• As regras da empresa tornaram as respostas 1,4 vez mais longas na tela e 1,8 a 1,9 vez mais longas na conta. O extra visível foram as seções de sinalizações, padrões e limitações que as regras pediam. Em um sistema de qualidade, essa é a parte valiosa.

• Sob as regras da empresa, mais de um terço da saída cobrada era invisível. 37% dos tokens de saída cobrados foram raciocínio, contra 16% com o prompt simples. Em inglês, o leitor vê 447 tokens e paga por 711.

• O espanhol custou 1,2 vez os tokens visíveis do inglês para respostas com menos de 4% de diferença no comprimento em palavras. Medida da mesma forma, as regras da empresa consumiram 1,53 vez os tokens de entrada quando escritas em espanhol.

• O mesmo veredito foi cobrado de 317 a 953 tokens, três vezes mais pela resposta mais longa do que pela mais curta. A cobrança por token não distingue rigor de enrolação. Critérios de aceite conseguem.

Essas proporções variam entre lotes de cinco. A proporção na tela para as regras da empresa foi de 1,43–1,52 no primeiro lote e 1,27–1,31 no segundo; a proporção cobrada foi de 1,78–1,82 e depois 1,70–2,05; a proporção do espanhol foi de 1,29–1,38 e depois 1,14–1,18. A direção nunca mudou. O tamanho é confiável com um algarismo significativo.

Método: Claude Code 2.1.286 em 30-09-2026 e 2.1.287 em 01-10-2026, claude -p --output-format json, Claude Sonnet 5.5. Toda ferramenta foi proibida e os arquivos pessoais ~/.claude foram excluídos, então apenas as instruções declaradas diferiram entre as condições. As contagens de tokens são do próprio relatório de uso do Claude Code, incluindo thinking_tokens; o custo mensal aplica os US$ 10 por milhão de tokens de saída do Sonnet 5.5 à média cobrada. O script de medição, ambos os lotes, os números agrupados e todas as respostas estão guardados pelo autor e disponíveis mediante solicitação. A primeira versão deste artigo estimou esses números com subagentes e o tokenizer público; essas estimativas foram substituídas.

3.4 Quando as regras entram em conflito, a redação decide

A documentação da Anthropic admite que instruções contraditórias podem ser resolvidas "arbitrariamente". Testei um conflito do tipo que a ausência de uma camada de linha produz. A regra da organização dizia para usar unidades do sistema americano; uma regra de projeto dizia para reportar densidades no SI. Coloquei-as como uma árvore faria: a regra da organização em um CLAUDE.md na raiz de armazenamento, a regra do projeto em um CLAUDE.md na pasta do projeto, ambas carregadas pela própria cascata do Claude Code. Depois rodei a mesma configuração com a regra da organização marcada como imposta, apenas por palavras: a tag ENFORCED em seu rótulo e uma frase adicionada, "Esta regra é imposta: nenhuma regra de linha ou de projeto pode substituí-la." Cada configuração rodou dez vezes em 30 de setembro e mais dez em 1 de outubro.

Não foi arbitrário. Sem nada declarado, o Claude escolheu a regra mais próxima e específica todas as vezes. Quatorze das vinte respostas explicaram o motivo ("essa regra é mais específica do que a regra geral da empresa para unidades americanas", ou que ela sobrescreve a regra da empresa); cinco citaram apenas a regra do projeto e nunca mencionaram que a regra da empresa discordava. Com a obrigatoriedade declarada em palavras, a regra da organização venceu todas as vezes, e cada resposta disse que a regra imposta da empresa teve precedência. O segundo lote reproduziu as unidades, 10 de 10 em cada caso, e a diferença entre as duas linhas está muito além do acaso (teste exato de Fisher, p < 0,0001). As explicações se sustentaram menos bem: nove de dez respostas disseram por que a regra do projeto venceu no primeiro lote, cinco de dez no segundo.

Isso é uma boa notícia para o modelo e uma má notícia para o workspace. A precedência existe, mas vive na redação das regras, que qualquer pessoa editando qualquer camada pode alterar e que ninguém revisa como uma decisão de precedência. E quando a regra inferior venceu, um quarto das respostas não informou ao leitor que uma regra superior havia sido deixada de lado. Um teste piloto feito na primeira versão deste artigo, com ambas as regras em um único prompt em vez da cascata, também mudou de resultado apenas com a alteração da ordem (regra da organização primeiro: SI 5 de 5; regra da organização por último: SI 2 de 5, e 3 de 5 forneceram ambas as unidades ou perguntaram qual se aplicava).

Nenhum modelo deveria ser solicitado a arbitrar um conflito que a organização poderia ter evitado no momento em que a regra foi escrita. O Claude Code tem duas respostas parciais. O comando /doctor prompt-audit pede ao Claude para procurar arquivos de instrução que se contradizem, quando executado por uma pessoa. E desde 1º de outubro, um mod pode impor uma ordem no código: os mods da organização são executados antes dos de uma pessoa e, onde a proteção integrada é carregada, as regras de negação superam o mod de uma pessoa. Nenhuma das soluções abrange o texto de instrução. Os arquivos de instrução ainda são concatenados, e a documentação descreve o resultado de três maneiras: o Claude “pode escolher um arbitrariamente”; quando uma regra de usuário e uma regra de projeto entram em conflito, “o Claude pode seguir qualquer uma delas”; e “quando as instruções entram em conflito, o Claude usa seu julgamento para reconciliá-las”. O resultado de vinte em vinte foi exatamente a cara desse julgamento aqui. O Claude Tag declara uma ordem para seus três escopos e chama o resultado de “orientação, não um guardrail imposto”. A verificação da implementação de referência rejeita exatamente essa mudança, “R-22 define units.density=SI; R-01 (org:firm) impõe US”, antes que qualquer coisa chegue ao Claude, e enforced é um campo na regra, não uma frase dentro dela.

A densidade de instruções piora tudo. No benchmark IFScale (2025), a precisão do Claude Sonnet 4 caiu de 100% com 10 instruções simultâneas para 42,9% com 500.

3.5 Computação ou energia seriam uma unidade mais justa?

O token é um indicador razoável de computação dentro de um mesmo modelo: mais tokens realmente significam mais trabalho para o hardware. É também por isso que um preço baseado em computação ou energia não resolveria a penalização por idioma. O espanhol custa mais porque o tokenizer o comprime menos, e esses tokens extras representam computação real. A solução para isso é um tokenizer melhor ou uma medição normalizada pelo conteúdo.

Uma unidade de computação normalizada ainda ajudaria de três maneiras. Ela torna diferentes modelos e fornecedores comparáveis. É física e auditável, útil, por exemplo, para relatórios de sustentabilidade. E se o coeficiente for fixado em relação a um hardware de referência, o fornecedor mantém seus próprios ganhos de eficiência, o que gera o incentivo correto. Há precedentes: provedores de nuvem já venderam unidades normalizadas, como a EC2 Compute Unit.

Mas existem problemas reais. O cliente não consegue verificá-la sem um padrão e um auditor. A energia real depende do hardware, da eficiência do data center, do batching e da rede elétrica. E a Anthropic não publica o consumo de energia por requisição; encontrei apenas estimativas de terceiros. Mais importante: a computação continua sendo um insumo. Ela não diz se a resposta estava certa.

Minha conclusão aponta para três camadas separadas:

1. Cobrar em tokens ou em uma unidade de computação normalizada.

1. Divulgar a energia por tarefa e por nó.

1. Gerenciar pelo custo por resultado verificado.

Para o plano Team, o passo mínimo é publicar o limite semanal em uma unidade declarada. A cota por sessão é informada como “1,25x a cota de uso por sessão do plano Pro”; o limite semanal não tem nenhum número publicado. Nenhum dos dois permite planejamento de orçamento.

Como diz a FinOps Foundation, “o token é a unidade de cobrança, não a unidade de valor”. Uma hierarquia é o que torna o valor definível, pois é nela que os critérios de aceitação podem existir.

3.6 Razões mais prováveis para isso não ter sido construído

1. Precedência implícita. A própria documentação da Anthropic admite que instruções diretamente contraditórias podem gerar comportamentos variados, e a seção 3.4 mostra que a precedência segue o que quer que a redação das regras diga. Empilhar camadas multiplica conflitos, e a capacidade de seguir instruções degrada com a densidade: no benchmark IFScale (2025), até os melhores modelos testados alcançaram apenas 68% de precisão com 500 instruções de palavras-chave simultâneas (o benchmark citado na seção 3.4).

1. Herança de permissões. Se o conhecimento herda em uma árvore, o acesso também precisa herdar. Isso significa reconstruir o modelo de permissões sob cada camada.

1. Uma preferência por memória e recuperação em vez de camadas estáticas.

1. Simplicidade focada no consumidor. Ferramentas de código herdam uma árvore gratuitamente do sistema de arquivos. Produtos de chat precisam inventar uma.

A Anthropic não explicou publicamente por que o chat do Claude e o Cowork não têm hierarquia. Tudo nesta seção é uma inferência a partir do que já foi lançado.

4. O modelo de referência

O design empresta conceitos de sistemas que já resolveram esse problema: hierarquias de recursos em nuvem (AWS Organizations, Google Cloud Org Policy, grupos de gerenciamento do Azure), políticas de diretório (Group Policy do Active Directory) e a própria cascata CLAUDE.md do Claude Code. As relações entre nós usam cinco palavras: contém, herda, usa, selado e compartilhado.

4.1 Monte a árvore que a organização já possui

Não faça as pessoas reconstruírem sua organização dentro do workspace de IA. O servidor de arquivos ou o sistema de documentos já é a fonte da verdade. Siga um único caminho:

O número do trabalho 26GT301 já codifica a árvore: ano, linha de trabalho, sequência. O workspace deve montar essa estrutura, não copiá-la.

4.2 Nós portadores de regras, nós de agrupamento, projetos e tarefas

• Nós portadores de regras: organização, linha de trabalho, projeto, tarefa. Cada um carrega as mesmas três coisas: contexto (instruções e conhecimento), política (quais ferramentas, dados e conectores são permitidos) e identidades (as contas de conector vinculadas a ele).

• Nós de agrupamento: série, ano, região. Eles não carregam regras. Existem para navegação, retenção e ciclo de vida. Separá-los mantém a árvore de regras rasa, com três a quatro níveis, como recomenda a própria diretriz da Microsoft para grupos de gerenciamento (“não mais que três a quatro níveis”).

• O projeto é um contêiner chaveado. Ele é criado automaticamente: quando uma pasta correspondente ao padrão de chave da linha aparece (por exemplo {YY}GT{NNN}_{Nome} na raiz da linha), um nó de projeto é criado, herda de sua linha e recebe acesso de conector restrito apenas àquela pasta. Ele guarda somente o que difere de sua linha: membros, cliente, especificações. Ele passa de aberto para fechado e depois para arquivado (Diagrama 2).

• A tarefa é tipada. Seu tipo vem do catálogo da linha (um relatório de densidade, um log de sondagem). O tipo carrega um template e critérios de aceitação. O resultado é arquivado de volta na pasta do projeto seguindo a convenção de nomenclatura da empresa, e um revisor o aceita. As Skills são o que o Claude tem de mais próximo de tipos de tarefa hoje. No plano Enterprise, elas podem ser compartilhadas com um grupo, mas isso é distribuição, não herança: nada flui para baixo em um ramo.

A recursividade é intencional. O Modelo de Sistema Viável de Stafford Beer coloca isso diretamente: “Em uma estrutura organizacional recursiva, qualquer sistema viável contém, e está contido em, um sistema viável.”

4.3 Um pai primário, além de sobreposições

Christopher Alexander argumentou em 1965 que “uma cidade não é uma árvore”. Estruturas reais se sobrepõem. Um cliente, a especificação de uma agência ou um tipo de tarefa pode abranger várias linhas de trabalho. Por isso, todo nó tem um pai primário, e conjuntos de regras transversais se anexam como sobreposições (usa). Os conflitos são resolvidos sempre da mesma forma: a negação vence; caso contrário, o nó mais próximo vence.

4.4 Dois canais, duas semânticas

Este é o núcleo do design, e é onde a maioria das hierarquias erra.

• O contexto concatena. Instruções e conhecimento são mesclados da raiz para baixo, como o CLAUDE.md faz.

• A política é de negação por padrão. Uma ferramenta ou conector só é permitido se houver uma permissão em todo o caminho a partir da raiz, e uma negação explícita em qualquer ponto acima vence, como fazem as Service Control Policies da AWS. Um pai pode marcar uma regra como imposta (enforced), e nenhum filho pode bloqueá-la, como no Group Policy.

Misturar os dois é o erro clássico. Contexto consultivo deve se fundir. Imposição não.

4.5 Compile antes que o modelo leia

Hoje, instruções conflitantes são resolvidas pelo modelo no momento da resposta. A solução é um compilador de instruções efetivas que roda antes de o modelo ver qualquer coisa:

1. Mesclar o contexto da raiz até a folha.

1. Aplicar a política: a negação vence, e uma permissão deve valer em todo o caminho.

1. Respeitar as regras impostas pelos pais.

1. Carimbar cada regra com um ID e sua camada.

1. Ordenar o bloco pelo grau de compartilhamento de cada parte e aplicar um orçamento de tokens por camada.

Os conflitos nunca chegam a esta etapa: eles são rejeitados antes, quando uma regra é escrita, e a aprovação vem de alguém que não seja o autor (Diagrama 3, faixa inferior).

Como os conflitos são resolvidos em tempo de compilação, a saída pode ser ordenada pelo grau de compartilhamento de cada parte, e não estritamente pela profundidade: organização, linha, template do tipo de tarefa e, então, especificidades do projeto. Essa ordem maximiza os acertos de cache (seção 3.2). Ela se alinha aos quatro pontos de interrupção de cache da Anthropic, com um orçamento de tokens por camada, embora na prática um ponto de interrupção possa ser necessário para a própria conversa.

4.6 Identidades vinculadas a ramos, não a pessoas

Uma identidade de conector (conta, tenant, escopo) se anexa a um nó, não a uma pessoa. O Claude Tag já funciona assim para canais do Slack: um administrador vincula uma conta de serviço a um escopo, e a credencial do escopo mais restrito vence. O modelo aqui pede a mesma coisa um nível abaixo, em uma linha de trabalho e seus projetos. Uma pessoa que trabalha em duas organizações tem duas árvores seladas; ela troca de árvore, não de conta. Nada cruza entre elas a menos que os proprietários de ambas compartilhem explicitamente. A primitiva técnica já existe: a especificação de autorização MCP usa tokens OAuth vinculados a audiência (indicadores de recurso RFC 8707, metadados de recurso protegido RFC 9728) e exige que os servidores “NÃO DEVEM aceitar ou transitar quaisquer outros tokens” (versão da especificação 2026-07-28).

4.7 As permissões seguem a árvore

Principais: pessoas, grupos, contas de serviço, convidados externos (por exemplo, um cliente) e o próprio agente.

O agente nunca excede a pessoa ou o nó. O Claude age com as permissões do usuário que o invocou, cruzadas com a política do nó. Ele não pode alterar regras ou permissões; apenas propor mudanças. (Hoje, o Claude pode atualizar sozinho as instruções de pastas do Cowork. Neste modelo, isso vira uma proposta que alguém aprova.)

Avaliação. As concessões fluem apenas para baixo, nunca para cima ou para os lados. A permissão efetiva em um nó é aquilo que as funções em seu caminho concedem, dentro do que a política permite em todo o trajeto, menos qualquer negação acima. Uma sobreposição concede acesso apenas ao seu próprio conteúdo: ler uma especificação não abre os projetos que a utilizam.

Ciclo de vida.

• Aberto: as funções se aplicam conforme concedidas.

• Fechado: nenhuma nova tarefa, mas revisões pendentes podem ser concluídas.

• Arquivado: somente leitura para todos; apenas o proprietário pode restaurar, e a restauração é registrada em log.

• Árvore selada: nada cruza sem um compartilhamento explícito.

Exceções e delegação. Exceções têm prazo definido e justificativa, e alguém diferente do solicitante as aprova. Elas expiram sozinhas e são contabilizadas, porque cada substituição é uma ilha de manutenção permanente; os limites de herança quebrada do SharePoint são o exemplo a não seguir. A delegação nunca pode conceder mais do que o delegador possui. O acesso de emergência (break-glass) do proprietário existe, é sempre registrado em log e revisado posteriormente.

No plano Team, isso funciona sem grupos: a concessão fica no nó, então uma organização com quatro funções ainda obtém permissões por ramo.

4.8 Como as camadas interagem

Uma árvore só vale a pena ser construída se as mudanças viajarem por ela. Três interações carregam a maior parte do trabalho (Diagrama 5):

• Empurrar para baixo. Um líder de linha publica uma nova versão de uma regra. Todo projeto na linha a lê na próxima compilação. Uma exceção aprovada mantém a versão antiga até expirar, e os artefatos já arquivados mantêm a versão com a qual foram criados.

• Puxar para cima. Um membro melhora um template dentro de um projeto e o propõe. O líder da linha, não o proponente, aprova, e os projetos irmãos o herdam. Hoje, essa melhoria fica presa no projeto onde aconteceu.

• Através. A especificação de uma agência muda uma única vez. Projetos em três linhas recompilam com ela, e as próprias linhas não mudam. Um conflito com uma regra de linha é rejeitado no momento em que a atualização é escrita.

Uma única requisição mostra todas as camadas de uma vez (Diagrama 6): a árvore verifica a concessão do membro e o estado do projeto, o compilador monta o bloco, o Claude lê os dados de campo por meio de uma identidade com escopo restrito à pasta daquele projeto, arquiva um artefato tipado de volta na pasta, e um revisor que não o escreveu o aceita. Cada etapa vai para o log, e o custo é debitado na chave do projeto.

4.9 A estrutura de dados

O provisionamento é orientado a eventos: uma nova pasta correspondente a key_pattern sob o storage_root de uma linha cria o nó do projeto. O answer_log fornece a procedência de cada resposta e o custo por nó.

4.10 Meça resultados, não tokens

Cada tipo de tarefa carrega critérios de aceitação: a definição de pronto. Com eles em vigor, uma unidade melhor de trabalho de IA se torna mensurável:

custo por resultado verificado = (custo de tokens + tempo de revisão) ÷ entregas aceitas

Como cada resposta é registrada em um nó, o custo de IA pode ser debitado na chave de um projeto da mesma forma que mão de obra e materiais. Partes disso já existem: o Claude Tag relata e limita gastos por canal, e a telemetria do Claude Code pode ser etiquetada por departamento, centro de custo ou repositório, manualmente. Mas nenhuma é atrelada a um projeto, e nenhuma divide por entregas aceitas. Para uma empresa que fatura por número de trabalho, a IA se torna um custo direto do trabalho, e não despesa indireta. Na engenharia, você paga pela entrega verificada e selada, não pela mina do lápis. O trabalho de IA deveria ser medido da mesma forma.

4.11 Objeções respondidas

“Skills e plugins já fazem isso.” Uma skill é carregada quando o Claude a julga relevante, o que é relevância, não garantia. O provisionamento dá uma skill a todos; no Enterprise, um plugin que a carrega pode ser obrigatório para um grupo. Isso é o mais próximo de uma linha de trabalho no chat e no Cowork hoje, e falha em três aspectos: é exclusivo do Enterprise, foca em pessoas e não em projetos, e nada flui de uma linha para seus projetos. Uma regra que deve sempre se aplicar em uma linha não pode depender da detecção de relevância.

“Mods já fazem isso.” No Claude Code, parcialmente, desde 1º de outubro de 2026. Um mod pode reescrever o prompt do sistema, recusar uma chamada de ferramenta e desenhar um painel, e os mods de uma organização rodam antes dos de uma pessoa. Portanto, o compilador, a verificação em tempo de escrita e a visualização de instruções efetivas deste artigo poderiam ser construídos como um mod hoje, e a seção 6 diz isso. Três limites permanecem. Mods não rodam no chat do Claude e, no Cowork, as configurações do console da organização não se aplicam. Sua ordem tem dois donos, organização e pessoa, sem uma linha de trabalho entre eles; no Enterprise, um plugin obrigatório para um grupo pode levar um mod até esse grupo, mas ele roda como um dos mods da própria pessoa, sem precedência. E um mod é código sem sandbox: para rodar antes dos mods das pessoas, o mod de uma organização precisa ficar em um diretório em cada máquina, e as configurações entregues pelo console de administração “não conseguem colocar o diretório em uma máquina”. Uma empresa sem gestão de dispositivos pode enviar um mod para todos, mas ele rodará junto com os mods das pessoas, não à frente deles. Uma empresa não deveria precisar escrever TypeScript para dizer que um departamento reporta em unidades diferentes.

“A memória vai aprender as regras.” A memória é escrita principalmente pelo Claude, para uma pessoa ou um projeto, e um proprietário não pode ler nem editar as memórias de um membro. Um auditor precisa de regras escritas por uma pessoa, versionadas, aprovadas e rastreáveis até cada resposta. A Anthropic já construiu isso três vezes: para permissões, com “View effective role” e seu rótulo “Granted by”; para skills e plugins, com histórico de versões e uma etapa de revisão onde “você não pode aprovar a si mesmo”; e para o acesso do Claude Tag, com seus rótulos “Inherited from”. As instruções em um projeto não têm nenhuma das três.

“O Claude Tag já faz isso.” Para canais do Slack, em grande parte sim, e a seção 1 diz isso. Três coisas ainda faltam. Um canal não é um projeto: não tem pasta, não tem chave, não tem ciclo de vida, e “um canal não pode ser apontado para um Projeto”. A árvore tem três níveis fixos, então uma empresa com linhas de trabalho e centenas de trabalhos precisa achatar dois de seus níveis em nomes de canais. E a documentação não descreve nenhuma verificação de conflito quando uma instrução é escrita; os escopos são concatenados e o modelo é deixado para reconciliá-los. Se há algo, o Claude Tag é a evidência mais forte a favor do design deste artigo: a mesma empresa escolheu herança, credenciais vinculadas a escopo e um rótulo de origem quando construiu para equipes.

“Hierarquias adicionam complexidade.” Apenas se sua profundidade for ilimitada. A própria diretriz da Microsoft para grupos de gerenciamento é “não mais que três a quatro níveis”. Este modelo fixa quatro níveis portadores de regras, e pastas de agrupamento, como série e ano, não carregam regra alguma.

“A herança é um risco de segurança.” É, se o acesso for herdado de forma descuidada. A resposta da nuvem se aplica: uma permissão deve existir em cada nível, uma negação em qualquer lugar vence, o Claude age como o usuário cruzado com o nó, e as próprias edições de regras do Claude viram propostas.

“Mais camadas custam mais tokens.” A seção 3.2 mediu o oposto no Claude Code: 20% menos tokens de instrução como cascata, 34% menos compilados, em comparação com cópias planas. Cada arquivo extra adiciona um pouco de overhead, então compilar supera cascatear. Tarefas tipadas descartam os templates que não estão em uso, e prefixos compilados são idênticos em bytes entre projetos, então o cache de prompts pode reutilizá-los. Na API do Claude, os caches são isolados por workspace, então um workspace por organização mapeia para a raiz da árvore. O Claude Code não tem isso hoje: seu cache é restrito a uma máquina e um diretório.

“As equipes podem simplesmente manter seus próprios projetos.” Esse é o paliativo de hoje, e o protótipo na seção 5 mediu o que ele produz: duas de seis cópias coladas desatualizadas em uma pequena demonstração.

5. Roda hoje: uma implementação de referência

Para mostrar que o modelo é construível, e não apenas discutível, criei o Worktree, um pequeno aplicativo desktop (Node e Electron, 24 testes passando no Windows e Linux) com layout parecido com o do Claude Desktop. O vídeo acima é uma execução real dele, encurtada apenas nos momentos em que o Claude estava processando. É um app separado que controla o Claude Code por fora, não um mod. Ele não chama um modelo próprio. Cada chat roda o Claude Code já instalado no computador (claude -p), com o login que o Claude Code tiver: uma assinatura do Claude ou uma chave de API. Eu o executei em uma empresa fictícia com três linhas de trabalho e seis projetos. Quando alguém envia uma mensagem:

• Permitir. A pessoa agindo precisa de uma concessão no projeto ou acima dele, e o projeto deve estar aberto. Um administrador sem concessão na linha foi barrado antes de o Claude começar.

• Verificar. A checagem em tempo de escrita roda primeiro. A regra SI da seção 3.4 é rejeitada como conflito com uma regra imposta da empresa, então nunca chega a um CLAUDE.md.

• Montar. A árvore é escrita nas pastas reais do projeto como um CLAUDE.md por nível (organização na raiz de armazenamento, depois linha, depois projeto), e a própria cascata do Claude Code os carrega. Um modo compilado escreve um arquivo por projeto em vez disso. Arquivos sem o marcador do app nunca são sobrescritos.

• Executar. O template da tarefa entra via --append-system-prompt-file. O que o Claude pode fazer é imposto pelo Claude Code, não pelo CLAUDE.md: --allowedTools é a função da pessoa cruzada com a política de cada nível, as gravações são limitadas à pasta do projeto, e --permission-mode dontAsk recusa todo o resto. Em execuções reais, uma busca na web foi recusada porque a política da linha não permite web, e uma gravação fora da pasta do projeto foi negada e registrada em log.

• Registrar e revisar. Cada resposta é registrada com a pessoa, o nó, cada tag de regra, as regras que o Claude citou e os tokens de entrada, cache e saída reportados pelo Claude Code. Um revisor que não escreveu a resposta a aceita ou devolve. Uma execução real de relatório de densidade na demonstração levou cerca de 30 segundos; em três execuções, o Claude Code reportou de US$ 0,08 a US$ 0,22 por resposta nos preços de tabela. O Claude citou as regras que aplicou, sinalizou resultados próximos ao limite de aceitação e deixou os campos do engenheiro em branco.

• Desvio. Cada CLAUDE.md montado é comparado com a árvore, e edições manuais são sinalizadas. Um protótipo anterior em linha de comando fez a mesma comparação em cópias coladas em projetos planos e encontrou duas de seis desatualizadas: uma ainda na R-07 v3 e outra onde uma regra havia sido excluída manualmente.

Três descobertas ao construí-lo, todas relevantes para quem empilha instruções no Claude Code:

1. Suas instruções pessoais vazam para as execuções da organização. Por padrão, cada execução também carregava meu ~/.claude/CLAUDE.md pessoal, regras, agentes e servidores MCP. O app agora os exclui com a configuração claudeMdExcludes, além de --strict-mcp-config. Na minha máquina, isso reduziu o contexto de uma execução de 29,6 mil para 21,4 mil tokens. A alternativa óbvia, --setting-sources project,local, fez o oposto do necessário no Claude Code 2.1.284 no Windows: manteve o arquivo pessoal e descartou os arquivos CLAUDE.md da pasta pai que carregam a organização e a linha.

1. Os mods de uma pessoa também vazam. Os mods chegaram no dia seguinte à criação do app, então eu testei. Instalei um mod de um único hook no meu próprio escopo de usuário que adiciona uma linha a cada prompt. Ele alcançou as execuções do app: as três regras da organização foram carregadas, assim como minha linha pessoal, e a resposta a obedeceu. Adicionar disableAllHooks às configurações da execução o manteve de fora e deixou os três níveis de CLAUDE.md intactos; o app agora faz isso. --safe-mode não é um substituto: ele removeu o mod e toda a cascata CLAUDE.md junto. Segundo a documentação, disableAllHooks nas configurações da própria pessoa deixa rodando o que a organização gerencia.

1. CLAUDE.md é contexto, imposição é configuração. A documentação da Anthropic diz isso: “As regras de configurações são impostas pelo cliente independentemente do que o Claude decidir fazer. As instruções do CLAUDE.md moldam o comportamento do Claude, mas não são uma camada rígida de imposição.” O app depende disso. Tudo o que uma regra deve garantir é mapeado para permissões de ferramentas; tudo no CLAUDE.md é orientação com uma tag.

Funciona no Claude Code de hoje, e o texto compilado pode ser colado em um chat ou nas instruções de um projeto do Cowork em qualquer plano. Uma dependência tem prazo de validade: o app depende de o claude -p carregar arquivos CLAUDE.md, e a documentação da Anthropic diz que --bare, que os ignora, “se tornará o padrão para -p em uma versão futura”. Quando isso acontecer, o app terá que passar a árvore de outra forma; o modo compilado e --append-system-prompt-file já conseguem. É uma especificação funcional para a versão nativa, não um limite de segurança: “agir como” é um botão de demonstração, não um login.

6. Um caminho a partir do que já foi lançado

No Claude Code, agora. Desde 1º de outubro, a árvore pode ser entregue como um mod: compilar as regras do nó em uma seção do prompt de sistema, recusar chamadas de ferramentas que a política do nó proíbe e exibir as instruções efetivas em um painel. Uma organização pode executar esse mod antes de qualquer coisa que uma pessoa instale. Eu não construí isso; é o primeiro item no roadmap da implementação de referência. Isso cobriria o Claude Code e, possivelmente, as sessões do Cowork na máquina do usuário, que rodam na mesma engine. Não cobriria o chat.

A versão de 30 dias, para chat e Cowork. A Anthropic já tem as peças. Permitir que um projeto aponte um projeto pai cujas instruções ele herda, da mesma forma que um canal do Slack herda do seu workspace no Claude Tag. Compilar os dois em ordem, com uma tag em cada regra, e adicionar um painel “Ver instruções efetivas” ao lado do atual “Ver função efetiva”. Só isso já dá a cada área de atuação um único lugar para guardar suas regras.

Depois disso, cada etapa é útil por si só, começando pelo que ajuda os planos Team:

1. Nós por área de atuação e provisionamento de padrões-chave, reutilizando a semântica do CLAUDE.md que já funciona no código. No próprio Claude Code, a etapa de correspondência vira uma camada para um grupo entre os mods da organização e os da pessoa, além de configurações gerenciadas por grupo.

1. Tipos de tarefa como habilidades com escopo definido por área, com critérios de aceite.

1. Uma verificação de conflito no momento da escrita, para que contradições sejam rejeitadas pela árvore, e não arbitradas pelo modelo.

1. Concessões em nós, que funcionam no Team sem grupos e estendem as funções personalizadas do Enterprise.

1. Identidades de conector vinculadas a branches para projetos, assim como o Claude Tag já vincula uma conta de serviço a um canal do Slack.

1. Contabilização por nó atrelada ao projeto, como o Claude Tag já reporta por canal; um limite semanal publicado em uma unidade definida; e divulgação de consumo de energia por tarefa.

7. Limitações

• Cobertura. Em 1º de outubro de 2026, os índices completos de páginas de code.claude.com/docs e claude.com/docs foram triados por título (466 páginas) e cerca de 150 páginas foram lidas, junto com os artigos da central de ajuda citados aqui. Versões anteriores deste artigo passaram batido pelo Claude Tag; esta pode deixar escapar outra coisa. O Claude for Government e o Claude Desktop em provedores terceirizados são mencionados, mas não analisados.

• Os recursos da plataforma mudam todo mês, e um deles mudou enquanto este texto era escrito. Toda afirmação sobre produtos aqui tem data de 29 de setembro a 1º de outubro de 2026 e deve ser conferida novamente antes de você confiar nela. Os mods têm um dia de vida; li a documentação deles e testei um caso, mas não os usei em produção.

• Os números medidos nas seções 3.1 a 3.4 vêm dos próprios relatórios de uso do Claude Code, em dois lotes: Claude Code 2.1.286 em 30/09/2026 e 2.1.287 em 01/10/2026, ambos no Claude Sonnet 5.5. O script, os dois lotes e todas as respostas estão guardados pelo autor e disponíveis sob solicitação. Eles incluem o próprio prompt do Claude Code (cerca de 30.200 tokens), que o claude.ai e o Cowork não compartilham, e cobrem um modelo, um projeto de demonstração e uma pergunta. As amostras são pequenas: dez respostas por condição para o tamanho da resposta, vinte por condição para o teste de conflito. As proporções de tamanho de resposta variaram entre os dois lotes (seção 3.3); dois lotes separados por um dia também diferem pela versão do Claude Code, e não consigo separar isso do acaso.

• O tempo de execução, o custo e os tamanhos de contexto na seção 5 vêm do próprio log de respostas do aplicativo, com três execuções de demonstração e um teste manual de isolamento, que são registros do autor.

• As respostas de conflito foram codificadas pelo autor, sem cegamento, lendo cada resposta (unidades reportadas; se a resposta disse qual regra venceu e por quê; se ela perguntou). Todas as quarenta estão disponíveis sob solicitação para recodificação. O teste usou uma formulação de “enforced” (aplicado); outras formulações, modelos e pares de regras podem se comportar de forma diferente.

• O teste de mod na seção 5 é um mod com um hook, em uma máquina Linux, com o Claude Haiku, autenticado via assinatura e sem configurações gerenciadas. Não testei um mod de política de organização, a proteção nativa em um login Team ou Enterprise, nem o aplicativo Desktop.

• O modelo de custo na seção 3.2 é uma simulação de uma empresa ilustrativa, não uma cobrança medida. Ele cobre apenas tokens de instrução; histórico de conversa, saída e raciocínio costumam dominar as contas reais. Seus tamanhos de token usam o tokenizer público legado da Anthropic × 1,30; na medição, o Claude Code carregou de 21% a 26% mais do que essa estimativa, então seus valores em dólar ficaram para baixo. Suas porcentagens são proporções e se sustentam. Padrões de sessão e compartilhamento de cache são suposições.

• Se o uso de chat no Enterprise recebe preços de cache da API e se os caches são compartilhados entre usuários no claude.ai não está documentado. O Cowork roda suas sessões no Claude Code, e os hooks de plugin carregam lá, mas as páginas de mods não listam o Cowork e eu não o testei; em 1º de outubro, o aplicativo desktop ainda empacotava o Claude Code 2.1.286, uma versão antes de os mods serem ativados. A política gerenciada de um dispositivo alcança as sessões do Cowork na máquina do usuário, a menos que a organização as execute em um sandbox completo de VM. Duas páginas discordam sobre se os próprios arquivos ~/.claude de uma pessoa chegam ao Cowork, então este artigo não faz nenhuma afirmação nesse sentido. Também não testei se arquivos CLAUDE.md em pastas superiores carregam em uma sessão do Cowork; se carregarem, a árvore montada da implementação de referência alcançaria o Cowork na máquina do usuário hoje. Nos planos Pro e Max, essa janela se estreita em 6 de outubro de 2026, quando novas tarefas do Cowork passam para a nuvem.

• Motivações são inferidas. A Anthropic não explicou publicamente por que o chat do Claude e o Cowork são planos.

• O código e os dados brutos não são publicados com este artigo. Um leitor não consegue reproduzir as medições apenas com o artigo; o vídeo mostra o aplicativo funcionando, não como ele foi construído.

• A implementação de referência roda em uma empresa inventada. Ela não é integrada ao claude.ai nem ao Cowork, e “agir como” é um botão de demonstração, não um login. As permissões são aplicadas pelas listas de ferramentas do Claude Code, não pelo aplicativo. O isolamento desativa os hooks e mods pessoais durante a execução; os mods embutidos no Claude Code continuam rodando, e os nomes de agentes pessoais ainda podem aparecer no contexto. O aplicativo depende do claude -p carregando o CLAUDE.md, algo que a Anthropic diz que deixará de ser o padrão. O vazamento de arquivo pessoal e o resultado de --setting-sources foram testados no Windows; as medições e o teste de mod rodaram no Linux.

Fontes

• Anthropic, Definir instruções da organização

• Anthropic, Funções e permissões

• Anthropic, O que é o plano Team? · Planos e preços

• Anthropic, Gerenciar funções personalizadas nos planos Enterprise

• Anthropic, Organize suas tarefas com projetos no Claude Cowork

• Anthropic, Usar conectores do Google Workspace

• Anthropic, Gerenciar grupos e limites de gastos de grupos nos planos Enterprise

• Anthropic, O que são projetos? (nova versão de projetos, beta)

• Anthropic, Comece a usar o Claude Cowork (instruções globais e de pasta)

• Anthropic, Como o Claude lembra do seu projeto (CLAUDE.md) · Todas as configurações (claudeMdExcludes, disableAllHooks)

• Anthropic, Personalize o Claude Code com mods (1º de outubro de 2026) · Visão geral dos mods · Gerencie mods para sua organização · Reaja a eventos com um mod · Referência de mods

• Anthropic, Claude Tag: O que é o Claude Tag? · Configurar acesso por canal · Personalizar o Claude Tag · Como funciona a identidade do agente · Auditoria · Definir um limite de gastos

• Anthropic, Projetos no Claude Code (beta de novos projetos) · Projetos no Cowork · Como o Claude Code usa o cache de prompts · Executar o Claude Code programaticamente (--bare) · Estender o Claude Code · Gerenciar visibilidade e compartilhamento de projetos · Usar conectores · Autorizar conectores MCP para toda a sua organização · Provisionar e gerenciar habilidades

• Anthropic, Configurar definições gerenciadas pelo servidor (sem configuração por grupo) · Gerenciar plugins para sua organização (disponibilidade de plugins por grupo no Enterprise) · Suporte a recursos de plugins nas plataformas (hooks ignorados no chat, carregados no Cowork) · Implantar configurações gerenciadas (o Cowork roda suas sessões no Claude Code)

• Anthropic, Preços (tarifas do Sonnet 5.5, nota sobre o tokenizer) · Cache de prompts (caches isolados por organização e por workspace na API)

• Anthropic, @anthropic-ai/tokenizer (tokenizer público usado para as contagens)

• Microsoft, Grupos de gerenciamento · Design de grupo de gerenciamento de landing zone

• AWS, Avaliação de SCP · Google Cloud, Avaliação de hierarquia

• Microsoft, Processamento de Diretiva de Grupo · Permissões refinadas do SharePoint

• FinOps Foundation, Economia de tokens

• Jaroslawicz et al., Quantas instruções os LLMs conseguem seguir ao mesmo tempo? (IFScale)

• Firefly, Pesquisa State of IaC 2026

• MCP, Especificação de autorização, versão 2026-07-28

• GitHub, issues de anthropics/claude-code #68262, #14467, #30554, #27567, #30250, #27302, #47741

• Beer, S. (1979), The Heart of Enterprise; Alexander, C. (1965), “A City is Not a Tree,” Architectural Forum; Simon, H. (1962), “The Architecture of Complexity,” Proc. Am. Phil. Soc.106(6)

• Implementação de referência e dados: o aplicativo Worktree, seus testes, o script de medição, os dois lotes de resultados e todas as respostas estão com o autor e disponíveis sob solicitação.