Um agente que faz tudo — e falha exatamente por isso
Na primeira vez que a gente constrói um agente de IA, o instinto é sempre o mesmo: torná-lo mais capaz. Mais uma ferramenta, para ele também escrever arquivos. Mais uma seção no prompt de sistema para cobrir o caso excepcional da semana passada. Mais uma linha de instrução porque ele escorregou em alguma situação de borda. O agente fica maior, mais esperto, mais universal — e por um tempo isso funciona surpreendentemente bem.
Aí a coisa vira. A partir de certo ponto, mais não deixa o agente melhor; deixa pior. Ele perde o fio do que deveria fazer no meio da tarefa. Escolhe a ferramenta errada entre as suas trinta. Entra em loop, roda a mesma busca três vezes, se contradiz entre dois passos. O reflexo óbvio é empilhar ainda mais instruções — e é justamente isso que agrava o problema em vez de resolvê-lo.
A resposta não é um agente único mais inteligente. É um sistema com vários. Não porque muitos agentes sejam intrinsecamente melhores do que um — não são, já chego lá —, mas porque um único contexto e um único prompt têm um teto real, físico. Quem entende esse teto entende por que orquestração não é jargão da moda, e sim uma decisão de arquitetura.
Por que um único agente esbarra num teto
O teto tem três causas, e todas as três moram na janela de contexto — a memória de trabalho na qual o agente carrega a tarefa inteira, suas ferramentas e todo o histórico até ali.
Primeiro: a janela de contexto se enche de lastro. Cada ferramenta que um agente conhece custa espaço — não só quando é chamada, mas o tempo todo. A definição completa de cada ferramenta, com seus parâmetros, descrições e exemplos, fica no contexto a cada passo de raciocínio, esteja a ferramenta em uso naquele momento ou não. Um agente com cinco ferramentas carrega uma caixa enxuta. Um agente com trinta carrega uma loja de material de construção nas costas, e em nove de cada dez passos, vinte e nove delas são irrelevantes. Esse lastro disputa atenção com a tarefa de verdade — e a cada passo o modelo precisa pescar a única opção certa entre trinta plausíveis. A taxa de erro sobe exatamente onde a escolha é mais ampla.
Segundo: o raciocínio se degrada conforme o histórico cresce. Um modelo não raciocina igualmente bem sobre um contexto de 5.000 tokens e sobre um de 150.000. Quanto mais longo o histórico — cada chamada de ferramenta anterior, cada saída intermediária, cada tentativa frustrada —, mais ruído se acumula entre a pergunta atual e a informação que a responde. O modelo perde de vista instruções antigas, sobrescreve as próprias conclusões, se enrola em contradições entre o passo três e o passo dezessete. Há um nome certeiro que pegou para esse fenômeno: "context rot" — a deterioração lenta da qualidade das respostas à medida que o contexto fica mais cheio e mais confuso.
Terceiro: um prompt tenta ser tudo. Um agente pau-para-toda-obra precisa de um prompt de sistema que saiba pesquisar e escrever código e consultar bancos de dados e negociar com o usuário. Cada um desses papéis puxa o prompt para uma direção diferente. As instruções para pesquisar com cuidado ficam ao lado das que mandam escrever com cautela, e o modelo tem de decidir sozinho, a cada instante, qual chapéu está valendo. O resultado é um prompt que faz tudo pela metade e nada por inteiro — o generalista que é passável em tudo e excelente em nada.
Esses três efeitos se reforçam. Mais ferramentas significa mais contexto, que significa rot mais rápido, que significa decisões piores, que significam mais tentativas frustradas, que significam ainda mais contexto. Não dá para sair desse ciclo no prompt. É preciso cortá-lo.
Padrões que funcionam
A saída é sempre a mesma ideia de base: divida a tarefa e dê a cada parte um contexto próprio, fresco e estreito. Como fazer isso na prática segue um punhado de padrões consagrados.
Orquestrador e worker. Um agente central — o orquestrador — mantém a visão do objetivo e da estratégia, mas quase não executa trabalho de detalhe. Ele decompõe a tarefa e delega os pedaços a agentes worker, cada um recebendo exatamente um encargo, resolvendo-o no próprio contexto e devolvendo apenas o resultado. O orquestrador nunca vê os 40.000 tokens que o worker gerou ao vasculhar doze arquivos — recebe as três frases da conclusão. É exatamente assim que funcionam os subagentes do Claude Code: pela ferramenta Task, o agente principal dispara um subagente que faz uma pesquisa delimitada num contexto isolado e devolve só a essência. O contexto principal permanece limpo, por mais que o subagente tenha tido de fuçar.
Planejador, executor, verificador. Em vez de deixar um único agente planejar e agir e conferir, separam-se as três fases em três papéis. Um agente planejador descobre o que fazer e escreve um plano explícito. Um agente executor pega esse plano e o cumpre passo a passo, sem renegociar a estratégia o tempo todo. Um agente verificador pega o resultado e pergunta: está certo? A vantagem não é só o contexto limpo, mas o fato de cada papel encarnar um modo de pensar diferente — divergente ao planejar, focado ao executar, cético ao conferir. Um único agente teria de alternar entre esses modos com a mesma cabeça, e isso raramente dá certo.
Especialistas com um conjunto estreito de ferramentas. Um agente que só consulta o banco de dados precisa de três ferramentas, não de trinta. Seu prompt pode se dedicar inteiro a lidar com SQL de forma limpa. Um agente que só revisa pull requests não precisa de ferramenta de deploy. Quanto mais estreito o papel, mais curto o prompt, menor a caixa de ferramentas, mais certeira a escolha. Troca-se versatilidade por confiabilidade — e, para a maioria das subtarefas, é uma boa troca.
Subcontextos isolados como map-reduce. Talvez o padrão mais forte: quando uma tarefa percorre um grande conjunto de coisas semelhantes — vasculhe esta base de código, revise estes duzentos documentos, analise estes cinquenta endpoints —, ela é distribuída entre muitos subagentes paralelos, cada um cuidando de uma fatia e devolvendo apenas a sua conclusão. Nenhum contexto isolado chega a ver a base de código inteira; ele vê só os achados destilados. É exatamente esse o padrão que a Anthropic descreve em seus relatos sobre o sistema de pesquisa multiagente: um agente líder decompõe uma pergunta de pesquisa em aberto e dispara vários subagentes que seguem, em paralelo, diferentes fios. Cada subagente tem a própria janela de contexto e comprime seus achados antes de devolvê-los. O agente líder sintetiza a resposta a partir dessas compressões — e nunca precisou segurar na cabeça, ao mesmo tempo, a massa bruta de todas as fontes vasculhadas.
Todos esses padrões compartilham um princípio: o isolamento de contexto é o verdadeiro produto. Não é o número de agentes que melhora o sistema, mas o fato de cada agente ver apenas o que precisa para o seu trabalho estreito.
O problema do repasse
No instante em que se distribui trabalho entre vários agentes, surge um problema novo, que não existia com um agente só: o repasse. O que exatamente um agente passa ao seguinte — e em que forma?
O caminho cômodo, mas perigoso, é o texto livre. O agente A escreve em prosa o que descobriu, o agente B lê e segue em frente. Isso funciona nos casos simples e falha justamente no momento em que importa. Porque texto livre é ambíguo. Quando o agente A escreve "o pagamento deu certo, exceto num caso", o agente B tem de adivinhar qual caso, se é relevante, o que significa "deu certo" aqui. Ao longo de vários repasses, essa ambiguidade vira um "telefone sem fio": cada agente reinterpreta um pouco a saída levemente difusa do anterior, e depois de quatro paradas o último agente trabalha numa tarefa que só de longe lembra a original. Ninguém mentiu; cada um apenas torceu minimamente o sentido. O resultado, ainda assim, está errado.
A contramedida é pouco espetacular e eficaz: saídas estruturadas em vez de texto livre. Define-se um esquema — quais campos um repasse precisa conter, em que formato, com quais valores permitidos — e obriga-se cada agente a entregar seus resultados exatamente nessa forma. Em vez de "o pagamento deu certo na maioria", o agente devolve { "status": "parcial", "sucesso": 199, "falha": 1, "erro_id": "txn_88231" }. O agente seguinte não tem nada a interpretar; ele lê campos. Um esquema também impõe completude: se falta um campo obrigatório, isso salta à vista na hora, em vez de se infiltrar pela cadeia como uma lacuna silenciosa. O repasse deixa de ser uma narrativa e vira um contrato — e contratos são aquilo sobre o que se pode construir um sistema.
Verificação como um agente próprio
Há um papel de que quase todo sistema multiagente sério precisa e que, mesmo assim, costuma ser esquecido: o verificador. Não como cortesia, mas como um agente autônomo e adversarial, cujo único trabalho é refutar o trabalho dos outros.
O motivo é estrutural. Um agente que produziu uma solução é o pior verificador possível dessa solução — ele compartilha cada suposição que o levou ao erro e está condicionado a achar plausível a própria saída. Peça ao mesmo agente para "conferir de novo" e ele, na maioria das vezes, aprova o próprio trabalho. Um agente verificador separado, com um encargo oposto — "ache a falha, presuma que há uma aqui" —, chega com outra predisposição. Ele caça a lista vazia, o caminho de erro não tratado, a suposição que não se sustenta. Recebe a tarefa e o resultado, e tem licença para duvidar de ambos.
Isso não é garantia — um verificador de IA compartilha alguns pontos cegos com o produtor de IA, e dois sinais verdes não são duas vezes mais seguros que um. Mas um agente com encargo adversarial e contexto fresco pega uma classe inteira de falhas que o produtor, por estrutura, não consegue enxergar. Separar produzir e conferir em dois papéis é um dos ganhos de qualidade mais baratos que um projeto multiagente tem a oferecer.
O outro lado: multiagente não é de graça
Agora a conta honesta, porque sem ela a lição é levada longe demais. Sistemas multiagente quebram o teto do agente único — mas não fazem isso de graça, e em muitos casos o preço é maior que o ganho.
Os custos de token se multiplicam. Cada agente tem o próprio prompt de sistema, a própria lista de ferramentas, o próprio histórico — e tudo isso é processado de novo a cada passo. Nas medições da própria Anthropic, uma execução de agente consome cerca de quatro vezes os tokens de uma interação de chat normal, e um sistema multiagente cerca de quinze vezes. O que custa US$ 2 como requisição de chat custa, rapidinho, US$ 30 como execução multiagente orquestrada. Para tarefas de valor real, é dinheiro bem investido. Para uma reformatação simples, é dinheiro no lixo.
Coordenação custa overhead — e dá errado. Agentes que deveriam colaborar se enrolam de maneiras que um agente único simplesmente não consegue. Dois workers atacam a mesma subtarefa porque o orquestrador a distribuiu duas vezes. Um agente espera por um resultado que nunca chega. Dois agentes caem num loop em que cada um reage à correção do outro. Esses modos de falha só surgem por causa da distribuição — o agente único simplesmente não os tem.
Latência e depuração pioram. Uma execução multiagente é tão lenta quanto a sua cadeia mais lenta e, quando algo errado sai no fim, rastrear a causa é muito mais difícil: foi o planejador, um worker, o repasse no meio? O não determinismo agrava tudo — a mesma entrada leva, ao passar por vários agentes probabilísticos, a execuções diferentes, e uma falha que aparece só a cada cinco execuções é um inferno de reproduzir.
A conclusão sóbria: "mais agentes" não é "melhor". A maioria das tarefas é resolvida de forma mais rápida, mais barata e mais confiável por um único agente bem talhado. Multiagente compensa apenas quando a tarefa se decompõe de verdade e as subtarefas são independentes — pesquisa paralela em muitas fontes, map-reduce sobre uma base de código grande, fases bem separadas com repasses limpos entre elas. Se uma tarefa não se divide de forma sensata, cada agente extra só acrescenta custo de coordenação sem levantar o teto que é, de fato, a trava. A arte não é construir o máximo de agentes possível, mas reconhecer quando um é a resposta certa.
Conclusão
O reflexo de tornar um agente cada vez mais capaz é compreensível e, até certo ponto, correto. Passado esse ponto, ele se inverte: mais ferramentas, mais instruções, mais contexto não deixam o agente mais esperto, e sim mais disperso. O teto do agente único não é uma questão de prompts melhores, mas um limite estrutural — e não se supera com um prompt mais genial, e sim com um sistema bem pensado: agentes especialistas com papéis estreitos, contextos isolados, repasses estruturados, um verificador próprio.
Mas construir um sistema desses é uma tarefa de projeto, não uma fórmula mágica. Quem faz multiagente como fim em si mesmo compra custos de token, latência e não determinismo sem o ganho para mostrar. O trabalho difícil e valioso não está em construir muitos agentes, mas em decidir onde a decomposição realmente se sustenta e onde um único agente é a resposta mais honesta.
É exatamente aí que está o nosso padrão na NH Labs. Construímos sistemas de agentes em que cada agente tem um trabalho estreito e claramente delimitado — e em que um humano é o responsável pelo desenho da orquestração: é ele quem decide o que se decompõe e o que não se decompõe, como são os repasses e onde um verificador é necessário. Não o máximo de agentes possível, mas os certos, ligados com clareza. Por isso nossos sistemas funcionam não por serem complexos, mas porque cada parte deles é simples o bastante para ser confiável.