**
Uma ideia arquitetônica amplamente difundida na comunidade de IA está levando muitas equipes ao caminho errado.
A Conclusão Primeiro
Se você está pensando em nomear vários Agentes de IA como "Gerente de Produto", "Arquiteto" e "Engenheiro de Testes", e fazê-los passar documentos e colaborar como departamentos de uma empresa — por favor, pare.
Esse modelo parece intuitivo e logicamente sólido, mas tem falhas fundamentais em engenharia. Mais importante ainda, nenhum dos três grandes provedores — Anthropic, OpenAI e Google — usa esse modelo ao construir seus próprios sistemas de Agentes.
Isso não é coincidência.
O que é a Arquitetura dos "Três Departamentos e Seis Ministérios"?
Essa metáfora se refere a uma classe de ideias de design multiagente amplamente populares na comunidade, conhecidas por diferentes nomes em vários frameworks e artigos: agentes baseados em papéis, equipes virtuais, divisão de trabalho estilo CrewAI ou organização estilo MetaGPT. Este artigo as chama coletivamente de modelo "Departamentalizado".
O padrão central é: decompor uma tarefa complexa em várias funções, com cada Agente desempenhando um papel — PM para requisitos, Tech Lead para arquitetura, Dev para implementação e QA para testes. As tarefas fluem entre os Agentes como uma linha de montagem.
Esse modelo parece ótimo em um diagrama. Ele satisfaz a intuição humana de "divisão do trabalho" e torna o conceito de uma "equipe de IA" concreto e explicável. Frameworks como CrewAI acumularam muitos usuários por causa disso.
O problema é que ele resolve gargalos humanos, não gargalos de IA.
Por que Essa Analogia é Fundamentalmente Errada
Os humanos precisam de divisão do trabalho porque:
- Uma única pessoa tem atenção limitada e não consegue processar todas as informações simultaneamente.
- Os humanos têm barreiras profissionais e altos custos de aprendizado/mudança.
- Os humanos precisam de interfaces para coordenar uns com os outros.
Mas as características dos LLMs são completamente diferentes:
- O mesmo modelo pode escrever tanto PRDs quanto código; não existem "barreiras profissionais".
- O gargalo para os modelos não é a capacidade de atenção, mas a profundidade de raciocínio e a integridade da informação.
- Os modelos não têm "cultura" e "entendimento tácito" para compensar a perda de informação.
Rotular um Agente como "Gerente de Produto" não o torna mais profissional — faz com que ele se recuse a cruzar fronteiras. Um Agente limitado a um papel de "Engenheiro de Testes" pode ignorar um problema arquitetônico porque "não está no meu escopo". O raciocínio mais valioso geralmente acontece nas fronteiras, e o modelo Departamentalizado sela essa possibilidade em nível de sistema.
A interpretação de papéis cria fronteiras falsas. Este é o primeiro problema.
O Segundo Problema: A Informação Morre no Trânsito
No modelo Departamentalizado, o Agente A produz um documento e o passa para o Agente B.
Esse processo transmite conclusões, não o processo de raciocínio.
B recebe o documento, o reinterpreta e reconstrói o contexto. A intenção original se degrada, suposições ocultas se perdem e cada transferência acumula erros. Quanto mais longo o fluxo de trabalho, mais a saída final se torna "localmente correta, mas globalmente desviada" — cada nó parece razoável, mas o todo se desviou do objetivo original.
As organizações humanas dependem de reuniões, cultura e comunicação informal para compensar essa perda de informação. Os Agentes não têm esses mecanismos.
Há uma objeção comum: As soluções dos três grandes provedores (progress.txt, arquivos de especificação, runbooks) também envolvem "passar arquivos"? Qual é a diferença?
A diferença está em quem escreve, para quem é e como é atualizado.
O fluxo de informação departamentalizado é uma transferência unidirecional entre papéis: A termina e entrega para B; B não olha para trás, e A não sabe como B usou o documento. A informação é comprimida em conclusões, o processo de raciocínio se perde e a transferência é um ponto de ruptura.
Os arquivos de estado externos são logs incrementais da mesma tarefa: A entidade executora anexa ao mesmo registro em cada ponto de verificação, e a próxima sessão lê o histórico completo da tarefa, não a conclusão de saída de um "colega" anterior. A pessoa que escreve o estado e a pessoa que lê o estado são o mesmo papel, apenas em momentos diferentes. A informação não é "comprimida e passada"; ela é "continuamente acumulada".
Essa diferença determina se a cadeia de raciocínio pode permanecer contínua entre as sessões.
Uma quantidade massiva de tokens é desperdiçada em "arquivos de transferência" entre Agentes, em vez de raciocínio real. Você obtém um sistema que simula o comportamento de uma empresa, não um sistema que resolve problemas.
Como os Três Grandes Provedores Realmente Fazem
É notável que quando Anthropic, OpenAI e Google constroem seus sistemas de Agentes de nível de produção, seus documentos de engenharia quase nunca mencionam "interpretação de papéis" ou "divisão departamental".
Anthropic: Engenharia de Contexto + Arquivos de Estado Explícitos
A Anthropic atualizou a "Engenharia de Prompt" para "Engenharia de Contexto": A questão não é como escrever um bom prompt, mas qual configuração de token produz melhor o comportamento desejado.
Ao construir os sistemas Claude Code e Research, seu desafio central foi: Os Agentes devem trabalhar em sessões discretas, e cada nova sessão não tem memória do que aconteceu antes. Sua metáfora são "engenheiros de turno" — cada novo turno de engenheiros não sabe nada sobre o trabalho do turno anterior.
A solução não é fazer com que os Agentes desempenhem papéis diferentes, mas:
- claude-progress.txt: Um log de trabalho entre sessões que o Agente atualiza no final de cada sessão e lê no início da próxima.
- Histórico do Git: Servindo como âncoras de estado, registrando cada alteração incremental.
- Agente Inicializador: Executa apenas na primeira sessão para configurar o ambiente, expandir a lista de recursos e escrever o runbook para todas as sessões subsequentes.
Insight chave: A continuidade da cadeia de raciocínio não depende do modelo "lembrar"; depende de estado externo explícito para ancorá-la.
Eles também descobriram que codificar "suposições de capacidade do modelo" no harness é perigoso. O Sonnet 4.5 tinha "ansiedade de contexto" — ele concluía cedo ao se aproximar do limite de contexto, então eles adicionaram uma reinicialização de contexto ao harness. Mas no Opus 4.5, esse comportamento desapareceu, e a reinicialização se tornou peso morto. Isso mostra que o harness precisa evoluir com o modelo; qualquer "solução permanente" é apenas um compromisso de engenharia para o estágio atual.
Em sistemas de Pesquisa multiagente, a arquitetura da Anthropic é orquestrador-trabalhador: um agente líder decompõe tarefas e coordena subagentes, que exploram direções diferentes em paralelo, com os resultados fluindo de volta para o agente líder para síntese. Eles descobriram que o consumo de tokens sozinho explicava 80% das diferenças de desempenho — o valor dos multiagentes não é "divisão do trabalho", mas usar mais tokens para cobrir um espaço de busca maior.
Há um ponto de confusão aqui: Os subagentes da Anthropic podem parecer "divisão do trabalho", mas a essência é diferente. A departamentalização é divisão funcional — papéis diferentes lidam com tipos diferentes de trabalho (PM para Dev para QA). Os subagentes da Anthropic são paralelismo funcional — vários agentes idênticos buscam direções diferentes simultaneamente, não há "próximo passo", e todos os resultados convergem para o mesmo orquestrador. O primeiro é uma corrida de revezamento; o segundo é lançar uma rede ampla.
OpenAI: Compaction + Skills + Arquivos de Especificação Estruturados
Os princípios da OpenAI para tarefas de longo horizonte são ainda mais diretos: planeje a continuidade no início da tarefa.
Em seus experimentos com Codex, os engenheiros deram ao agente um arquivo de especificação (congelando o objetivo para evitar que o agente fizesse algo "impressionante, mas na direção errada"), fizeram com que ele gerasse um plano baseado em marcos e, em seguida, usaram um arquivo runbook para dizer ao agente como operar. Este runbook também é uma memória compartilhada e um log de auditoria.
Resultado: O GPT-5.3-Codex funcionou por cerca de 25 horas continuamente, completando uma ferramenta de design completa, mantendo a coerência durante todo o processo.
A compactação no lado do servidor serve como um primitivo padrão, não como um fallback de emergência. Em tarefas de várias etapas, previous_response_id permite que o modelo continue trabalhando no mesmo thread, em vez de reconstruir o contexto a cada vez.
Eles também introduziram o conceito de Skills — conjuntos de instruções reutilizáveis e versionados montados em contêineres, dando aos agentes padrões operacionais estáveis para tarefas específicas. Estes não são "papéis"; são ferramentas e procedimentos operacionais, que são fundamentalmente diferentes.
Google: 1M de Contexto + Desenvolvimento Orientado a Contexto
A direção do Google é forçar a janela: o contexto de 1M de tokens do Gemini é uma estratégia de diferenciação clara. Sua lógica é que técnicas anteriormente forçadas, como fatiamento de RAG e descarte de mensagens antigas, podem ser substituídas por "apenas colocar tudo" dado uma janela grande o suficiente.
Mas eles admitem que mesmo isso não é suficiente. O Google lançou a extensão Conductor para o Gemini CLI, com uma ideia central idêntica à da Anthropic: mover a intenção do projeto para fora da janela de chat e para arquivos Markdown persistentes no código-fonte. A filosofia: "Não confie em histórico de chat instável; confie em arquivos formais de especificação e plano."
O Gemini 3 também introduziu as Thought Signatures: salvar nós-chave da cadeia de raciocínio em sessões longas para evitar "deriva de raciocínio" — o problema de inconsistência lógica em contextos longos.
Quais São os Princípios Arquitetônicos Reais?
Das práticas de engenharia dessas três empresas, vários princípios comuns podem ser extraídos:
A cadeia de raciocínio não pode ser quebrada; ela só pode ramificar e mesclar. O uso correto de multiagentes não é uma linha de montagem, mas um agente principal segurando a intenção completa, com subchamadas usadas para aprofundar subproblemas, e os resultados fluindo de volta para o agente principal, não passados para o próximo agente.
Estado externo explícito, não confie na memória do modelo. Seja progress.txt, histórico do git, arquivos de especificação ou bancos de dados — a forma não importa. O princípio é: nós-chave da cadeia de raciocínio devem ser externalizados para armazenamento persistente.
O valor dos multiagentes é a cobertura paralela, não a divisão do trabalho. A conclusão do sistema de Pesquisa da Anthropic é clara: os ganhos de desempenho vêm de "gastar mais tokens", não de "melhor divisão do trabalho". Multiagentes são adequados para tarefas de amplitude primeiro — cenários que exigem exploração simultânea de direções independentes. Eles não são adequados para cenários que exigem raciocínio contínuo e dependência profunda de contexto.
O Agente Verificador é um negador, não um corredor de revezamento. Se estiver usando multiagentes para controle de qualidade, o design correto é ter um Agente especificamente para encontrar problemas no trabalho de outro, em vez de "passar o resultado do trabalho". Testes adversariais, não transferência em linha de montagem.
Ferramentas são ferramentas, não papéis. Com quais ferramentas você equipa um Agente (bash, I/O de arquivo, busca, execução de código) é muito mais importante do que qual rótulo você coloca nele. As ferramentas determinam o que um Agente pode fazer; os rótulos de papel apenas restringem o que ele está disposto a fazer.
Por que o Modelo "Departamentalizado" é Popular?
Porque é fácil de explicar.
"Este Agente é o PM, aquele é o QA" — qualquer um pode entender isso. Isso satisfaz o desejo humano de explicabilidade do sistema de IA e a imaginação da gestão de "IA trabalhando como uma equipe".
Também é fácil de demonstrar. Desenhado como um fluxograma com departamentos, setas e transferências, é muito intuitivo.
Mas ser fácil de explicar e demonstrar é diferente de ser engenheiramente sólido.
Uma razão mais profunda é que a maioria das equipes que adotam esse modelo nunca enfrentou verdadeiramente o problema da "perda de contexto durante a transferência multiagente". Suas tarefas podem não ser complexas o suficiente, ou o problema é mascarado por outros fatores. Uma vez que a complexidade da tarefa aumenta e o sistema começa a mostrar erros "localmente corretos, mas globalmente errados", o problema é exposto.
Conselhos Práticos
O melhor sistema multiagente não se parece com uma empresa. Parece mais com os múltiplos rascunhos de um pensador — o mesmo cérebro expandindo o raciocínio em diferentes dimensões e finalmente mesclando-os em uma conclusão coerente.
Com base neste princípio:
Não pergunte "De quantos Agentes preciso?"; pergunte "Qual é a estrutura de dependência de informação desta tarefa?"
Se uma tarefa requer raciocínio contínuo e alta dependência de contexto (por exemplo, escrever um documento de design para um recurso complexo), um único Agente + boa engenharia de contexto geralmente é superior a multiagentes.
Se uma tarefa requer exploração simultânea de direções independentes (por exemplo, pesquisar 10 concorrentes simultaneamente), o paralelismo multiagente é razoável — a tarefa de cada subagente é independente, e o custo da perda de informação é minimizado.
Se uma tarefa abrange várias sessões, os arquivos de estado externos são obrigatórios. Um arquivo de estado eficaz deve conter quatro tipos de informação:
- Objetivo da Tarefa (Invariável, lido no início da sessão para evitar desvio)
- Etapas Concluídas (Anexadas, não sobrescritas, para manter o histórico completo)
- Estado Atual (Sobrescrito para refletir o progresso mais recente)
- Armadilhas Conhecidas (Anexadas para evitar repetir erros na próxima sessão)
Esses quatro tipos de informação, mantidos separadamente e combinados, fornecem o contexto completo necessário para o "próximo eu".
Se adicionar uma etapa de verificação, faça com que a única tarefa do Agente Verificador seja encontrar problemas, não "pegar o bastão e continuar". Testes adversariais, não transferência em linha de montagem.
Finalmente: As capacidades do modelo estão melhorando rapidamente. Soluções alternativas necessárias no harness hoje podem se tornar peso morto em seis meses. A Anthropic já provou isso — a ansiedade de contexto do Sonnet 4.5 desapareceu no Opus 4.5. Manter a evolutibilidade arquitetônica é mais importante do que escolher uma "arquitetura perfeita".
A departamentalização é uma ilusão que parece boa, mas é engenheiramente cara. Seu verdadeiro custo não é o fracasso direto, mas fazer com que seu sistema se degrade de maneiras difíceis de diagnosticar à medida que a complexidade aumenta — onde cada nó "parece estar funcionando", mas o todo está se desviando.
Quando você encontrar o problema, a linha de montagem já estará muito longa.
Referências: Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents); OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction); Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)
