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. Assim, cada projeto recebe uma cópia feita à mão 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. Nenhum deles chega ao nível do 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 conflitantes, 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 texto: 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 criei roda o Claude Code dentro dessa á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 algo concreto. Todo sistema de qualidade em que trabalhei foi construído assim, e o mesmo vale para a árvore de pastas em quase todos os servidores de arquivos corporativos: empresa, linha de atuação, ano e, em seguida, uma pasta por trabalho, nomeada por um número 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 formam 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 transmite instruções para 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, qual é o custo real 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 possui quatro interfaces onde o trabalho de uma equipe acontece, e cada uma tem 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 desses 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 alcança as 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ó é carregada quando o Claude a considera 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 criado para pequenas e médias empresas.

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 somam-se, 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 indica “Herdado de” um escopo mais amplo ou “Anexado 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 barreira 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 seção 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 aspectos deles importam aqui:

• Eles carregam uma ordem declarada. Uma proteção integrada 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 serão executados.” Onde a proteção é carregada (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 recuse. 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 decidir. Não há um nível para a 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 queira uma política diferente por grupo tem dois caminhos, ambos via TI: implantar um arquivo de configurações 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 atingem o Cowork de forma desigual. “Mods funcionam na CLI do Claude Code e na aba Code do aplicativo Claude Desktop.” Um mod é entregue em 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 aplicativo 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 limitado: 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 dos projetos está em beta público no Pro e no Max, começando no Claude Code, com chat, Cowork, Team e Enterprise 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 no código e por canal no 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 locatário, 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 trabalho), 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 resume-se a arquivar e excluir. O Cowork pode vincular um projeto a uma pasta local, mas apenas manualmente, um projeto por vez, sem padrão de chave e sem pai. Uma linha de atuação pode abrir centenas de trabalhos por ano. Isso deixa duas opções ruins: um projeto do Claude feito à mão para cada trabalho, 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. Retire um elemento e nada acima dele será transferido para baixo. Com regras, acontece o mesmo. 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 feita à mão.

As cópias divergem. Corrija uma regra em um projeto e os outros mantêm a versão antiga. Cada projeto continua passando em sua própria verificação local. A incompatibilidade só aparece quando alguém compara projetos lado a lado e, em trabalhos regulamentados, esse alguém costuma ser um auditor. Equipes de infraestrutura conhecem bem essa falha. Na pesquisa de 2026 da Firefly, cerca de um terço dos entrevistados associou o desvio de configuração a incidentes caros em produção, e aproximadamente 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 consegue vincular o Drive de cada cliente aos projetos desse 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 anexada a um canal do Slack, e também mostra onde ele para: no projeto. A página do conector do Google da Anthropic descreve uma única conta do Google conectada, e a maneira 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 manda “pedir ao Claude para repetir suas instruções de administrador”. Nenhuma interface mostra, para uma determinada 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 às taxas 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. Conforme medido na seção 3.2, o prompt do sistema e as ferramentas do próprio Claude Code somavam 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

Legendas em todas as imagens: 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 coletei os tokens de entrada que o próprio Claude Code reportou. Rodei no Claude Code 2.1.286 em 30 de setembro e novamente 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 pôde mostrar. A cascata custa 224 tokens a mais do que o arquivo compilado para as mesmas regras: cada arquivo extra traz overhead, aqui representado pelo marcador e título do próprio aplicativo no arquivo de cada nível, além do 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% mais do que o tokenizador 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 baixas.

Depois, a simulação 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 tokenizador legado público da Anthropic (que a própria Anthropic chama de “uma aproximação muito grosseira” para o Claude 3 e posteriores) e escalonados em 1,30 para o tokenizador do Claude 4.7+. O bloco da organização foi extrapolado de uma amostra de 597 caracteres para o limite de 3.000 caracteres, e o manual da linha de atuação é 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 é renovado 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 de atuação, todos os seis modelos de relatório e as especificidades do projeto.

• Árvore: organização, linha de atuação, apenas o modelo de relatório em uso e, então, as especificidades do projeto, compiladas com as camadas mais compartilhadas primeiro.

Tamanhos por trás da tabela: bloco da organização com 830 tokens (3.000 caracteres), manual da linha de atuação com 729, um modelo de relatório com 147, especificidades do projeto com 98 (arredondados; os totais foram calculados antes do arredondamento). A simulação ignora o prompt do sistema do próprio 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, de modo que centenas de projetos compartilham um prefixo idênte byte a byte: só a ordenação, com todos os seis modelos ainda carregados, reduz o custo do 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: nele, “o cache é efetivamente restrito 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 gerar, não como algo disponível hoje. Uma objeção justa: as 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 de atuação e fluir para os projetos dessa linha. (No Claude Code, uma skill em um subdiretório é carregada para sessões iniciadas nele ou abaixo dele.) 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. O histórico da conversa e a saída dominam as faturas reais. O argumento forte a favor da árvore é a precisão e, no Team, a capacidade. Não é a fatura.

A medição acima reproduz o efeito das 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 ensaio 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 que o leitor nunca vê.

Quatro constatações:

• As regras da empresa tornaram as respostas 1,4 vez mais longas na tela e de 1,8 a 1,9 vez mais longas na fatura. O extra visível eram as seções de sinalizações, normas e limitações que as regras exigiam. 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 aceitação distinguem.

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 de 1,27–1,31 no segundo; a proporção cobrada foi de 1,78–1,82 e depois de 1,70–2,05; a proporção do espanhol foi de 1,29–1,38 e depois de 1,14–1,18. A direção nunca mudou. O tamanho é confiável até 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. Todas as ferramentas foram proibidas e os arquivos pessoais ~/.claude foram excluídos, de modo que apenas as instruções declaradas diferiram entre as condições. As contagens de tokens vêm 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 consolidados 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 tokenizador 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 de atuação produz. A regra da organização mandava usar unidades do sistema americano; uma regra de projeto mandava reportar densidades no SI. Coloquei-as como uma árvore faria: a regra da organização em um CLAUDE.md na raiz do 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 texto: a tag ENFORCED em seu rótulo e uma frase adicionada, “Esta regra é imposta: nenhuma regra de linha de atuação 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 substitui a regra da empresa); cinco citaram apenas a regra do projeto e nunca mencionaram que a regra da empresa discordava. Com a obrigatoriedade declarada por texto, 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: nove de dez respostas disseram por que a regra do projeto venceu no primeiro lote, e 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 mora 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 avisou ao leitor que uma regra superior havia sido deixada de lado. Um teste piloto feito na primeira versão deste artigo, com as duas regras em um único prompt em vez da cascata, também mudou de resultado apenas ao trocar a ordem delas (regra da organização primeiro: SI 5 de 5; regra da organização por último: SI 2 de 5, e 3 de 5 informaram ambas as unidades ou perguntaram qual se aplicava).

Nenhum modelo deveria ser chamado para 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 contradigam, quando executado por uma pessoa. E desde 1º de outubro, um mod pode impor uma ordem no código: os mods da organização rodam antes dos da pessoa e, onde o guardrail nativo é carregado, regras de negação (deny) vencem o mod da pessoa. Nenhum dos dois cobre texto de instrução. Os arquivos de instrução continuam concatenados, e a documentação descreve o resultado de três formas: o Claude “pode escolher um arbitrariamente”; quando uma regra de usuário e uma 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 tentativas foi exatamente a cara desse julgamento na prática. 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 esta mudança, “R-22 define units.density=SI; R-01 (org:firm) impõe US”, antes que qualquer coisa chegue ao Claude, e enforced (imposto) é 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 unidades mais justas?

O token é um indicador razoável de computação dentro de um mesmo modelo: mais tokens realmente significam mais trabalho para o hardware. É por isso também 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 fica com os ganhos de eficiência que conquistar, 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 verificar isso 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: computação continua sendo um input. 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 validado.

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. Não dá para fazer orçamento com nenhum dos dois.

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, porque é nela que os critérios de aceitação podem existir.

3.6 Motivos mais prováveis para isso ainda 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 o texto 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 é herdado em uma árvore, o acesso também precisa ser. Isso significa reconstruir o modelo de permissões sob cada camada.

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

1. Simplicidade focada no consumidor final. Ferramentas de código herdam uma árvore de graça 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 dedução 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 a organização dentro do workspace de IA. O servidor de arquivos ou o sistema de documentos já é a fonte da verdade. Siga um caminho:

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

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

• Nós com regras: organização, linha de atuação, 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 com chave. Ele é criado automaticamente: quando uma pasta correspondente ao padrão de chave da linha aparece (por exemplo {YY}GT{NNN}_{Nome} sob a raiz da linha), um nó de projeto é criado, herda da sua linha e recebe acesso de conector restrito apenas àquela pasta. Ele guarda somente o que difere da 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 principal, 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 atuação. Por isso, todo nó tem um pai principal, e conjuntos de regras transversais se anexam como sobreposições (usa). 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 coração do design, e é aqui que 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 (allow) em todo o caminho desde a 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 mesclar. 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.

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, por fim, especificidades do projeto. Essa ordem maximiza os acertos de cache (seção 3.2). Ela se alinha aos quatro breakpoints de cache da Anthropic, com um orçamento de tokens por camada, embora na prática um breakpoint possa ser necessário para a conversa em si.

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 atuação 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 de uma para outra a menos que os donos de ambas compartilhem explicitamente. A primitiva técnica já existe: a especificação de autorização MCP usa tokens OAuth vinculados a audience (RFC 8707 resource indicators, RFC 9728 protected resource metadata) e exige que os servidores “NÃO DEVEM aceitar ou transitar quaisquer outros tokens” (versão da especificação 2026-07-28).

4.7 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 mudar regras ou permissões; só pode propor mudanças. (Hoje, o Claude consegue atualizar sozinho as instruções de pastas no 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ó é o que os papéis (roles) em seu caminho concedem, dentro do que a política permite em todo o caminho, 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: os papéis se aplicam conforme concedidos.

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

• Arquivado: somente leitura para todos; apenas o dono 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 que não seja o solicitante as aprova. Elas expiram sozinhas e são contabilizadas, porque cada substituição é uma ilha permanente de manutenção; 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 dono existe, é sempre registrado em log e revisado depois.

No plano Team, isso funciona sem grupos: a concessão vive no nó, então uma organização com quatro papéis ainda consegue 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 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 quem propôs, aprova, e os projetos irmãos o herdam. Hoje, essa melhoria fica presa no projeto onde aconteceu.

• Transversalmente. A especificação de uma agência muda uma vez. Projetos em três linhas recompilam com ela, e as linhas em si não mudam. Um conflito com uma regra da linha é rejeitado quando 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ê 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 passo 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 procedência para cada resposta e 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 validado = (custo em tokens + tempo de revisão) ÷ entregas aceitas

Como toda 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 reporta e limita gastos por canal, e a telemetria do Claude Code pode ser etiquetada por departamento, centro de custo ou repositório, manualmente. Nenhuma é atrelada a um projeto, e nenhuma divide o valor pelas entregas aceitas. Para uma empresa que fatura por número de trabalho, a IA vira um custo direto do trabalho em vez de 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 entrega uma skill para todos; no Enterprise, um plugin que a carrega pode ser obrigatório para um grupo. Isso é o que há de mais próximo de uma linha de atuação no chat e no Cowork hoje, e falha em três pontos: é exclusivo do Enterprise, mira 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 de detecção de relevância.

“Mods já fazem isso.” No Claude Code, em parte, desde 1º de outubro de 2026. Um mod pode reescrever o system prompt, recusar uma chamada de ferramenta e desenhar um painel, e os mods da organização rodam antes dos da pessoa. Então 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 atuação 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 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 roda junto com os mods das pessoas, não antes 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 dono não consegue 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”. 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 atuação 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 algo serve de prova, 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.” Só 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 com regras, e pastas de agrupamento como série e ano não carregam regra alguma.

“Herança é um risco de segurança.” É, se o acesso for herdado de forma descuidada. A resposta da nuvem se aplica: uma permissão (allow) deve existir em cada nível, uma negação em qualquer ponto vence, o Claude age como o usuário cruzado com o nó, e as próprias edições de regra 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 em 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 byte a byte entre projetos, então o prompt caching pode reutilizá-los. Na API do Claude, os caches são isolados por workspace, então um workspace por organização mapeia a raiz da árvore. O Claude Code não tem isso hoje: seu cache tem escopo de 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 estavam desatualizadas em uma pequena demonstração.

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

Para mostrar que o modelo pode ser construído, e não apenas defendido em tese, 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 rodei em uma empresa fictícia com três linhas de atuação 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 por 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 único arquivo por projeto. 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 é o papel da pessoa cruzado com a política de cada nível, 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. Toda resposta é registrada com a pessoa, o nó, cada tag de regra, as regras citadas pelo Claude 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 (Drift). 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 apagada 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,6k para 21,4k 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 das pastas superiores 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 carregaram, minha linha pessoal também, 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 substitui isso: 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: “Regras de configurações são impostas pelo cliente independentemente do que o Claude decidir fazer. 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 precisa garantir é mapeado para permissões de ferramentas; tudo no CLAUDE.md é orientação com uma tag.

Ele 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 claude -p carregando 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 outro jeito; o modo compilado e --append-system-prompt-file já conseguem. É uma especificação funcional para a versão nativa, não uma fronteira 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 do 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 no mesmo motor. 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á daria 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 limitado a uma área, com critérios de aceitação.

1. Uma verificação de conflito no momento da escrita, para que as 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 ampliam 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 das plataformas mudam mensalmente, e um deles mudou enquanto este texto era escrito. Toda afirmação sobre produtos aqui está datada entre 29 de setembro e 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 apenas 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, referente a três execuções de demonstração e um teste manual de isolamento, que são registros do próprio autor.

• As respostas do conflito foram codificadas pelo autor, sem cegamento, lendo cada resposta (unidades reportadas; se a resposta dizia qual regra venceu e por quê; se ela perguntou algo). Todas as quarenta estão disponíveis sob solicitação para recodificação. O teste usou uma única 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 envolve um mod com um hook, em uma máquina Linux, com o Claude Haiku, conectado via assinatura e sem configurações gerenciadas. Não testei o mod de política de uma 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ólares parecem baixos. Suas porcentagens são proporções e se mantêm válidas. Padrões de sessão e compartilhamento de cache são suposições.

• Não está documentado 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. O Cowork executa 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 vinha com 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 divergem sobre se os próprios arquivos ~/.claude de uma pessoa chegam ao Cowork, então este artigo não afirma nada 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 já 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 passarem para a nuvem.

• As 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 integrados ao Claude Code continuam rodando, e os nomes dos agentes pessoais ainda podem aparecer no contexto. O aplicativo depende do claude -p carregando o CLAUDE.md, o que a Anthropic diz que deixará de ser o padrão. O vazamento de arquivo pessoal e o resultado do --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 prompt · 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 executa suas sessões no Claude Code)

• Anthropic, Preços (tarifas do Sonnet 5.5, nota sobre o tokenizer) · Cache de prompt (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 em posse do autor e disponíveis sob solicitação.