Plano Vence Hierarquia: Agentes Pares e a Informação Perdida no Padrão Orquestrador

A maior parte dos sistemas multiagente em produção hoje compartilha uma topologia tão familiar que ninguém mais questiona. Um agente-pai decompõe a tarefa. Sub-agentes executam as partes. Os resultados sobem. O pai monta a resposta. Esse é o padrão orquestrador-trabalhador, e ele tem sido o padrão desde os primeiros designs publicados de harness.

O padrão é importado, em bloco, das hierarquias corporativas. Herda o mesmo modo de falha. Em qualquer hierarquia, a informação mais precisa sobre o que está realmente acontecendo vive no nível do trabalhador. Hierarquias então soterram essa informação debaixo de sumarização, tradução e do modelo que o pai já trazia do problema. Quando uma descoberta chega ao ponto de decisão, já foi comprimida no formato que cabe nas expectativas do pai.

A demo Pi to Pi do IndyDevDan, lançada esta semana, mostra a alternativa. Roda em um socket Unix e um servidor Bun. Expõe quatro ferramentas: listar agentes, enviar comando, enviar prompt, aguardar resposta. Não há papel de orquestrador. Qualquer agente pode pingar qualquer outro agente. O repositório é público. É curto. Dá para ler.

O que a demo prova não é que peer-to-peer é mais elegante. É que peer-to-peer muda qual informação chega à decisão.

Demo 1: O Agente de Produção Vê o Que o Agente de Dev Não Pode Ver

A primeira demo roda dois agentes em máquinas diferentes. Um agente de produção em um Mac Mini tem acesso a dados ao vivo. Um agente de dev em um MacBook Pro tem acesso ao código e ao ambiente de staging. Eles reproduzem um bug de bloqueio de usuário no plano Pro.

Em um setup orquestrador-trabalhador, o agente de dev pediria ao pai o estado de produção. O pai pediria ao agente de produção. O agente de produção devolveria o que o pai perguntou, no formato que o pai esperava. PII passaria sem redação, ou então o pai precisaria conhecer o suficiente do schema de produção para fazer as perguntas redigidas certas.

No Pi-to-Pi, o agente de dev pinga o agente de produção diretamente. O agente de produção aplica a redação de PII na própria fronteira. O agente de dev nunca vê dados brutos de produção, mas vê a descrição que o agente de produção faz do estado do bug, nos termos do agente de produção. O bug apareceu em minutos.

Vale nomear a propriedade arquitetural aqui. A fronteira de confiança é o próprio agente, não um plano de controle entre agentes. O agente de produção é o redator porque o agente de produção é quem sabe o que redação significa no contexto dele. Um orquestrador central que tenta aplicar redação em domínios de dados heterogêneos precisa conhecer todos esses domínios. O modelo entre pares deixa cada agente aplicar a própria fronteira.

Demo 2: Dez Correções Que Teriam Ido para Produção Em Silêncio

A segunda demo é a que deveria mudar como times de engenharia pensam sobre janelas de contexto de agentes.

Dois agentes trabalham em paralelo. Um carrega a documentação completa do E2B em contexto. O outro carrega a documentação completa do exe.dev em contexto. A tarefa é construir uma skill com paridade de funcionalidade para um novo provedor de sandbox, usando a skill existente do E2B como template.

A troca entre pares dura dez mensagens. Nessas dez mensagens, o agente exe.dev corrige o agente E2B dez vezes. Dez erros factuais que o agente originador teria embutido na nova skill em silêncio. O loop de correção só disparou porque havia um segundo agente com autoridade e contexto para empurrar de volta. Não um trabalhador reportando achados na cadeia. Um par discordando de um par.

A informação que mais importava vivia na segunda janela de contexto. Um setup hierárquico com um único agente planejador no topo não teria trazido à tona nenhuma dessas dez correções. O planejador teria escrito a skill a partir de um resumo da documentação, não da documentação em si. Os erros factuais viveriam no resumo, não na consciência do planejador.

Dois Milhões de Tokens, Duas Janelas, Um Resultado Melhor

Outro achado discreto da segunda demo: o orçamento total de contexto entre os dois agentes ficou em cerca de dois milhões de tokens. O mesmo orçamento em um único agente teria produzido um resultado pior. Não pela capacidade bruta do modelo, mas porque a atenção se degrada à medida que o contexto cresce. Duas janelas focadas de um milhão de tokens cada superam uma janela diluída de dois milhões.

Esse é o argumento operacional para peer-to-peer. A especialização de contexto é o ativo de fato. O protocolo A2A de quatro ferramentas é o mecanismo. A topologia é o que permite que contextos especializados negociem diretamente, em vez de forçar os achados por uma camada de tradução.

O próprio sistema multiagente de pesquisa da Anthropic, publicado em 2025, era hierárquico. A publicação de março de 2026 sobre harness de aplicações de longa duração usava uma cadeia estrita de planejador, gerador e avaliador. Em maio de 2026, a palestra na AI Engineer Conference reportou simplificação dessa hierarquia. Menos papéis. Mais comportamento entre pares emergindo no nível do modelo. O fornecedor que praticamente inventou o padrão moderno de orquestrador está, em palco, recomendando menos dele.

As Implicações de Governança Não São as Que Você Espera

Topologia plana não é ganho de graça. Tem consequências que o time de plataforma precisa planejar.

A aplicação de fronteira migra para o agente. Em setups hierárquicos, o orquestrador é um ponto natural de estrangulamento para política. Quer aplicar residência de dados? Coloque a regra no orquestrador. Quer redigir PII? Mesmo lugar. No peer-to-peer, cada agente que detém um domínio sensível precisa aplicar a própria fronteira. Isso é mais difícil de desenhar e mais fácil de escalar. O agente de produção da Demo 1 é o lugar certo para redigir dados de produção. O orquestrador nunca foi.

A auditoria sai de um traço único para um grafo. Uma execução hierárquica produz um log de auditoria linear: pai chamou filho, filho retornou, pai chamou o próximo filho. Uma execução entre pares produz um grafo direcionado. Sua stack de observabilidade precisa dar conta disso. Se você não consegue reconstruir quem disse o quê para quem, e em que ordem, você não depura e não passa em revisão de compliance.

Detecção de loop vira problema da plataforma. Dois pares podem se pingar indefinidamente. Hierarquias têm um sinal natural de terminação: o agente raiz retorna. Peer-to-peer exige orçamentos explícitos, prazos e detecção de ciclo. O await_response do Pi-to-Pi é síncrono; força serialização, mas não limita o tamanho da conversa. Uma implantação em produção precisa adicionar esses limites.

A habilidade de escrever para pares substitui a habilidade de escrever para orquestradores. Agentes-trabalhadores são desenhados para satisfazer um pai. Agentes-pares precisam confrontar uns aos outros e aceitar serem confrontados. Engenharia de prompt para comportamento entre pares é uma disciplina diferente de engenharia de prompt para execução hierárquica. As dez correções da Demo 2 aconteceram porque ambos os agentes foram instruídos a empurrar de volta em afirmações factuais, não apenas responder a perguntas.

A Decisão de Topologia Precisa Ser Explícita

Os times que ainda tratam orquestrador-trabalhador como única opção estão, em geral, fazendo isso por inércia, não por análise. A pergunta deixou de ser se peer-to-peer funciona. A demo Pi-to-Pi provou isso com quatro ferramentas e um socket Unix. A pergunta é quais partes do seu sistema de agentes ganham com topologia plana, quais partes precisam de controle hierárquico, e como esses dois regimes fazem handoff um para o outro.

Já escrevemos sobre kernels multiagente, sobre orquestração em produção e sobre modelos operacionais em formato de time. O que a demo desta semana adiciona é uma prova limpa e executável de que a escolha de topologia é uma escolha de verdade, com efeitos mensuráveis no fluxo de informação, nas fronteiras de governança e no uso de contexto. A camada de harness é onde essa escolha é feita. Importa qual harness você escolhe.

Faça Isso Agora

Bloqueie 45 minutos com a liderança de engenharia e um designer sênior de agentes. Puxe o diagrama do fluxo multiagente mais complexo do time. Faça três perguntas.

Primeira: onde, nesse fluxo, a informação morre porque um resumo substitui um achado? Se você não consegue identificar nenhum ponto desses, não olhou o suficiente. Todo fluxo hierárquico tem um. Marque.

Segunda: das fronteiras que você aplica centralmente hoje (PII, residência de dados, limites de taxa, validação de schema), quais delas são aplicadas por um agente que não detém o domínio que está sendo protegido? Mova essas fronteiras para os agentes que detêm o domínio. Esse é o padrão entre pares mesmo dentro de um fluxo ainda hierárquico.

Terceira: escolha um nó no diagrama em que dois agentes poderiam discordar de maneira produtiva e hoje não conseguem. Dê a eles as ferramentas para se pingarem. Veja o que sai. O repositório Pi-to-Pi entrega um protocolo de quatro ferramentas que você pode copiar. A mudança que você procura não está na ferramenta. Está no que chega à decisão depois que os agentes podem conversar.

O padrão orquestrador-trabalhador não é errado. Mas não é a única escolha. Tratá-lo como padrão é como times perdem, em silêncio, o acesso à informação que os próprios agentes já têm.

---

Fontes

• IndyDevDan. “Pi to Pi: Two-Way Agent Orchestration.” Maio de 2026.
• disler. “pi-vs-claude-code repo.” Maio de 2026.
• Ash Prabaker e Andrew Wilson, Anthropic. “Build Agents That Run for Hours.” AI Engineer Conference, Maio de 2026.
• Anthropic Engineering. “How we built our multi-agent research system.” 2025.

A Victorino ajuda times de engenharia a escolherem entre topologias hierárquicas e planas para agentes, e a instrumentarem ambas para produção: contato@victorino.com.br | www.victorino.com.br