Amazon Bedrock AgentCore: tool use saiu do modo estático
TL;DR
O Amazon Bedrock AgentCore Runtime evoluiu de um padrão de tool use mais estático para sessões que conseguem pausar, pedir dados estruturados, solicitar geração ao cliente e reportar progresso durante tarefas longas. Na prática, isso aproxima agentes de um fluxo de trabalho conversacional, com integração mais natural entre backend, interface e observabilidade.
O que mudou no AgentCore Runtime
O ponto central dessa evolução é simples: a chamada de ferramenta deixou de ser apenas um request com resposta final. Com stateful MCP server features e com o suporte ao AG-UI protocol, o runtime passa a operar em sessões, com eventos intermediários e continuidade de contexto.
Isso aparece em três capacidades que importam para quem constrói agentes de produção: elicitation, para pausar e pedir input estruturado; sampling, para solicitar geração de texto ao cliente; e progress notifications, para expor andamento incremental em operações longas.
Stateful MCP: do comando isolado à sessão conversacional
No modelo mais tradicional, o servidor recebe uma entrada, processa e devolve saída. Isso funciona bem para tools curtas, mas fica limitado quando a tarefa exige confirmação humana, preenchimento de parâmetros faltantes ou múltiplas etapas com dependências de contexto.
O modo stateful do MCP no AgentCore Runtime muda esse formato. A documentação de stateful MCP server features mostra que a sessão passa a carregar estado e a preservar a conversa entre cliente e servidor, inclusive com configuração específica para habilitar esse comportamento em cenários que não devem ser tratados como uma única requisição HTTP sem memória.
Na prática, isso é útil para um agente de atendimento que precisa confirmar um CPF mascarado, um fluxo de compras que pede validação de endereço ou um assistente interno que depende de autorização antes de seguir. O ganho não é só ergonomia: é redução de retrabalho, porque o tool server não precisa “forçar” tudo para uma única resposta final.
Esta seção descreve o comportamento documentado em 2026 para o runtime e para o MCP stateful. APIs de IA e integrações de orquestração mudam rápido — confira os links oficiais antes de levar a arquitetura para produção.
Elicitation: pausar no meio da execução
Elicitation é a capacidade que mais altera o desenho de fluxo. Em vez de falhar quando falta um dado, o servidor pode pausar a execução e pedir algo estruturado ao client. Isso é importante porque evita uma classe comum de gaps: o agente já tem contexto suficiente para avançar, mas ainda precisa de uma confirmação objetiva.
Um exemplo típico é um workflow que monta uma ação sensível e, antes de executar, precisa de confirmação explícita ou de uma preferência operacional. Com elicitation, esse pedido vira parte do protocolo, não um workaround improvisado na aplicação.
Sampling: geração no cliente, sem acoplar credenciais no tool server
Outro ponto relevante é o sampling. Aqui, o servidor solicita ao client que produza texto com o LLM disponível no lado da aplicação. Isso desloca a geração para onde as credenciais e a política de uso podem estar centralizadas, em vez de exigir que toda tool carregue acesso próprio ao modelo.
Esse desenho é útil em stacks corporativas, porque separa responsabilidades: o servidor de ferramenta executa domínio e o client medeia a geração. Para times que já têm gateway, app web e política de acesso bem definida, isso encaixa melhor em governança.
Progress notifications: melhor experiência em tarefas longas
As progress notifications resolvem um problema recorrente: a sensação de “travamento” em tarefas de longa duração. Em vez de esperar a resposta final em silêncio, o ecossistema passa a propagar eventos incrementais durante a execução da tool.
Isso importa tanto para UI quanto para observabilidade. Um usuário vê que o agente está avançando; e a equipe técnica consegue instrumentar etapas como download, transformação, chamada externa e persistência sem improvisar logs fora de banda.
AG-UI: quando o agente fala com a interface em tempo real
O suporte ao AG-UI protocol leva a integração para outra camada. A proposta é tratar a UI como parte ativa da experiência do agente, com eventos orientados a interface, e não apenas como consumidor passivo de uma resposta final.
Para aplicações de produto, isso é relevante porque aproxima o comportamento do agente do que o usuário realmente percebe. Em vez de “submit e esperar”, a tela pode refletir estados intermediários, capturar interações durante a execução e manter a sessão viva enquanto a operação acontece.
A documentação de Deploy AG-UI servers in AgentCore Runtime mostra que a integração deixa de ser uma adaptação artesanal e passa a ter caminho oficial no runtime. Isso reduz a distância entre backend de agente e frontend, especialmente em apps com experiência conversacional ou com painéis de acompanhamento em tempo real.
O impacto arquitetural para tool use
Quando juntamos MCP stateful, AG-UI e progress notifications, o desenho de tool use muda de natureza. O agente deixa de ser apenas um orquestrador que chama APIs e passa a operar como uma sessão com memória, eventos e pontos formais de intervenção humana.
Isso facilita quatro padrões concretos: workflows multi-turn dentro de uma execução; pedidos de confirmação sem abandonar o contexto; geração delegada ao client; e feedback contínuo para o usuário. Em aplicações com etapas longas, esse conjunto evita a fragmentação entre backend, chat e frontend.
Para quem trabalha com integrações corporativas, o valor está na redução de gambiarras. Antes, era comum criar filas paralelas, flags de estado e polling para simular continuidade. Agora, parte dessa semântica aparece no protocolo e no runtime.
Exemplo de desenho de fluxo
Imagine um assistente interno que precisa abrir um chamado, consultar um sistema legado e montar um resumo para aprovação. Em um fluxo estático, a tool chama tudo em sequência e só responde no fim. Em um fluxo stateful, o servidor pode pedir uma confirmação quando um campo essencial estiver ausente, enviar progresso para a UI e retomar a execução depois que o usuário responder.
Essa diferença é especialmente útil quando o tempo de resposta depende de integrações externas. O usuário não fica olhando para um spinner sem contexto, e o agente não precisa fingir que avançou quando ainda está aguardando uma etapa do processo.
Na prática, o ganho vem menos de “fazer mais IA” e mais de modelar melhor o fluxo entre ferramenta, cliente e interface.
Por que isso importa pro dev brasileiro
No Brasil, essa evolução conversa diretamente com contexto de custo e latência. Muitos times ainda operam com orçamento em BRL apertado, usam regiões fora do país e precisam justificar cada chamada adicional em arquitetura de IA. Quando a experiência é mais longa, uma interface que mostra progresso e reduz reexecuções evita custo operacional desnecessário.
Há também o fator regulatório. Em cenários com dados pessoais, a LGPD exige cuidado com coleta, retenção e transporte de informações. Fluxos stateful bem desenhados ajudam a explicitar quando o usuário precisa confirmar algo e a separar o que é contexto de sessão do que é dado sensível persistido.
Outro ponto muito brasileiro é a realidade de times que montam produto com backend em uma stack heterogênea e frontend enxuto, muitas vezes em startups ou áreas digitais de bancos e varejo. AG-UI e progress notifications reduzem a necessidade de soluções paralelas só para “dar vida” à interface enquanto o agente trabalha.
O que observar antes de adotar
O primeiro cuidado é não extrapolar o protocolo para casos simples. Nem toda tool precisa ser stateful; para consultas curtas e estáveis, o desenho clássico continua suficiente. O estado deve existir porque há um requisito real de continuidade, e não porque a arquitetura ficou “mais moderna”.
O segundo cuidado é versionamento. Como o próprio ecossistema de IA evolui rápido, vale revisar a documentação oficial dos recursos de MCP no AgentCore Runtime e do AG-UI antes de transformar qualquer POC em produção.
Também é importante separar observabilidade de experiência do usuário. Progress notifications ajudam a UI, mas não substituem métricas, tracing e logs bem estruturados. Em operações longas, você continua precisando de sinais técnicos para diagnosticar falhas, timeouts e gargalos de integração.
Conclusão
O Amazon Bedrock AgentCore Runtime ampliou o tool use de um modelo de chamada-resposta para um modelo de sessão com intervenções formais, geração delegada e feedback contínuo. Para times que constroem agentes, isso abre espaço para experiências mais próximas de um fluxo de trabalho real e menos parecidas com uma sequência de APIs soltas.
Se você já usa AWS e quer sentir essa mudança na prática, abra a documentação oficial de Deploy MCP servers in AgentCore Runtime e leia, em seguida, a página de stateful MCP server features; em menos de 1 hora, você consegue mapear qual tool do seu sistema ganharia com elicitation, sampling ou progress notifications.
Conteúdos da DIO para quem quer aprofundar
- CI&T - Backend com Java & AWS — Domine o desenvolvimento backend profissional com Java e AWS. Aprenda desde os fundamentos da linguagem até a criação de APIs RESTful escaláveis com Spring Boot, integração com bancos de dados SQL e NoSQL, e deploy em nuvem com Amazon Web Services.
- XP Inc. - Cloud com Inteligência Artificial — Prepare-se para entender, implementar e otimizar soluções de IA Generativa, aplicando técnicas de engenharia de prompt eficientes, modelos de aprendizado de máquina e serviços de IA na nuvem.
- Nexa - Engenharia de Prompts na AWS com Claude — Trilha rápida para aplicar engenharia de prompts e melhorar seu uso de IA Generativa com foco em produtividade e no trabalho com Claude 3.
- AWS - Cloud Amazon Web Services — Jornada para entender os principais serviços de nuvem da AWS e consolidar bases úteis para arquiteturas modernas em cloud.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
