Por que sistemas multiagente falham em silêncio mesmo passando na avaliação

O problema: falhas silenciosas que nenhuma avaliação enxerga

Existe um tipo de falha em sistemas multiagente que é pior do que um erro com código 500, porque ela não deixa nenhum rastro. É o caso do agente que recebe um 200 da API interna, monta um payload perfeitamente estruturado — só que vazio — e passa o resultado adiante como se tudo estivesse certo. O próximo nó da cadeia interpreta aquele vazio como “não há histórico”, redige uma resposta educada e envia ao cliente. Nada travou, nada estourou timeout, nenhum alerta disparou. E o sistema entregou uma decisão errada.

Um exemplo concreto usado no artigo é um sistema de triagem de tickets de suporte com três nós: um classifica a solicitação, outro consulta o histórico da conta e o terceiro redige a resolução. Quando o ID da conta se corrompe dois passos antes, o serviço de cobrança devolve silenciosamente um resultado vazio para uma conta que não conseguiu encontrar — e o nó de redação transforma isso em “não há nada a reembolsar”. O reembolso legítimo é negado, e ninguém percebe.

Por que as avaliações tradicionais são cegas para isso

O motivo é estrutural: a maioria das avaliações de agentes em produção olha apenas o texto final. Ele sai gramaticalmente limpo, profissional e coerente — e passa na rubrica. O problema é que todas essas checagens miram a mesma camada, a saída compilada, e nenhuma pergunta o que aconteceu entre o nó dois e o nó três.

O artigo faz uma comparação certeira: ninguém considera um aplicativo compilado como testado só porque a tela de login renderiza. Você testa a query por trás, o token emitido, a checagem de permissão. A interface é o último lugar onde um bug aparece, não o primeiro onde você procura. Com agentes, a gente faz exatamente o oposto: avaliação de “UI” num sistema que nem tem UI no sentido tradicional.

Os números sustentam a tese. O relatório State of AI Engineering 2026 da Datadog aponta taxa de falha em produção de cerca de 5% para requisições de IA — e apenas ~60% disso vem das falhas “barulhentas” por capacidade, as que aparecem como erro. O resto é a falha que conclui e ainda assim erra.

A solução: avaliar os estados intermediários

A correção não é mais uma rubrica no fim da cadeia, e sim mover parte da avaliação para dentro do pipeline, exatamente nas costuras onde a saída de um agente vira a entrada de outro. O autor chama isso de Intermediate State Eval — um “watchdog” leve posicionado entre os nós.

No exemplo da triagem, seria um checkpoint entre o nó que consulta o histórico e o que redige. A única pergunta que ele faz: este handoff parece plausível? O ID da conta no payload bate com o que foi solicitado? O resultado parece uma consulta real ou um valor padrão de fallback?

Três decisões de design tornam isso prático:

• Schema tipado com Pydantic em vez de dict solto — dá ao watchdog algo concreto para checar, em vez de adivinhar a estrutura a cada chamada.
• Modelo pequeno e local (o autor usa um modelo destilado de 1B rodando na mesma máquina) fazendo uma pergunta estreita e binária: plausível ou não. Não precisa ser inteligente, precisa ser rápido e barato.
• Veredicto binário com piso de confiança: se o JSON vier ilegível ou a confiança ficar abaixo do piso, o handoff é bloqueado — nunca “dá o benefício da dúvida”.

No código, o watchdog é uma função simples que recebe o payload de saída, o ID solicitado e devolve um veredicto estruturado. Se o resultado não for plausível, o pipeline levanta uma exceção no ponto exato da corrupção — em vez de deixar o e-mail errado ir três passos adiante em silêncio. Uma escalada de suporte que custava confiança vira uma sessão de debugging de poucos minutos.

O que isso custa (e por que não é bala de prata)

O autor é honesto sobre os três custos:

• Latência: para um pipeline de três nós, são duas chamadas de inferência extras no caminho crítico. Faz diferença quando tempo de resposta importa.
• Nova superfície de falha: um watchdog mal calibrado passa a rejeitar handoffs corretos, trocando corrupção silenciosa por falsos bloqueios que alguém precisa triar manualmente. Ajustar o limiar exige iteração real.
• Julgamento: nem todo nó merece um watchdog. Ele compensa onde o custo de errar é alto — logo antes de algo voltado ao exterior, como um e-mail que sai ou um reembolso que dispara.

O conselho final é pragmático: se você opera um pipeline multiagente, não comece pela frente da cadeia. Comece pelo último handoff interno antes de uma ação externa — o e-mail, a gravação de registro, a decisão que vira efeito real. Instrumente essa fronteira, rode por uma ou duas semanas e deixe o watchdog mostrar o que ele realmente pega antes de empurrar a arquitetura para trás. Você não precisa do sistema completo no primeiro dia.

A lição central vale para qualquer time que coloca agentes em produção: a falha cara nunca foi a barulhenta. É a que responde 200, se estrutura direitinho — e está semanticamente errada.