4 padrões de engenharia que separam agente de IA de verdade de prompt com nome pomposo

O Google encerrou mais uma rodada do Google for Startups AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → Agents Challenge e, segundo o post publicado no Google Developers Blog por Sergio Villani, o rótulo mais frequente nas submissões foi "sistema multiagente". O problema: muita coisa marcada como multiagente era, na prática, "um único modelo passando por uma cadeia de prompts com nomes de agente pendurados". Os que chegaram ao topo de cada trilha repetiram o mesmo punhado de decisões de engenharia, e é isso que interessa para quem constrói: são padrões que não exigem time maior nem modelo mais novo.

Abaixo vão os quatro, com o que cada um resolve, o que ele substitui e onde não compensa.

Padrão 1: MCP nos dois sentidos

A maioria usou o Model Context Protocol (MCP) numa direção só: o agente chama um servidor de ferramentas para buscar dados. Uma das equipes fez os dois lados. O agente consumia um banco de telemetria através da própria camada de ferramentas MCP e, na sequência, expunha esse mesmo raciocínio como um servidor MCP que outros agentes podiam chamar diretamente, sem UI de chat feita para humano no meio.

A metade interna já vale por si. A versão ingênua desse agente rodaria um SELECT contra o banco de telemetria e despejaria todas as linhas no contexto do modelo, que é exatamente como uma única requisição estoura o orçamento de tokens numa base de produção. Passar por uma camada de ferramentas MCP dá ao agente meios de inspecionar e filtrar programaticamente, trazendo o plano de execução de um job ou um stack trace específico em vez da tabela inteira. O contexto fica pequeno o bastante para o modelo raciocinar de fato.

Essa mediação é também o que torna a metade externa segura. Uma ferramenta que só devolve uma resposta limitada e feita sob medida pode ser entregue a um chamador que você não controla; uma conexão SQL↳SQL64 conteúdosSQL Server – Como evitar SQL Injection?Data · mai 2019Azure SQL DB Managed InstanceData · abr 2019SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query)Data · abr 2019Ver tudo em Data → crua, nunca. Depois que o raciocínio do agente já mora atrás de uma interface de ferramentas, expor externamente vira só levantar um servidor MCP na frente das mesmas ferramentas. No caso descrito, um agente de código rodando no terminal ou na IDE conseguia perguntar diretamente ao agente de performance sobre um job específico, como chamaria qualquer outra tool. Ninguém precisou abrir dashboard, descrever o problema num chat e copiar a resposta de volta.

Uma interface de chat é um destino; um servidor MCP pode ser infraestrutura sobre a qual outros agentes constroem, sem que ninguém escreva uma segunda integração para eles.

O detalhe fácil de pular: no momento em que você serve um chamador que não controla, esse servidor precisa de controle de acesso de verdade. Quem alcança o servidor passa a chamar sua camada de raciocínio diretamente. Uma superfície de ferramentas que só o seu próprio agente usa não precisa pensar nisso; uma exposta ao mundo, sim.

Padrão 2: concorrência dirigida a eventos

A primeira versão de uma equipe era um pipeline linear: agente de sensores chamava o de compliance, que chamava o de mensagens ao residente, que chamava o de despacho. Funcionava como demo e desabava no caso real, que era detectar risco de queda por mudança na marcha, cruzar com um banco vivo de interações medicamentosas e avisar a pessoa certa antes que a janela de ação fechasse.

A correção foi um event bus assíncrono montado sobre quatro instâncias separadas de asyncio.Queue, uma por agente, cada uma com sua corrotina worker. Em vez de o Agente A chamar o B e esperar o retorno, os agentes publicam eventos tipados em tópicos nomeados e assinam os que lhes interessam. Uma queda de 15% ou mais na velocidade da marcha publica um evento CLINICAL.ANOMALY_DETECTED. O agente de compliance já está estacionado nesse tópico, pega o evento no instante em que dispara, cruza com o banco de interações e publica seu próprio CLINICAL.COMPLIANCE_REPORT_READY assim que termina, sem polling e sem esperar handoff explícito de ninguém a montante.

A diferença concreta entre cadeia de chamadas e event bus:

Esse formato compensa onde os agentes rodam em tempos genuinamente diferentes: um fazendo polling a cada poucos segundos, outro numa chamada de rede de meio segundo, outro que dispara uma vez só no fim. Encadeie tudo numa pilha única e o mais rápido fica preso atrás do mais lento. Como resume o post, "um sistema single-threaded vestindo um rótulo de multiagente" é justamente o que aparece quando um agente precisa esperar o outro para reagir ao mesmo sinal.

Padrão 3: fallback que ainda precisa passar na sua régua

O agente de raciocínio clínico de uma equipe rodava em Gemini 3.1 Pro. Sob carga real, o Pro começou a devolver 503. A resposta comum seria acoplar um loop de retry no mesmo modelo. Em vez disso, a equipe montou fallback para o Gemini 3.6 Flash com backoff e passou a resposta de qualquer um dos dois modelos pela mesma função de validação antes de aceitar: uma checagem de citação confirmando que a resposta nomeava uma diretriz clínica real, e não só linguagem médica plausível.

O ponto não é a existência do fallback, e sim onde a validação mora. Ela não está duplicada, uma cópia para o caminho primário e outra para o de fallback, onde é fácil atualizar uma e esquecer a outra. Existe uma única validate_clinical_response() que tanto o caminho do Pro quanto o do Flash são obrigados a chamar antes de qualquer resultado sair do agente. Depois que a resposta bate nessa função, não importa qual modelo a produziu: nenhum ganha atalho, e nenhum entrega uma resposta que falha na checagem só porque calhou de ser o modelo disponível na hora.

É isso que impede um fallback de rebaixar a régua sem ninguém perceber: não é lembrar de aplicar o mesmo padrão duas vezes, é tornar estruturalmente impossível aplicá-lo só uma. Se o trecho de código que roda depois do fallback disparar pula uma etapa de validação que o caminho primário tem, você está enviando dois produtos e testando um.

Padrão 4: roteamento em camadas antes da chamada cara

Custo de inferência é provavelmente a restrição mais discutida em IA agora: todo mundo quer raciocínio de modelo de fronteira sem preço de fronteira em cada requisição. Uma equipe mediu o que realmente comia o orçamento e descobriu que não eram as perguntas difíceis, e sim as fáceis ("onde está meu pedido", "cancelar meu agendamento") passando pela mesma chamada completa de modelo que pedidos genuinamente ambíguos.

A solução foi um classificador de três camadas na frente do agente:

1. Regex local captura intenção navegacional a zero token.
2. Caso ambíguo vai para uma chamada barata ao Gemini a 10 tokens e temperature 0.1, só para classificar intenção.
3. Só o que sobrevive às duas etapas chega ao modelo de raciocínio completo.

Pela medição da própria equipe, a primeira passada sozinha resolveu mais de 40% das mensagens antes de qualquer chamada a modelo de verdade. Outra submissão aplicou a mesma ideia com um modelo rápido e barato triando o caso e escalando para o modelo lento e caro só o que precisa de raciocínio profundo. A lição é simples: não gaste seu modelo mais caro numa decisão que um mais barato já resolve. Antes de assumir que precisa de modelo maior, olhe a distribuição do seu tráfego.

O que isso muda pra quem constrói no Brasil

Nenhum dos quatro padrões depende de time grande ou modelo novo, e eles compõem bem entre si. O post destaca uma equipe que combinou os padrões 1 e 3 no mesmo build: um agente raiz espalhando especialistas em paralelo e depois expondo toda essa camada de raciocínio como servidor MCP chamável por outros agentes.

Vale o registro do viés da fonte: o Google observa que os padrões apareceram com mais frequência nas submissões construídas sobre o Agent Development Kit (ADK) e conduzidas pela Agents CLI, "porque o framework não briga com você em concorrência, fallback ou passar uma tool para outro agente". Traduzindo para o dev cético: os padrões são agnósticos de framework (event bus com asyncio, uma função de validação compartilhada, um classificador com regex e uma chamada barata rodam em qualquer stack Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) →), mas o post é do fabricante do ADK, então trate a recomendação de ferramenta como o que ela é.

O recado central sobrevive à propaganda: a diferença entre um agente de verdade e um pipeline de prompts com crachá está em decisões de arquitetura banais de engenharia de software, controle de acesso, concorrência, validação única e roteamento por custo, não em qual modelo você chamou.

Fonte: Google Developers Blog