Hub-Spoke Custa 4x Mais para Código, e Perde. Multi-Agente Acaba de Ser Medido.

Por dois anos, plataformas multi-agente foram vendidas com a mesma figura: um orquestrador central coordenando trabalhadores especializados. Hub-spoke. Gerente e time. A analogia com o organograma era tão intuitiva que ninguém perguntou se a arquitetura de fato encaixa na carga de trabalho.

Rohit Krishnan perguntou. Mediu. A resposta destrói o pitch universal.

Em Why Smart Planners Lose to Simple Markets, Krishnan rodou o mesmo conjunto de tarefas em três arquiteturas: solo (um agente faz tudo), hub-spoke (orquestrador delega a trabalhadores) e mercados (agentes independentes competem). Os resultados se separaram limpamente por tipo de carga, e a separação é o oposto do que a maioria dos slides de procurement assume.

O Que os Números Dizem

Para tarefas de código: solo marcou 7,2/10. Hub-spoke marcou 6,7/10 a US$ 5,33 por tarefa, cerca de 4x o custo do solo. A arquitetura de orquestrador perdeu em qualidade e custo simultaneamente.

Para tarefas de raciocínio: mercados marcaram 7,1/10. Solo marcou 5,1/10. Agentes independentes competindo no mesmo problema produziram respostas melhores do que um único agente pensando mais.

O padrão é estrutural, não coincidência. Código exige estado global contínuo, o que foi decidido três arquivos atrás, que contrato de interface foi assumido, o que as fixtures de teste esperam. Dividir isso entre um orquestrador e trabalhadores introduz perda de tradução em cada handoff. A observação verbatim de Krishnan sobre o modo de falha: “se qualquer um dos passos estiver errado, os trabalhadores podem ser individualmente competentes e a resposta final ainda assim vai piorar.” Cada agente está bem. As costuras entre eles são onde a qualidade morre.

Raciocínio é a forma oposta. A tarefa se beneficia de tentativas independentes, enquadramentos diferentes, cadeias de pensamento diferentes, tentativas diferentes no mesmo alvo. Mercados exploram isso. Solo não consegue, porque um agente só pode pensar de um jeito por vez, e auto-dúvida não substitui tentativas genuinamente independentes.

Por Que a Analogia do Organograma Quebra

A pergunta mais profunda é por que hub-spoke falha para código quando funciona para times humanos. Krishnan é direto: “agentes de IA NÃO são como agentes humanos. Modelos também não são apenas modelos.”

Três disanalogias estruturais fazem o estrago.

Sem conhecimento individual persistente. Um trabalhador humano acumula contexto de projeto ao longo de semanas. Lembra da call com o cliente onde o requisito significava outra coisa. Carrega conhecimento tácito que nunca chegou ao spec. Agentes de IA começam cada tarefa sem memória além do que é empurrado para o prompt. O orquestrador não pode delegar para um trabalhador que internalizou o projeto, porque tal trabalhador não existe.

Contexto tácito não passa em mensagens. Times humanos transferem entendimento por conversa, troca de corredor, experiência compartilhada. O handoff orquestrador-para-trabalhador em IA é uma string de tokens. Tudo o que o trabalhador precisa tem que ser serializado. O que é implícito se perde. Código vive ou morre de contexto implícito, convenções de nomenclatura, estilo de tratamento de erro, o que significa “pronto para produção” nesta base.

Comportamento muda com o prompt. Um trabalhador humano tem julgamento estável entre tarefas. A qualidade de um agente de IA é função de como ele foi promptado neste turno. O prompt do orquestrador para o trabalhador é fonte de variância. Duas delegações ligeiramente diferentes produzem dois trabalhadores materialmente diferentes. Não há análogo em gestão humana, você não recebe um funcionário diferente dependendo de como formulou o pedido.

Junto: a analogia do organograma funciona no nível da metáfora e quebra no nível da arquitetura. Hub-spoke para código é pagar 4x por perda de tradução entre agentes que não têm o que traduzir.

Onde Cada Arquitetura de Fato Encaixa

As medições sugerem um checklist de procurement, não uma resposta universal.

Solo é certo quando o trabalho exige estado global contínuo. Código, refatoração, edições multi-arquivo, qualquer coisa em que a segunda decisão dependa de lembrar da primeira. O custo de um handoff de contexto excede o custo de um agente fazendo tudo. Os números de código de Krishnan são a versão mais limpa desse argumento: a arquitetura mais barata também ganhou em qualidade.

Mercados são certos quando o trabalho se beneficia de tentativas independentes. Raciocínio, pesquisa, exploração, qualquer coisa em que ver o mesmo problema por ângulos genuinamente diferentes melhore a resposta. O gap de 7,1 vs 5,1 em raciocínio é o gap entre três tentativas independentes e um agente pensando mais. Tentativas independentes ganham porque amostram uma distribuição mais ampla.

Hub-spoke é certo quando as subtarefas são genuinamente independentes e o papel do orquestrador é coordenação real. Automação de workflow entre sistemas distintos. Pipelines em que a saída do passo N é entrada limpa do passo N+1. Casos em que o orquestrador faz roteamento e agregação, não transferência de contexto de alta largura de banda. A arquitetura funciona quando as costuras entre agentes são finas, quando há pouco a traduzir, porque a fronteira já era limpa.

O pitch de fornecedor para hub-spoke como arquitetura padrão de agentes de código agora está mensuravelmente errado. Não filosoficamente errado. Errado por 0,5 ponto de qualidade e 4x de multiplicador de custo no mesmo benchmark.

A Pergunta de Procurement

Líderes de engenharia avaliando plataformas multi-agente foram orientados a comparar funcionalidades, integrações, cobertura de modelos. Pergunta errada. A pergunta certa é se a arquitetura da plataforma casa com o tipo da carga de trabalho, e se permite trocar de arquitetura conforme os tipos mudam dentro da mesma organização.

Uma plataforma que só faz hub-spoke é uma plataforma apostando que todas as suas cargas se parecem com problemas de coordenação. Os dados de Krishnan dizem que algumas das suas cargas mais caras não. Código, a carga que a maioria das organizações de engenharia tenta acelerar primeiro, é exatamente a forma errada para hub-spoke.

As perguntas a fazer ao fornecedor:

• Quais cargas na nossa organização são de estado contínuo (usar solo)? Quais se beneficiam de tentativas independentes (usar mercados)? Quais são coordenação limpa (usar hub-spoke)?
• A plataforma permite rodar as três arquiteturas ou nos prende em uma?
• Qual o delta de custo-por-tarefa entre arquiteturas em uma carga representativa nossa, medido como Krishnan mediu?
• Quando a arquitetura está errada para a carga, o modo de falha é visível, qualidade degradada, custo maior, ou é silencioso?

O primeiro argumento medido de que uma arquitetura multi-agente está errada para algumas cargas é também o primeiro argumento de que decisões de procurement devem ser tipadas por carga, não por fornecedor. Compre a arquitetura que encaixa no trabalho. Se a plataforma só vende uma forma, está vendendo as cargas que ela serve, não as que você tem.

---

Fontes

• Rohit Krishnan / Strange Loop Canon. “Why Smart Planners Lose to Simple Markets (Why Coase Needs Hayek).” Maio de 2026.

A Victorino ajuda líderes de engenharia a casar a arquitetura multi-agente ao tipo de carga de trabalho antes do lock-in de fornecedor: contato@victorino.com.br | www.victorino.com.br