Amazon Bedrock AgentCore e MCP stateful
TL;DR
A Amazon Bedrock AgentCore Runtime passou a tratar MCP server como fluxo com estado, em vez de uma sequência solta de chamadas. Na prática, isso dá continuidade por sessão com Mcp-Session-Id, permite pedir informação ao cliente durante a execução e abre espaço para notificações de progresso em tarefas longas. Para quem constrói agentes e automações sobre AWS, a mudança reduz retrabalho em fluxos multi-turn e facilita operar experiências interativas sem recomeçar do zero a cada chamada.
O que mudou no AgentCore Runtime
O ponto central é a passagem de um uso mais estático do MCP para um modelo stateful no servidor. A atualização do AWS What’s New e a documentação oficial do Bedrock AgentCore descrevem suporte a elicitation, sampling e progress notifications quando a sessão é mantida com contexto.
Isso importa porque vários usos de agente não cabem bem em um modelo “executo tudo e devolvo uma resposta final”. Em aplicações reais, o servidor pode precisar pedir um dado faltante, esperar confirmação humana ou informar andamento sem perder o contexto da interação. Com estado de sessão, o runtime consegue correlacionar essas etapas e reduzir o custo de reiniciar o fluxo.
Mcp-Session-Id como chave de continuidade
O identificador de sessão é a peça que liga as interações. A doc de deploy de MCP servers no AgentCore Runtime explica que o runtime pode até adicionar Mcp-Session-Id automaticamente quando o cliente não envia, para preservar a continuidade. Já a página de stateful features mostra que as capacidades stateful dependem dessa correlação.
O efeito prático é simples: chamadas sucessivas passam a “enxergar” o mesmo contexto. Em vez de tratar cada request como uma execução isolada, o servidor pode manter o fio da conversa, o que é útil quando a tarefa envolve validação humana, busca de dados ou uma sequência longa de passos com dependências.
Elicitation: quando o servidor precisa perguntar antes de seguir
Elicitation é o comportamento em que o servidor solicita informação adicional ao cliente durante a execução. A documentação da AWS posiciona isso para fluxos em que faltam dados ou confirmação. Em vez de falhar e obrigar o usuário a reiniciar, o servidor pausa, pergunta e continua quando recebe a resposta adequada.
Esse padrão é valioso em cenários como reserva, cadastro, aprovação ou execução de ação sensível. Em um fluxo de automação, por exemplo, isso evita perder estado entre a etapa que detecta a lacuna e a etapa que recebe o complemento. A documentação oficial do AWS Machine Learning Blog contextualiza essa lógica no conjunto de capacidades stateful para agentes interativos.
Sampling: o cliente ajuda a gerar sem quebrar a sessão
Sampling permite que o servidor peça ao cliente um trecho gerado com base no contexto da sessão. Isso aparece nos materiais da AWS como parte do pacote de features stateful e amplia o papel do cliente no ciclo de execução. Em vez de o servidor concentrar toda a geração, a sessão permite cooperar com o lado cliente quando isso faz sentido para o fluxo.
Na prática, essa abordagem faz sentido quando a interface cliente já tem contexto de produto, de usuário ou de política interna que vale incorporar na geração. O ganho é combinar estado de sessão com geração assistida, sem desmontar o fluxo entre uma chamada e outra.
Progress notifications em tarefas mais longas
Para operações demoradas, o runtime também passa a suportar progress notifications. A nota oficial da AWS e o sample de tarefas longas mostram esse uso para manter o usuário informado enquanto o trabalho avança.
Esse detalhe é mais importante do que parece. Em automações que envolvem múltiplas etapas, a ausência de feedback costuma ser interpretada como travamento. Com notificações de progresso, o agente consegue expor sinais de vida durante a execução e reduzir a necessidade de timeout artificial, polling agressivo ou recomeço desnecessário.
Isolamento por sessão e concentração de contexto
A AWS também destaca o isolamento da sessão stateful em ambiente próprio. Isso ajuda a evitar que estado de uma execução contamine outra, o que é essencial quando há múltiplos usuários, ferramentas e passos de longa duração. O comportamento é coerente com a proposta de agent runtime: cada sessão mantém seu histórico funcional, mas sem misturar contexto entre chamadas independentes.
Na engenharia do agente, isso simplifica bastante o desenho de fluxos multi-turn. Você pode modelar a sessão como uma unidade operacional: começa, acumula contexto, negocia entradas faltantes, executa passos longos e encerra. Para times que já sofreram com duplicidade de requests, retry mal calibrado ou perda de contexto entre frontend e backend, o ganho é bem concreto.
Como isso encaixa em arquiteturas de agente
Se você já desenhou integração entre LLM, ferramentas e backend, sabe que a maior dor costuma estar na coordenação do estado. O MCP stateful entra justamente nessa camada de coordenação. Ele não substitui seu domínio, mas reduz a quantidade de cola que você precisa escrever para manter sessão, progresso e interação humana alinhados.
Um exemplo útil é separar três responsabilidades: o agente decide, o runtime preserva a sessão e o cliente interage com o usuário. Essa separação reduz acoplamento e facilita observabilidade. Quando o fluxo precisa pedir mais contexto, o servidor não “esquece” o que vinha fazendo; quando a operação demora, o cliente recebe sinais de andamento; quando a geração depende do lado cliente, a sessão continua íntegra.
Esta seção descreve a versão atual do AgentCore Runtime para MCP stateful. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Outro ponto é que essa evolução deixa menos frágil o desenho de ferramentas compostas. Em vez de fazer um tool único gigante, você pode decompor passos e confiar que a sessão vai preservar o contexto necessário para seguir em frente. Para quem usa AWS Step Functions, isso também ajuda a imaginar agentes como participantes de um fluxo maior, e não como funções isoladas.
Por que importa pro dev brasileiro
Há um motivo muito concreto para isso pesar no Brasil: latência e custo. Em muitos times daqui, o backend está em AWS em região fora da América do Sul, com tráfego indo para us-east-1 por padrão. Quando um fluxo de agente precisa de várias idas e vindas, cada reexecução desnecessária aumenta latência percebida e gasto operacional em dólar.
O stateful MCP reduz parte dessa fricção porque preserva o contexto da interação em vez de obrigar o cliente a reconstruí-lo a cada etapa. Isso tem impacto direto em produtos com times enxutos, orçamento em BRL e necessidade de lançar features sem multiplicar chamadas e retries. Em empresas brasileiras que lidam com suporte, operações internas ou automação de atendimento, esse tipo de economia aparece rápido no custo do fluxo e na experiência do usuário.
Outro fator específico do contexto brasileiro é compliance. Quando o fluxo manipula dados pessoais, decisões assistidas ou aprovações, a LGPD exige cuidado com minimização, finalidade e controle de acesso. Um runtime que mantém sessão isolada e evita contaminação de contexto entre usuários ajuda a desenhar guardrails mais claros, principalmente em projetos que começam pequenos e depois precisam ganhar governança para atender jurídico, segurança e auditoria.
Como pensar adoção sem complicar a arquitetura
O melhor ponto de partida é escolher um caso de uso que já tenha troca de mensagens, espera humana ou execução demorada. Fluxos como assistência interna, triagem de solicitações, reserva de recursos, análise guiada ou atualizações operacionais são candidatos naturais. Nesses casos, o ganho do estado aparece rapidamente porque o fluxo real já não é linear.
Depois, vale observar onde o contexto está sendo guardado hoje. Se está espalhado entre frontend, backend e fila, o Mcp-Session-Id pode virar a chave única que simplifica esse trânsito. Se existe expectativa de resposta longa, as notificações de progresso evitam que o usuário abandone a tarefa por silêncio. E se o fluxo exige perguntas no meio, a elicitation reduz o número de reinícios manuais.
Para produção, o cuidado mais importante é tratar a sessão como recurso com ciclo de vida. A própria documentação da AWS indica que expiração ou reinício podem exigir re-inicialização da sessão, o que significa que você deve planejar timeout, retry e retomada com parcimônia. A boa notícia é que a semântica ficou mais explícita; a ruim é que não dá para fingir que sessão stateful é sinônimo de memória infinita.
Conclusão
O suporte stateful de MCP no Amazon Bedrock AgentCore Runtime muda o desenho de agentes para tarefas realmente interativas. Em vez de encaixar mutações, perguntas e progresso em chamadas sem memória, agora dá para organizar a execução em torno de uma sessão que preserva contexto e conversa com cliente e usuário ao longo do caminho.
Se você trabalha com AWS e quer validar esse padrão em menos de uma hora, abra a documentação oficial de deploy de MCP servers no AgentCore Runtime, identifique um fluxo do seu produto que hoje reinicia do zero e redesenhe-o para carregar Mcp-Session-Id do início ao fim.
Conteúdos da DIO para quem quer aprofundar
- AWS - Agentes de IA em Campo — trilha prática para criar soluções com Amazon Bedrock, agentes autônomos, automação de fluxos e projetos aplicados no ecossistema AWS.
- Nexa - Fundamentos de IA Generativa com Bedrock — introduz fundamentos de IA generativa usando serviços como Amazon Bedrock, PartyRock, Amazon Nova e AgentCore.
- Formação AWS Cloud Foundations — base de cloud na AWS para entender serviços, arquitetura, segurança e boas práticas de infraestrutura.
- Santander - EducaIA — conteúdo voltado a aplicações de inteligência artificial com foco em uso prático e construção de projetos.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
