Quatro padrões de engenharia que separam multiagente de prompt chain

O texto de Sergio Villani (Google Cloud AI, 2 de setembro de 2026) não é anúncio de produto, é um relatório de banca. Ele descreve, sem nomear times, o código real de quem venceu: um agente de telemetria que é cliente e servidor MCP ao mesmo tempo; um pipeline clínico refeito sobre quatro asyncio.Queue; um agente de raciocínio clínico que sobreviveu aos 503 do Gemini 3.1 Pro caindo para o 3.6 Flash sem baixar a régua; e um roteador de três camadas em que o modelo caro só entra quando regex e um classificador de dez tokens já desistiram.

A pergunta que vale reenquadrar não é "esses padrões funcionam?", funcionaram, tem submissão pontuada provando. A pergunta é: o que sobrevive quando o protótipo sai da máquina do hackathon e vai para uma conta AWS com auditoria, SLO e conta de Bedrock no fim do mês? É essa a lente da review. Cada padrão abaixo tem uma versão que cabe num notebook e uma versão que aguenta plantão; o post descreve a primeira e insinua a segunda.

Depois de 16 anos operando plataformas financeiras, o que me chamou atenção foi outra coisa: nenhum dos quatro padrões é novo. Interface de ferramenta em vez de conexão crua, pub/sub em vez de call chain, validação em ponto único, roteamento barato antes do caro, isso é engenharia de sistemas distribuídos de 2010 com outro vocabulário. O que mudou é o custo do erro: uma call chain lenta antes atrasava uma tela; agora ela multiplica tokens.

A metade interna do padrão é a que mais vale em produção. O agente vencedor não fazia SELECT * na base de telemetria e despejava linhas no contexto, ele acessava a base por uma camada de tools MCP que devolvia o plano de execução de um job ou um stack trace específico. É o que mantém o contexto pequeno o bastante para raciocinar e o que impede que uma única pergunta consuma o orçamento de tokens do dia. Em sistemas financeiros eu vou mais longe: a tool devolve resposta limitada por contrato (N linhas, campos nomeados, sem colunas de PII), porque é isso que o auditor vai ler.

A metade externa é onde o post acerta e para cedo. Expor o mesmo raciocínio como servidor MCP transforma um chat em infraestrutura, outro agente, num IDE, pergunta sobre um job sem ninguém abrir dashboard. Só que "esse servidor precisa de controle de acesso real" é uma frase; a especificação MCP de 2025-06-18 é um contrato: o servidor é resource server OAuth 2.1, publica metadata por RFC 9728, responde 401 com WWW-Authenticate, e deve rejeitar token cuja audiência não seja ele (RFC 8707). Token passthrough é proibido explicitamente, o servidor não repassa ao banco o token que recebeu do agente.

Na AWS, o AgentCore Gateway já entrega as duas metades: autenticação inbound (JWT/OAuth) e outbound (injeção de credencial por tool), alvos Lambda, OpenAPI e Smithy convertidos em tools MCP, e busca semântica de ferramenta para o catálogo não estourar o prompt. Use-o quando o chamador é um agente que você não controla. Se só o seu agente chama, um Lambda atrás de IAM com aws:PrincipalTag resolve, e custa menos para manter.

O caso clínico é o melhor argumento do post. A versão linear, monitoramento chama compliance, que chama mensageria, que chama despacho, passou na demo e quebrou no uso real: detectar risco de queda por variação de marcha, cruzar com base de interação medicamentosa e avisar alguém antes de fechar a janela de ação. Numa call chain a latência é aditiva; num bus por tópico, dois agentes que não dependem um do outro rodam no mesmo instante. Uma queda de 15% na velocidade de marcha publica CLINICAL.ANOMALY_DETECTED; o agente de compliance já está estacionado no tópico e publica CLINICAL.COMPLIANCE_REPORT_READY quando termina, sem polling, sem handoff explícito.

O que o post chama de event bus é quatro asyncio.Queue, uma por agente, cada uma com sua corrotina. Isso é um bus dentro de um processo: o processo reinicia, os eventos em voo somem; um consumidor trava, ninguém sabe; não há retry, DLQ nem ordem garantida. Serve para o desafio. Para produção eu troco por EventBridge, o padrão de retry por alvo é 24 horas e até 185 tentativas com backoff exponencial e jitter, e a DLQ recebe o que esgotar, ou por SNS com fan-out para uma SQS por agente quando preciso de ordem por chave (FIFO com MessageGroupId = paciente).

Dois detalhes que a versão em memória esconde: idempotência, porque um bus gerenciado entrega pelo menos uma vez e o agente de mensageria não pode avisar a família duas vezes; e schema do evento, porque "evento tipado" em Python é uma dataclass, e entre serviços é um contrato versionado em EventBridge Schema Registry. Quem esquece o segundo descobre na primeira mudança de campo.

O time de raciocínio clínico viu o Gemini 3.1 Pro devolver 503 sob carga real. A resposta comum seria retry contra o mesmo modelo; eles caíram para o Gemini 3.6 Flash com backoff. O detalhe que vale roubar não é o fallback, é onde mora a validação: uma única validate_clinical_response() que os dois caminhos são obrigados a chamar, checando se a resposta cita uma diretriz clínica real e não linguagem médica plausível. Não é "lembrar de aplicar a régua duas vezes"; é tornar estruturalmente impossível aplicá-la uma só.

Eu já vi a versão errada desse padrão em plataforma de pagamentos: validação duplicada por caminho, uma cópia atualizada num sprint, a outra esquecida, e a resposta de menor qualidade saindo pelo caminho "raro" durante um incidente, exatamente quando ninguém está olhando. A lição dura: fallback sem validação compartilhada é rebaixamento silencioso de SLO, e rebaixamento silencioso é o pior tipo em ambiente regulado, porque o log diz 200.

No Bedrock a primeira linha de defesa contra 503 e ThrottlingException nem é trocar de modelo: é chamar por inference profile cross-region (us., eu., apac.), que roteia para outra região da mesma geografia sem custo adicional de roteamento, o preço é o da região de origem, e o CloudTrail registra additionalEventData.inferenceRegion para a auditoria. Só quando isso esgota eu troco de modelo, e aí três regras: o modelId que respondeu vai para o log estruturado e para uma métrica (fallback_ratio com alarme acima de 5%); a validação é uma função com testes próprios, não um trecho de prompt; e o fallback nunca recebe ferramentas que o primário não recebia.

O time que olhou a própria conta de inferência achou o que todo mundo acha: "onde está meu pedido" e "cancela minha consulta" passando pela mesma chamada completa que uma pergunta genuinamente ambígua. A resposta foi três camadas, regex para intenção navegacional (zero tokens), uma chamada barata ao Gemini com dez tokens de saída e temperature 0.1 para o ambíguo, e o modelo de raciocínio só para o resto. A primeira camada sozinha resolveu mais de 40% das mensagens, por medição deles, antes de qualquer modelo ser tocado.

É o mesmo princípio de todo custo de manutenção que eu aplico a plataforma de dados: o processamento mais barato é o que não acontece. A camada zero é determinística, testável com uma tabela de casos, e auditável, em ambiente com BACEN ou LGPD na mesa, poder dizer "essa resposta não passou por modelo" tem valor próprio. O risco é o inverso: regex generoso demais classifica errado sem custar nada, e erro grátis não aparece em dashboard de custo. Meça a taxa de "regex acertou" com amostragem humana, não só o volume.

A versão gerenciada na AWS é o Intelligent Prompt Routing do Bedrock: um endpoint que prevê a qualidade de resposta de dois modelos da mesma família e roteia pelo responseQualityDifference que você configura, com modelo de fallback como âncora. Serve como camada 1 ou 2, não como camada 0, ele ainda gasta tokens, e tem três limites documentados: é otimizado só para inglês, exige exatamente dois modelos da mesma família e não aprende com a performance da sua aplicação. Para o português das minhas cargas, a camada zero continua sendo regex e a camada um continua sendo um classificador meu, com maxTokens de dez e a lista de intenções versionada no repositório.