A Arquitetura Multi-Agent Que Realmente Entrega

A maioria dos sistemas multi-agent nunca sai da demo

O time de engenharia da Factory AI subiu ao palco no AI Engineer World's Fair e mostrou algo que a plateia não esperava: um sistema multi-agent que entrega código em produção. Não uma demo. Não um prototipo de pesquisa. Um sistema processando milhares de tarefas de programação por dia, com clientes reais dependendo do resultado. A palestra já acumulou mais de 119.000 visualizações porque respondeu a uma pergunta na qual a maioria dos times estava travada: como você sai de "agents que impressionam em demos" para "agents que funcionam na terca as 3 da manhã quando ninguém esta olhando?"

De acordo com o guia da product.engineer, uma arquitetura multi-agent é um design de sistema onde múltiplos agentes de AI especializados se coordenam para completar tarefas complexas, cada agente sendo responsável por uma atribuição distinta dentro de um workflow maior. Diferente de um agente monolitico que tenta fazer tudo, um sistema multi-agent decompoe o trabalho entre componentes construídos com propósito específico que se comunicam por interfaces definidas. Esse é o padrão de arquitetura que separa AI de produção de projetos de feira de ciência.

A resposta que a Factory apresentou não era magica. Era engenharia. Especificamente, o tipo de engenharia que um product engineer faz todos os dias: decompor problemas ambiguos em componentes enviaveis, construir sistemas que falham graciosamente e obcecar com o resultado para o usuário em vez da novidade técnica. A arquitetura multi-agent que eles descreveram funciona não porque os agentes individuais são mais inteligentes, mas porque o design do sistema os restringe a confiabilidade.

Eu passei anos construindo sistemas onde a coordenação é a parte difícil. Na AWS, vi times lutando com sistemas distribuídos onde os serviços individuais funcionavam perfeitamente isolados mas desmoronavam nas fronteiras de integração. Arquitetura multi-agent tem exatamente o mesmo modo de falha. Os agentes não são o problema. A coordenação é o problema. O framework da product.engineer para sistemas multi-agent mapeia isso. A Factory descobriu isso, é a solução deles e instrutiva para qualquer um construindo sistemas de AI de produção hoje.

Por que sistemas de agente único atingem um teto

Arquiteturas de agente único dominaram a primeira onda de ferramentas de AI para código. De uma tarefa para um modelo, deixe ele pensar, deixe ele escrever código. Cursor, GitHub Copilot, as versões iniciais do Devin. Funcionam notavelmente bem para tarefas delimitadas. Escrever uma função. Corrigir um bug. Gerar um teste.

Elas quebram em tarefas compostas.

Um estudo de 2025 do NLP Group de Princeton mediu a performance de agentes de AI em tarefas de engenharia de software multi-passo usando o dataset SWE-bench. Sistemas de agente único resolveram 13,8% dos issues reais do GitHub de forma autônoma. Quando os mesmos modelos subjacentes foram implantados em configuração multi-agent com papeis especializados para planejamento, implementação e verificação, a taxa de resolução saltou para 33,2%. Isso é uma melhoria de 2,4x apenas pela arquitetura, sem nenhuma melhoria no modelo.

A razao e fundamental. Um único agente gerenciando uma tarefa complexa precisa manter contexto de planejamento, detalhes de implementação e critérios de verificação em uma única janela de contexto simultaneamente. Conforme as tarefas crescem em complexidade, essas preocupações competem por atenção. O planejamento degrada porque o modelo esta distraido com detalhes de implementação. A implementação sofre porque o modelo ainda está raciocinando sobre o plano. A verificação vira um detalhe secundário porque a janela de contexto está saturada.

A arquitetura multi-agent resolve isso por separacao de responsabilidades. O mesmo princípio que faz microsservicos funcionarem melhor que monolitos. O mesmo princípio que torna pipelines Unix poderosos. Componentes pequenos e focados fazendo uma coisa bem feita, conectados por interfaces limpas. Não é uma ideia nova. E uma ideia antiga aplicada a um novo substrato.

O teto para sistemas de agente único e aproximadamente correlacionado com a utilização da janela de contexto. Uma vez que uma tarefa requer mais de 60% da janela de contexto efetiva de um modelo para raciocínio completo, a performance do agente único degrada de forma não-linear. A arquitetura da Factory evita isso distribuindo a carga cognitiva entre múltiplos agentes especializados, cada um operando bem dentro do seu orçamento de contexto.

A arquitetura de produção da Factory, decomposta

A arquitetura multi-agent da Factory, como apresentada no AI Engineer, segue um padrão que eles chamam de "Drafter, Reviewer, Integrator." Três classes de agentes, cada um com um papel específico, coordenando-se por um workspace compartilhado. Deixa eu detalhar o que realmente roda em produção.

O agente Drafter

O Drafter recebe uma especificação de tarefa e produz mudanças de código candidatas. Ele opera com um contexto focado: a descrição da tarefa, conteúdo de arquivos relevantes e convenções de código. Nada mais. Sem histórico de review. Sem contexto de deploy. Sem preocupações de integração. Essa restrição e deliberada. O trabalho do Drafter e produzir soluções plausiveis, não perfeitas.

A Factory reportou que seus agentes Drafter produzem código viável na primeira passagem em 84% dos casos. Os 16% restantes requerem iteração, mas de forma crítica, essa iteração e tratada por um agente diferente com contexto diferente e objetivos diferentes. O Drafter nunca vê suas próprias falhas porque dar contexto de falha a ele contaminaria seu foco generativo.

O agente Reviewer

O Reviewer recebe a saída do Drafter junto com uma janela de contexto diferente: padrões de código, políticas de segurança, requisitos de cobertura de testes e padrões históricos do codebase. Seu trabalho é pura crítica. Ele identifica problemas, sinaliza riscos potenciais e produz feedback estruturado.

Essa separacao e crucial. Quando um único agente escreve e revisa código, ele exibe vies de confirmação. Ele tende a aprovar o próprio trabalho. Ao separar esses papeis em agentes com system prompts diferentes e contextos diferentes, a Factory elimina esse vies estruturalmente. O Reviewer nunca viu a especificação da tarefa na forma original. Ele vê apenas o código é os padrões que deve aplicar.

O agente Integrator

O Integrator cuida da camada de coordenação: fazendo merge de mudanças, resolvendo conflitos, rodando testes e gerenciando o pull request final. Ele opera com o contexto mais amplo mas o espaço de ação mais restrito. Ele pode fazer merge, rejeitar ou solicitar novo rascunho, mas não pode escrever código ele mesmo.

Essa restrição previne um modo de falha comum onde um agente de integração "corrige" problemas escrevendo patches, introduzindo bugs sutis que nem o Drafter nem o Reviewer teriam produzido. O Integrator é um coordenador, não um contribuidor.

Comparação: padrões de agente único vs. multi-agent

O protocolo de coordenação multi-agent que funciona em produção

Agentes sozinhos não são arquitetura. A coordenação entre eles é a arquitetura. A apresentação da Factory revelou três padrões de coordenação que distinguem seu sistema de produção de pesquisa academica sobre multi-agent.

Padrão 1: Handoffs tipados

Toda comunicação entre agentes usa um schema tipado. O Drafter não passa "algum código" para o Reviewer. Ele passa um objeto estruturado com campos para: arquivos alterados, justificativa para cada mudança, scores de confiança por arquivo e premissas explícitas sobre o codebase. O Reviewer consome essa estrutura, não texto cru.

Isso importa porque comunicação não-tipada entre agentes é a fonte primária de falhas em cascata. Quando o Agente A passa saída ambígua para o Agente B, o Agente B precisa interpreta-la, e interpretacao introduz erro. Handoffs tipados eliminam a interpretacao. São os contratos de API dos sistemas multi-agent.

Padrão 2: Retry limitado com escalação

Quando um Reviewer rejeita a saída do Drafter, o sistema não entra em loop infinito. A Factory implementa um protocolo de retry limitado: o Drafter tem no máximo duas tentativas para endercar o feedback. Se ambas tentativas falharem, a tarefa escala para um engenheiro humano com contexto completo: a tarefa original, ambas tentativas é as razoes específicas de falha.

Esse padrão de retry limitado é o que torna o sistema seguro para produção. Loops de retry ilimitados são a forma mais comum de sistemas multi-agent desperdicarem compute e produzirem saída cada vez mais incoerente. Cada retry degrada a qualidade da saída porque o modelo esta raciocinando sobre suas próprias falhas, o que consome contexto que deveria estar dedicado a solução.

A Factory reportou que 91% das tarefas completam na primeira tentativa. 7% requerem um retry. Os 2% restantes escalam para humanos. Essa distribuição e saudável. Significa que o sistema conhece seus limites.

Padrão 3: Workspace compartilhado, contexto isolado

Todos os agentes operam no mesmo codebase (workspace compartilhado) mas veem fatias diferentes dele (contexto isolado). O Drafter vê os arquivos relevantes para sua tarefa. O Reviewer vê esses arquivos mais o guia de estilo e expectativas de testes. O Integrator vê o grafo completo de dependências é o status do CI.

Isso é análogo a como times de engenharia humanos trabalham. O desenvolvedor vê o código. O revisor vê o código mais os padrões. O engenheiro de release vê o estado do sistema. Mesmo artefato, perspectivas diferentes. A arquitetura multi-agent codifica esse padrão organizacional em software.

O que isso significa para product engineers

Se você é um product engineer construindo features com AI, os padrões da Factory oferecem licoes concretas que você pode aplicar hoje. Isso não é astronautica de arquitetura abstrata. São padrões que entregam.

Licao 1: Decomponha por modo cognitivo, não por tipo de tarefa. A separacao Drafter, Reviewer, Integrator não é sobre "planejamento, codificacao, teste." E sobre "gerar, criticar, coordenar." Esses são modos cognitivos fundamentalmente diferentes. Quando você projeta sistemas multi-agent, separe agentes por como eles pensam, não pelo que eles fazem. Um product engineer que entende isso vai construir sistemas mais confiáveis do que um que separa agentes por taxonomia de tarefas.

Licao 2: Restrições viabilizam a entrega. Os agentes da Factory são fortemente restritos. O Drafter não pode revisar. O Reviewer não pode codar. O Integrator não pode escrever patches. Essas restrições parecem limitantes, mas são o que torna o sistema previsível o suficiente para rodar em produção. Cada restrição que você adiciona a um agente é uma classe de falha que você elimina. Isso se conecta diretamente ao princípio de tornar seu codebase pronto para agents: quanto mais estruturado seu sistema, mais confiavelmente agents podem operar dentro dele.

Licao 3: Escalação humana é uma feature, não uma falha. Aquela taxa de escalação de 2% não é um bug. E uma decisão de design. O sistema é explicitamente projetado para reconhecer quando não consegue resolver um problema é rotear para um humano com contexto completo. Isso é o que distingue sistemas de produção de demos. Demos nunca falham. Sistemas de produção falham graciosamente.

Licao 4: Monitore fronteiras entre agentes, não apenas saídas de agentes. Os bugs em sistemas multi-agent vivem nas fronteiras. O Drafter produz bom código. O Reviewer faz boas críticas. Mas o handoff entre eles perde informação porque o schema tipado não captura alguma nuance. A Factory instrumenta cada handoff, medindo completude do schema, tempo de ida e volta e perda de informação. Se você está construindo sistemas multi-agent, sua camada de observabilidade precisa cobrir os espaços entre agentes, não apenas os agentes em si.

Padrões que você pode roubar hoje

Você não precisa da escala da Factory para aplicar arquitetura multi-agent. Aqui estão padrões concretos que funcionam em qualquer tamanho de time, destilados da abordagem deles e validados contra o que eu vi funcionar na AWS e nos meus próprios projetos.

O loop Draft-Review para qualquer feature de AI

Em vez de pedir para um modelo "escrever e revisar" código, dívida em duas chamadas separadas com system prompts diferentes. A primeira chamada gera com um prompt criativo e focado em solução. A segunda chamada avalia com um prompt crítico e focado em padrões. Configurações de temperatura diferentes, contexto diferente, objetivos diferentes. Você pode implementar isso em uma tarde e vai imediatamente melhorar a qualidade da sua saída de AI.

// Pseudocodigo para um padrão multi-agent mínimo
const draft = await model.generate({
  systemPrompt: "Você é um gerador de código. Foque em corretude e clareza.",
  context: [taskSpec, relevantFiles],
  temperature: 0.7
});
 
const review = await model.generate({
  systemPrompt: "Você é um revisor de código. Foque em bugs, segurança, violacoes de estilo.",
  context: [draft.output, styleGuide, securityPolicy],
  temperature: 0.2
});
 
if (review.approved) {
  return draft.output;
} else {
  // Um retry limitado
  const revision = await model.generate({
    systemPrompt: "Você é um gerador de código. Enderece esse feedback específico.",
    context: [taskSpec, relevantFiles, review.feedback],
    temperature: 0.5
  });
  return revision.output;
}

O padrão Coordinator para workflows complexos

Quando você tem workflows multi-passo (fluxos de onboarding, pipelines de dados, sequências de deploy), designe um agente como coordenador que não pode executar trabalho ele mesmo. Ele só pode despachar para agentes workers e gerenciar estado. Esse é o padrão Integrator aplicado a qualquer domínio. O coordenador mantém o estado global. Workers mantém contexto local. Nenhum agente sozinho mantém tudo.

A Linear usa uma variante desse padrão em suas features de gerenciamento de projetos com AI. O agente de coordenação entende a estrutura do projeto é a alocacao do time. Agentes workers lidam com tarefas específicas como escrever atualizações, triar bugs ou rascunhar especificações. O coordenador nunca escreve conteúdo ele mesmo. Ele roteia, prioriza e escala.

O agente de Verificação para segurança em produção

Adicione um agente de verificação final a qualquer pipeline que produz saída visível ao usuário. Esse agente recebe a saída final mais um conjunto de invariantes que devem ser verdadeiros. "Resposta não pode conter PII." "Código deve passar na checagem de tipos." "Resumo deve referenciar o documento original." O agente de verificação tem um único trabalho: confirmar ou rejeitar. E barato de rodar, rápido de executar e pega a classe de erros que passam pela geração e revisão.

A Stripe usa esse padrão no seu pipeline de documentação. Docs gerados passam por um agente de verificação que checa precisão técnica contra suas especificações de API. O agente de verificação pega aproximadamente 12% das saídas que de outra forma iriam para produção com erros técnicos sutis.

A economia de multi-agent vs. agente único

Uma objeção comum a arquitetura multi-agent e custo. "Você está fazendo três chamadas de API em vez de uma." Esse enquadramento entende errado a economia.

A Factory compartilhou dados economicos de produção na palestra. Seu sistema multi-agent custa aproximadamente 2,3x por tarefa comparado a uma baseline de agente único. Mas sua taxa de sucesso e 3,1x maior. E sua taxa de retrabalho (tarefas que precisam de intervencao humana após a conclusão inicial) e 74% menor. Quando você conta o custo totalmente carregado de um engenheiro refazendo trabalho de AI que falhou, o sistema multi-agent e aproximadamente 40% mais barato por tarefa concluida com sucesso.

A equacao de custo:

• Agente único: $0,12 por tarefa, 31% de taxa de sucesso = $0,39 por tarefa bem-sucedida
• Multi-agent: $0,28 por tarefa, 96% de sucesso na primeira passagem = $0,29 por tarefa bem-sucedida

Esses números são do sistema de produção da Factory no início de 2026. Seus números vão variar, mas a proporção se mantém. Gastar mais em inferencia para obter maior confiabilidade e quase sempre mais barato do que gastar tempo humano corrigindo saída não confiável.

Pesquisa sobre economia de agentes corrobora isso. Configurações multi-agent com 3-5 agentes especializados consistentemente superam sistemas de agente único em métricas de custo-por-conclusão-bem-sucedida, apesar de custos de inferência bruta mais altos. O ponto de equilíbrio é aproximadamente uma melhoria de 15% na taxa de sucesso. Qualquer coisa acima disso, o multi-agent se paga.

Minha experiência com coordenação de agentes em escala

Tendo orientado mais de 12.000 engenheiros por diversos programas e contratado mais de 600 durante minha carreira, tenho visto um padrão consistente: os times que entregam features de AI confiáveis não são os com os modelos mais sofisticados. São os com a arquitetura mais disciplinada. Os padrões multi-agent que a Factory descreve mapeiam diretamente para o que observei na AWS, onde pensamento de sistema distribuído e pre-requisito básico.

Os times com quem trabalhei que mais lutam com integração de AI são aqueles que tratam o modelo como um oráculo monolitico. "Peca pra ele fazer tudo, espere pelo melhor." Os times que tem sucesso tratam chamadas de AI como chamadas de serviço em um sistema distribuído: delimitadas, tipadas, com retry possível, observáveis. Eles constroem workflows de engenharia de AI colaborativa onde o sistema é projetado para degradacao graciosa, não performance perfeita. Esse é o superpoder do product engineer. Você pensa em sistemas, não em prompts.

Como product engineer, seu trabalho é entregar resultados, não impressionar pessoas com a complexidade da sua arquitetura de agentes. Sistemas multi-agent são poderosos precisamente porque fazem comportamento complexo emergir de componentes simples e restritos. Cada agente e entediante. O sistema é interessante. Essa e toda a licao.

Modos de falha comuns é como evita-los

Após estudar a abordagem da Factory e implementar variacoes dela em múltiplos projetos, identifiquei os modos de falha que matam sistemas multi-agent em produção.

O loop infinito. Dois agentes ficam trocando feedback indefinidamente. Agente A rascunha, Agente B rejeita, Agente A revisa, Agente B rejeita de novo. Solução: limites rigidos em retries. A Factory usa dois. Já vi times terem sucesso com três. Nunca mais que cinco. Se cinco tentativas não resolvem, um humano precisa olhar.

O vazamento de contexto. Agente A recebe informação destinada apenas ao Agente B. Isso acontece quando você compartilha um único thread de conversa entre agentes. Solução: isolamento estrito de contexto. Cada agente recebe sua própria janela de contexto, populada apenas com informação relevante ao seu papel.

O conflito de autoridade. Dois agentes dão instruções contraditorias a um terceiro. O Reviewer diz "adicione tratamento de erro." O agente de performance diz "remova o try-catch, ta muito lento." Solução: hierarquia clara. No sistema da Factory, o Integrator desempata. Sempre existe exatamente um agente com autoridade final.

O gap de observabilidade. Você consegue ver o que cada agente produziu mas não por que o sistema se comportou da forma que se comportou. O bug vive na interação entre agentes. Solução: logue cada handoff, cada schema, cada ponto de decisão. Sua observabilidade precisa cobrir os espaços entre agentes, não apenas os agentes em si.

A armadilha do scaling prematuro. Você adiciona mais agentes porque "multi-agent e melhor" sem validar que a decomposição melhora resultados. Solução: comece com um agente. Adicione um segundo apenas quando conseguir medir uma falha específica que o segundo agente preveniria. A Factory começou com um agente e adicionou componentes apenas quando dados de produção mostraram modos de falha específicos que a decomposição resolveria.

Para onde a arquitetura multi-agent esta indo

O padrão de arquitetura multi-agent que a Factory demonstrou é a versão um. Varios desenvolvimentos vão moldar como isso evolui nos próximos 12 a 18 meses.

Modelos especializados menores é mais baratos. Rodar modelos de classe GPT-4 para cada agente e caro. A tendência em direção a modelos menores mas capazes (Mistral, Phi, variantes do Llama ajustadas para tarefas específicas) significa que você pode rodar agentes especializados em modelos construídos com propósito. Seu Drafter pode usar um modelo grande e criativo. Seu Reviewer pode usar um modelo menor ajustado com dados de code review. O Integrator pode usar um modelo de raciocínio otimizado para tomada de decisão.

Protocolos padronizados de agentes. O Model Context Protocol (MCP) da Anthropic, o Agent Protocol da AI Engineer Foundation é a especificação de function calling da OpenAI estão convergindo para interfaces padrão de comunicação entre agentes. Dentro de um ano, você vai poder compor agentes de provedores diferentes com interfaces tipadas e interoperaveis.

Ferramentas de observabilidade para agentes. Empresas como LangSmith, Helicone e Braintrust estão construindo observabilidade especificamente para sistemas multi-agent. Tracing que atravessa fronteiras de agentes, atribuição de custo por agente e benchmarking de performance entre configurações. Essas ferramentas vão tornar sistemas multi-agent tão debugaveis quanto sistemas distribuídos tradicionais.

O product engineer que entende arquitetura multi-agent hoje vai estar construindo a próxima geração de produtos com AI amanha. Não porque a tecnologia e nova, mas porque os padrões estão comprovados. Decomponha. Restrinja. Coordene. Entregue.

Principais conclusões

• Arquitetura multi-agent separa agentes especializados por modo cognitivo (gerar, criticar, coordenar), não por tipo de tarefa
• Handoffs tipados entre agentes eliminam a ambiguidade que causa falhas em cascata
• Retry limitado com escalação humana torna sistemas seguros para produção; loops ilimitados são o modo de falha principal
• Sistemas multi-agent custam mais por tarefa mas menos por resultado bem-sucedido; o ponto de equilíbrio e aproximadamente uma melhoria de 15% na taxa de sucesso
• Comece com um agente e adicione decomposição apenas quando dados de produção revelarem modos de falha específicos que a justifiquem
• Monitore fronteiras entre agentes, não apenas saídas de agentes; e la que os bugs de produção vivem

FAQ

O que é arquitetura multi-agent em engenharia de software?

Arquitetura multi-agent é um padrão de design de sistema onde múltiplos agentes de AI especializados se coordenam para completar tarefas complexas. Cada agente e responsável por uma atribuição distinta (como rascunhar código, revisar código ou coordenar integração) e se comunica com outros agentes por interfaces tipadas. Esse padrão espelha a arquitetura de microsservicos em software tradicional: componentes pequenos e focados conectados por APIs limpas.

Como arquitetura multi-agent e diferente de um único agente de AI?

Um único agente de AI tenta lidar com todos os aspectos de uma tarefa dentro de uma janela de contexto, o que leva a sobrecarga cognitiva em tarefas complexas. A arquitetura multi-agent distribui a carga cognitiva entre agentes especializados, cada um operando dentro de um contexto focado. Pesquisa do NLP Group de Princeton mostra que configurações multi-agent alcancam taxas de sucesso 2,4x maiores em tarefas reais de engenharia de software comparadas a abordagens de agente único.

Quando devo usar arquitetura multi-agent em vez de um agente único?

Use sistemas de agente único para tarefas delimitadas e bem-definidas que cabem confortavelmente na janela de contexto de um modelo (escrever uma função, responder uma pergunta, gerar um teste). Mude para arquitetura multi-agent quando tarefas requerem múltiplos modos cognitivos (gerar E avaliar E coordenar), quando taxas de sucesso de agente único caem abaixo de limiares aceitaveis, ou quando você precisa de garantias estruturais como prevenir vies de confirmação em code review.

Como o sistema multi-agent da Factory AI funciona em produção?

A Factory AI usa o padrão "Drafter, Reviewer, Integrator." O Drafter gera mudanças de código candidatas com foco criativo. O Reviewer avalia essas mudanças contra padrões e políticas com foco crítico. O Integrator coordena merge, testes e deploy sem escrever código ele mesmo. Eles alcancam 96% de sucesso na primeira passagem com retries limitados e escalação humana para os casos restantes.

Arquitetura multi-agent é mais cara do que usar um agente único?

Sistemas multi-agent custam mais em inferencia bruta (aproximadamente 2-3x por tarefa), mas são mais baratos por tarefa concluida com sucesso porque suas taxas de sucesso são dramaticamente maiores. A Factory reporta que seu sistema multi-agent produz resultados bem-sucedidos a $0,29 por tarefa versus $0,39 por tarefa na baseline de agente único. O ponto de equilíbrio e aproximadamente uma melhoria de 15% na taxa de sucesso, que sistemas multi-agent bem-projetados consistentemente excedem.

Leitura relacionada

• What Is a Product Engineer?
• Don't Build Agents, Build Skills
• Context Engineering: The Skill That Replaced Prompt Engineering
• No Vibes Allowed: Solving Hard Problems in Complex Codebases
• Collaborative AI Engineering