Notas de Campo

O que quebra num pipeline multiagente (e como limitamos o estrago)

18 de julho de 2026 · 7 min de leitura

Demos multiagente são fáceis. Sistemas multiagente que sobrevivem a execuções reais, redes instáveis, quotas de modelo e entrada hostil são outra disciplina. Construindo o Proposal Architect para o Google for Startups AI Agents Challenge 2026, a maior parte do nosso tempo de engenharia foi não em fazer os agentes conversarem, mas em limitar o que acontece quando eles falham.

Estas são as notas de campo: seis coisas que quebraram, por que quebraram, e o padrão que corrigiu cada uma.

1. A chamada que nunca volta

Sintoma: uma execução do pipeline congela num estágio e fica lá para sempre.

Causa raiz: uma chamada de modelo sem deadline. Sob carga, um endpoint de inferência ocasionalmente nem responde nem falha: ele simplesmente pendura, e um await sem limite transforma uma chamada lenta num pipeline morto.

Padrão: toda chamada de modelo ganha um timeout duro, e toda execução ganha um deadline geral duro. Recuperação só é possível quando a falha é detectável, e a falha só é detectável quando a espera tem limite.

2. Repetir tudo para consertar uma coisa

Sintoma: o último estágio falha, e o retry ingênuo re-executa o pipeline inteiro: lento, caro, e capaz de produzir uma proposta diferente daquela que quase deu certo.

Causa raiz: lógica de retry que trata o pipeline como uma unidade atômica.

Padrão: checkpoint de estado entre agentes e retry apenas do estágio que falhou. Quando o nosso compositor falhou, re-executamos só o compositor contra o estado já computado dos estágios anteriores; a arquitetura, as estimativas e o preço ficaram exatamente como aprovados.

3. A quota dos modelos preview acaba na pior hora

Sintoma: o pipeline morre no meio da demo com erros de quota.

Causa raiz: modelos em tier preview vêm com quotas apertadas e compartilhadas, que se comportam de forma muito diferente dos modelos GA sob execuções repetidas.

Padrão: rotear os caminhos críticos para modelos generally-available e reservar tiers preview ou premium para o único passo onde a qualidade visivelmente se compõe (no nosso caso, o agente arquiteto). Roteamento de tier é uma decisão de confiabilidade tanto quanto de custo.

4. O crítico que critica de memória

Sintoma: o crítico adversarial rejeita rascunhos válidos com afirmações sobre capacidades de modelos que estão simplesmente desatualizadas.

Causa raiz: um crítico ancorado na memória de treinamento alucina o presente.

Padrão: ancorar o crítico em fatos vivos (no nosso caso, um catálogo atual de modelos), para que as objeções dele referenciem a realidade em vez da lembrança.

5. O briefing é entrada hostil

Sintoma: nenhum, e esse é o problema: você raramente vê a injeção que funcionou.

Causa raiz: um briefing de cliente é texto controlado pelo usuário que flui para o contexto de todos os agentes. Isso o torna uma superfície de injeção.

Padrão: tratar o briefing como entrada não confiável. Endurecer os system prompts e validar tudo que o modelo produz na fronteira onde aquilo vira consequência. O nosso gate determinístico de preço rejeita números malformados independentemente do porquê: uma alucinação e um ataque recebem a mesma resposta.

6. O celular bloqueou e a execução "sumiu"

Sintoma: no mobile, o usuário recarrega no meio de uma execução e perde o pipeline que estava acompanhando.

Causa raiz: estado da execução vivendo na sessão do navegador.

Padrão: a execução pertence ao servidor; o cliente apenas a observa. Depois de um reload, a interface se reconecta à execução em andamento em vez de iniciar outra.

O metapadrão

Cada correção acima é a mesma correção com roupas diferentes: defina a fronteira, limite a espera, preserve o estado, ancore os fatos. Frameworks de agentes te dão a conversa entre modelos. A engenharia é tudo o que fica em volta.