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

O Google publicou os quatro padrões de engenharia que apareceram nos vencedores do AI Agents Challenge. Nenhum deles é sobre modelo: são interface de ferramenta, mensageria assíncrona, validação estrutural e roteamento barato antes da inferência. Reviso cada um com o que muda ao levá-lo para AgentCore, EventBridge e Bedrock — e onde o protótipo do desafio não sobrevive à produção.

- URL: https://fernando.moretes.com/blog/quatro-padroes-de-engenharia-que-separam-multiagente-de-prompt-chain

- Markdown: https://fernando.moretes.com/blog/quatro-padroes-de-engenharia-que-separam-multiagente-de-prompt-chain/article.md?lang=pt

- Published: 2026-09-22T10:14:42.554Z

- Category: IA & Agentes

- Tags: ai-agents, mcp, event-driven, bedrock, agentcore, eventbridge, finops, resilience

- Reading time: 9 min

- Source: [4 engineering patterns behind the strongest AI Agents Challenge submissions](https://developers.googleblog.com/4-engineering-patterns-behind-the-strongest-ai-agents-challenge-submissions/)

---

O post do Google sobre o AI Agents Challenge diz uma coisa que eu levei anos para aceitar em plataformas financeiras: "multiagente" foi a alegação mais frequente entre milhares de submissões, e boa parte era um modelo só passando por uma cadeia de prompts com nomes de agente colados. Os que ficaram no topo de cada trilha repetiam quatro decisões de engenharia que não têm nada a ver com o modelo — e tudo a ver com quem opera o sistema quando o modelo principal devolve 503 às 2h da manhã.

## Os números que sustentam a review

- **40%+** — das mensagens resolvidas sem modelo. Primeira camada (regex, zero tokens) do time de roteamento em camadas, medida por eles mesmos
- **1** — função de validação para os dois modelos. `validate_clinical_response()` na saída do Gemini 3.1 Pro e do fallback Gemini 3.6 Flash
- **185 / 24h** — retries padrão do EventBridge por alvo. O que um bus gerenciado entrega de graça e quatro `asyncio.Queue` num processo não entregam

## O que o post é — e o que não é

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.

## Padrão 1: MCP bidirecional é uma decisão de superfície de ataque

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.

## Padrão 2: quatro filas num processo não são um event bus

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.

## Os quatro padrões numa única requisição

Uma mensagem entra, passa pelo roteamento em camadas, vira evento, aciona agentes em paralelo, cruza uma única função de validação e sai como tool MCP para outros agentes.

### 🟧 AWS — Roteamento em camadas (padrão 4)

- Camada 0: regex 0 tokens, >40% resolvido (edge)
- Camada 1: classificador ~10 tokens, temperature 0.1 (ai)
- Camada 2: modelo completo só o que sobrou (ai)

### 📡 AWS — Event bus (padrão 2)

- EventBridge CLINICAL.* por tópico (messaging)
- DLQ (SQS) após 185 retries / 24h (messaging)

### 🤖 Agentes — reação paralela

- Agente de compliance cruza interação medicamentosa (compute)
- Agente de mensageria idempotente por paciente (compute)
- Agente de despacho (compute)

### 🔐 Saída — mesma régua (padrões 3 e 1)

- Modelo primário 503 → fallback com backoff (ai)
- Modelo fallback mesma família ou menor (ai)
- validate_response() ponto único, sem atalho (security)
- AgentCore Gateway servidor MCP, JWT + audiência (security)

### Fluxos

- caller -> regex: mensagem
- regex -> cheap: não casou
- cheap -> full: ambíguo
- full -> bus: publica evento tipado
- bus -> compliance: ANOMALY_DETECTED
- bus -> messaging: COMPLIANCE_REPORT_READY
- bus -> dispatch: DISPATCH_REQUESTED
- bus -> dlq: entrega falhou
- compliance -> primary: inferência
- primary -> fallback: 503 / throttling
- primary -> validate: resposta
- fallback -> validate: resposta
- validate -> mcpsrv: só o que passou
- mcpsrv -> caller: tool MCP para outros agentes

## Padrão 3: o fallback passa pela mesma função ou não é fallback

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.

## Padrão 4: roteamento em camadas é FinOps aplicado a tokens

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.

## Onde os quatro padrões brilham

- **Contexto limitado por construção:** a tool devolve o plano de execução, não a tabela — o orçamento de tokens deixa de depender da disciplina de quem escreve prompt.
- **Latência deixa de ser aditiva:** compliance e mensageria acordam no mesmo evento; o agente mais rápido não espera o mais lento.
- **Fallback sem rebaixar a régua:** uma função de validação, dois modelos, nenhum atalho — o incidente não vira queda de qualidade invisível.
- **Custo cortado antes da inferência:** mais de 40% do tráfego resolvido por regex, com zero tokens e resposta auditável.
- **Raciocínio vira infraestrutura:** um servidor MCP é chamado por outros agentes sem segunda integração — desde que tenha audiência de token validada.

> **Onde o protótipo do desafio não sobrevive:** Três coisas quebram na primeira semana de produção. **Bus em memória:** quatro `asyncio.Queue` morrem com o processo, sem retry, sem DLQ e sem métrica de fila — troque por EventBridge ou SNS/SQS antes de ligar tráfego real. **Servidor MCP sem audiência:** aceitar qualquer bearer token válido é o confused deputy da especificação; valide `aud` por RFC 8707 e nunca repasse o token recebido ao banco. **Regex sem medição de erro:** a camada zero não custa tokens, então o erro dela não aparece em conta nenhuma — amostre e conte.

## Como adotar na AWS, na ordem que reduz risco

1. **Meça a camada zero antes de qualquer coisa** — Exporte uma semana de mensagens, rode a lista de regex offline e conte quantas casam e quantas casam errado. Sem esse número, o padrão 4 é opinião.

2. **Coloque o banco atrás de tools com resposta limitada** — Lambda por tool, IAM de leitura por tabela, N máximo de linhas e campos nomeados. É a metade interna do padrão 1 e o pré-requisito da externa.

3. **Troque a call chain por EventBridge com DLQ** — Um tópico por evento tipado, uma regra por agente, DLQ em SQS e chave de idempotência no `detail`. Mantenha o retry padrão (24h/185) até ter motivo para encurtar.

4. **Escreva a validação como função testada, depois ligue o fallback** — Primeiro inference profile cross-region contra throttling; só depois modelo alternativo. O `modelId` que respondeu vai para log e métrica com alarme.

5. **Exponha o servidor MCP por último, pelo AgentCore Gateway** — Inbound JWT com audiência validada, outbound com credencial por tool, e um único chamador externo na primeira semana. Superfície nova merece tráfego pequeno.

## Anti-padrões que o post insinua e eu já vi de perto

- **Multiagente de crachá:** um modelo, cinco prompts com nome de agente, latência somada e nenhum paralelismo — é um sistema single-thread com etiqueta nova.
- **Validação por caminho:** uma cópia para o primário, outra para o fallback; a segunda envelhece e o incidente sai pela porta menos vigiada.
- **Conexão crua no contexto:** `SELECT *` despejado no prompt; funciona no dataset de demo e estoura o orçamento de tokens na primeira tabela real.
- **Token passthrough:** o servidor MCP usa no banco o mesmo token que recebeu do agente — o downstream passa a confiar num token que nunca validou.

> **Nota do curador:** Se eu tivesse que escolher um dos quatro para implantar amanhã numa plataforma financeira, seria o padrão 3 — a validação única — porque é o único que protege contra um erro que o log não mostra. Os outros três economizam dinheiro ou latência; esse economiza um incidente com auditor. Eu faria a função de validação primeiro, com testes que rodam no CI contra respostas gravadas dos dois modelos, e só depois ligaria o fallback. A lição que carrego de anos de plantão: o caminho raro é o que roda no pior dia, e código que roda no pior dia precisa do mesmo teste que o caminho feliz.

## Veredito

O post vale como lista de verificação, não como arquitetura de referência: ele descreve corretamente o que separa multiagente de prompt chain e para antes da parte cara, que é operar. Adote os quatro padrões quando seu sistema tem agentes com tempos diferentes, um modelo que já devolveu 503 em produção e uma conta de inferência que alguém lê todo mês. Fique na call chain quando são dois passos, um modelo e nenhum SLO — o bus e a validação única custam manutenção que esse caso não paga. Na AWS, a tradução é EventBridge com DLQ, inference profile cross-region antes de trocar de modelo, e AgentCore Gateway só quando o chamador é um agente que você não controla.

**Rating:** 4/5

## Referências

- [Google Developers Blog — 4 engineering patterns behind the strongest AI Agents Challenge submissions (2 set 2026)](https://developers.googleblog.com/4-engineering-patterns-behind-the-strongest-ai-agents-challenge-submissions/)
- [MCP Specification 2025-06-18 — Authorization (OAuth 2.1, RFC 9728, RFC 8707, token passthrough)](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)
- [Amazon Bedrock AgentCore Gateway — inbound/outbound auth, alvos Lambda/OpenAPI/Smithy, busca semântica de tools](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html)
- [Amazon EventBridge — How EventBridge retries delivering events (24h / 185 tentativas)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rule-retry-policy.html)
- [Amazon Bedrock — Cross-Region inference (perfis geográficos e globais, sem custo de roteamento)](https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html)
- [Amazon Bedrock — Understanding intelligent prompt routing (responseQualityDifference, limites)](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html)
- [AWS Machine Learning Blog — Migrating multi-model AI agents to Amazon Bedrock AgentCore runtime (18 set 2026)](https://aws.amazon.com/blogs/machine-learning/migrating-multi-model-ai-agents-to-amazon-bedrock-agentcore-runtime/)