Como É de Verdade um Sistema Multiagente em Produção

A expressão sistema multiagente é usada para muitas coisas, a maioria delas pequena. Dois prompts chamando um ao outro num notebook não é um sistema multiagente. Tampouco é um único modelo a quem se pede que interprete vários papéis em uma longa conversa. O que entendemos por isso, e o que é preciso para rodar um em produção, é um conjunto de agentes distintos, cada um dono de uma etapa de trabalho real, que fazem handoff entre si de forma controlada e entregam um resultado em que um time pode confiar. Este texto descreve como isso é na prática, usando o Hermes, nosso próprio sistema multiagente de codificação, como exemplo trabalhado.

O Hermes planeja, escreve, testa e move software em direção à implantação, com pessoas revisando nos pontos que importam. Ele está no ar e constrói sistemas reais. Essa última parte é o ponto central. Uma demo responde se os agentes conseguem fazer uma tarefa. A produção faz uma pergunta mais difícil: eles conseguem fazê-la de forma confiável, dia após dia, de um jeito em que um time confie o suficiente para deixar rodando.

Agentes especializados, não um modelo usando vários chapéus

A primeira escolha de projeto é dividir o trabalho. Entrega de software não é uma única tarefa. É planejar uma mudança, escrever o código, testá-lo e levá-lo com segurança em direção à produção. Cada uma dessas etapas recompensa uma postura diferente. Planejar pede amplitude e cautela. Escrever pede foco em uma mudança estreita e bem especificada. Testar pede desconfiança, uma busca deliberada pelo que está errado, e não a confirmação de que algo funciona.

Então, no Hermes, essas etapas são conduzidas por agentes separados, em vez de um único modelo a quem se pede que faça tudo de uma vez. Um agente de planejamento transforma uma instrução em uma mudança concreta e delimitada. Um agente de escrita implementa essa mudança contra a base de código. Um agente de testes verifica o resultado e tenta quebrá-lo. Dividir o trabalho mantém a função de cada agente pequena e legível, e é isso que torna a saída dele revisável. Também significa que um passo fraco aparece como um passo fraco, não como uma falha vaga em algum lugar dentro de uma conversa de mil linhas.

Os handoffs são a arquitetura

Se os agentes são as peças, os handoffs entre eles são o sistema. A engenharia difícil em um arranjo multiagente não são os prompts. É o que passa de uma etapa para a seguinte, e se a etapa seguinte pode confiar nisso.

Tratamos cada handoff como dado estruturado, não como texto livre. O agente de planejamento não entrega ao agente de escrita um parágrafo de intenções. Ele repassa um formato definido: o que está mudando, onde e o que o resultado deve satisfazer. Analisamos isso contra um schema estrito antes que o próximo agente sequer veja, então uma saída malformada ou pela metade é interceptada na fronteira em vez de virar código ruim três passos depois. O mesmo vale para o que sai das etapas de escrita e de testes. As saídas são validadas, não presumidas.

• Cada etapa produz uma saída definida e analisável, não uma prosa que a próxima etapa tem que interpretar.
• As saídas são validadas contra um schema na fronteira, então um resultado ruim falha cedo em vez de se propagar.
• Cada handoff é registrado, então o caminho da instrução até a mudança entregue pode ser reconstruído passo a passo.
• A escolha do modelo é por etapa: o modelo certo é roteado para cada tarefa, e ele pode ser trocado sem reescrever o sistema.

É também daqui que vem a confiabilidade. Um agente de prompt único e longo falha de formas difíceis de localizar. Um pipeline de handoffs validados falha em uma fronteira nomeada, com um registro do que entrou e do que saiu. Quando algo dá errado, e vai dar, você consegue ver exatamente qual etapa produziu o resultado ruim e por quê.

Portões de decisão: onde uma pessoa permanece responsável

Agentes fazerem o trabalho não significa agentes tomando cada decisão sem supervisão. O Hermes tem portões de decisão, pontos em que o sistema para e uma pessoa revisa e aprova antes de ele prosseguir. A habilidade está em colocar os portões nos lugares certos. Coloque um portão em cada passo e você reconstruiu um processo manual com latência extra. Não coloque portão em nada e você colocou um sistema sem supervisão que altera código de produção por conta própria.

Colocamos portões onde o custo de errar é mais alto e a ação é mais difícil de reverter: um plano antes de virar código, e uma mudança antes de avançar em direção à implantação. Passos de baixo risco e facilmente reversíveis rodam sozinhos, com o registro disponível depois. O resultado é que uma pessoa nunca está no circuito de tudo, mas está sempre responsável pelo resultado. Essa distinção, fazer o trabalho versus ser dono do resultado, é a que permite que um time realmente confie no sistema.

Os agentes fazem o trabalho. As pessoas permanecem responsáveis pelo resultado. Os portões de decisão são onde esses dois fatos se encontram, e acertar o posicionamento deles é a maior parte do projeto.

Como ele entrega software

Reunido tudo, uma execução pelo Hermes se parece com um processo de entrega, não com um chat. Uma instrução chega. O agente de planejamento a delimita em uma mudança concreta, que uma pessoa revisa no primeiro portão. O agente de escrita implementa o plano aprovado contra a base de código. O agente de testes verifica o resultado e procura por falhas. A mudança então espera em um segundo portão por uma pessoa que aprove antes de ela avançar em direção à implantação. Em cada etapa, as entradas, as saídas e as decisões são registradas, então nada do que o sistema fez fica sem prestação de contas depois do fato.

Nada disso é exótico. É a disciplina da entrega comum de software, delimitar, revisar, testar, aprovar, aplicada a um sistema cujos trabalhadores por acaso são agentes. Isso é deliberado. Os times que conseguem confiar em agentes são os que conseguem enxergar os mesmos controles em que já se apoiam, e não uma caixa-preta que produz commits.

Por que os construímos desse jeito

O Hermes é como colocamos à prova aquilo que recomendamos aos clientes. Os padrões nele, agentes especializados, handoffs validados, escolha de modelo como dependência substituível e portões com humano no circuito, são os mesmos que levamos ao trabalho com agentes para empresas reguladas. Não chegamos a eles porque soavam rigorosos. Chegamos a eles porque as alternativas, o prompt único e longo e o agente sem supervisão, não sobrevivem ao contato com a produção.

Um sistema multiagente em produção, então, não é um modelo mais inteligente. É uma arquitetura: agentes pequenos e especializados, handoffs estruturados e validados, portões colocados onde a reversibilidade se esgota, e um registro completo por baixo. O modelo é a parte que ganha as manchetes. A estrutura em volta dele é a parte que entra em produção.