Um agente isolado resolve tarefas dentro de um escopo estreito, com catálogo de ferramentas coeso e uma única trajetória de raciocínio. Quando o escopo cresce, a tentação imediata é ampliar o catálogo, engordar o system prompt e estender o loop até cobrir tudo. O comportamento que emerge é previsível: o agente escolhe ferramentas erradas com frequência maior, e o custo por tarefa cresce de forma não linear em relação ao número de ferramentas expostas. Pra mim, o ponto em que essa degradação deixa de ser administrável pela engenharia de prompt é o ponto em que um time de agentes passa a ser a estrutura correta. A pergunta útil deixa de ser qual modelo usar e passa a ser como distribuir responsabilidade sem reintroduzir, no sistema distribuído, os mesmos problemas do agente único.
A primeira topologia adotada é a do orquestrador-trabalhador, em que um agente central recebe a tarefa, decompõe em subtarefas e delega cada uma a um agente especializado com catálogo e prompt ajustados ao subdomínio. O orquestrador observa os resultados e entrega resposta consolidada. Funciona porque preserva o controle de fluxo num ponto único e concentra a observabilidade num lugar identificável, permitindo que cada trabalhador evolua de forma independente. Na minha avaliação, o custo está concentrado no orquestrador. Ele precisa manter uma representação precisa do estado global pra rotear de forma consistente, e essa representação cresce com o número de trabalhadores e com a profundidade da conversa. Quando falha, falha de forma característica, escolhendo o trabalhador errado ou combinando resultados incompatíveis, e o diagnóstico é difícil porque o raciocínio de roteamento costuma estar embutido no prompt, sem registro explícito.
A segunda topologia, hierárquica, aparece quando um orquestrador único deixa de dar conta. A árvore passa a ter gerentes intermediários, cada um responsável por um domínio, que recebem subtarefas do nível acima e as redistribuem entre trabalhadores próprios. Cada nível opera com catálogo menor e decisões localizadas, ao preço da latência acumulada, porque cada camada adiciona uma passada de raciocínio e uma passagem de estado. Hierarquias profundas tornam-se caras rapidamente, e cada nó intermediário é mais um ponto em que a decisão pode degradar. A regra que se sustenta é manter a árvore rasa, no máximo dois níveis, subindo pra três só quando a separação de domínios justifica o custo.
A terceira topologia, de rede ou enxame, remove o orquestrador central e permite que agentes passem tarefas entre si com base em regras locais de handoff. Cada agente decide se executa ou se delega, podendo enriquecer a tarefa antes de repassar adiante. A promessa é resiliência e escalabilidade, já que não há ponto único de falha. Na minha análise, na quase totalidade dos cenários em que essa topologia foi tentada em produção, a ausência de um ponto de observação central torna o sistema quase impossível de depurar, handoffs circulares aparecem com frequência desconfortável, e a análise de custo perde granularidade porque o caminho varia a cada execução. Redes funcionam em contextos bem definidos, com domínios disjuntos e critérios de handoff formalizáveis. Falham em contextos abertos, onde quem assume a tarefa depende de avaliação subjetiva. Em boa parte dos sistemas que se apresentam como redes opera, na prática, um orquestrador disfarçado que intercepta os handoffs e reimpõe controle central quando algo foge do esperado.
O que separa um padrão de delegação que funciona de um que apenas parece funcionar é como o estado e a confiança são tratados na fronteira entre agentes. Na delegação, o orquestrador precisa decidir o que enviar: tarefa inteira, recorte estruturado ou apenas os parâmetros mínimos. Enviar tudo explode tokens e arrasta informação que confunde o raciocínio local. Enviar pouco obriga o trabalhador a operar sem sinais que mudariam a decisão. A escolha depende do acoplamento entre a decisão do trabalhador e o contexto global, e precisa ser feita por subtarefa, não por convenção geral. O retorno tem o mesmo dilema, e a forma como o resultado chega (bruto, normalizado ou já integrado à conversa) determina se o orquestrador consegue combinar saídas heterogêneas sem um segundo passo caro. Quando chega, ele ainda precisa decidir entre aceitar, validar ou rejeitar, decisão que na maioria das implementações iniciais sai implicitamente do modelo. O efeito é que trabalhadores produzem respostas plausíveis e erradas que o orquestrador incorpora sem verificação, e a falha aparece no cliente como resposta coerente e incorreta, o pior modo de falha porque não dispara alerta automático. Times que rodam múltiplos agentes em produção acabam introduzindo uma camada de validação estruturada entre trabalhador e orquestrador, com schemas e critérios de aceitação que não dependem do julgamento do modelo sobre o próprio resultado. É aí que a engenharia tradicional reentra no sistema, e a maior parte do ganho de confiabilidade vem desse lugar.
A escolha do padrão de delegação decide onde colocar o custo. Orquestrador-trabalhador concentra custo no orquestrador e ganha previsibilidade. À medida que a topologia se distribui, o custo se espalha entre níveis ou pares, ganhando a separação de domínios ou a resiliência ao preço da latência e da observabilidade. Na minha avaliação, quem começa com orquestrador-trabalhador raso, com validação explícita no retorno dos trabalhadores e estado mínimo passado na fronteira, opera sistemas multiagente em produção sem reinventar a infraestrutura a cada seis meses. Quem escolhe pelo desenho do diagrama acaba descobrindo na operação que tratou um problema de delegação como se fosse de prompt, quando o caminho passava por decisão de arquitetura desde o começo.