MCP stateful sessions no AgentCore Runtime em produção
TL;DR
A Amazon Bedrock AgentCore Runtime passou a sustentar sessões MCP com estado, o que muda a forma de construir agentes que precisam pausar, pedir confirmação no meio do fluxo e devolver progresso em tempo real. Na prática, isso reduz a costura externa que antes era necessária em fluxos long-running e abre espaço para experiências mais controladas em produção, desde atendimento até automação de tarefas multi-step.
O que mudou no runtime
O ponto central é que o servidor MCP deixa de ser tratado apenas como algo stateless e passa a operar com session state, amarrado ao ciclo de vida da sessão. A documentação oficial da AWS descreve suporte a elicitation, sampling e progress notifications dentro desse modelo, com continuidade mantida por sessão e uso de Mcp-Session-Id para preservar contexto entre interações (documentação oficial, anúncio oficial).
Isso é relevante porque o protocolo passa a acomodar etapas que normalmente quebrariam o fluxo linear. Em vez de forçar tudo para uma única chamada longa, o servidor pode pedir uma informação extra, solicitar geração ao client e emitir updates enquanto trabalha. Para quem desenha agentes em AWS, a diferença é arquitetural: o estado deixa de ser um detalhe acoplado na aplicação e vira parte do contrato de execução (blog oficial).
Elicitation: perguntar no meio da execução
Elicitation é o mecanismo mais fácil de entender em termos práticos. O servidor começa uma ação, percebe que falta contexto ou que uma confirmação humana é necessária, e interrompe a continuidade para solicitar entrada adicional. Isso ajuda em casos como execução de fluxo caro, operações com risco operacional ou tarefas que dependem de validação do usuário antes do próximo passo (docs, blog).
O ganho está em evitar reprocessamento. Em vez de concluir um passo, falhar e reiniciar tudo por falta de um parâmetro, o agente preserva a sessão e continua de onde parou. Em produção, isso é especialmente útil quando o custo da ida e volta entre cliente, modelo e ferramenta é alto, ou quando a resposta correta depende de uma decisão humana no meio do caminho.
Sampling e progress notifications
Sampling permite que o servidor peça geração ao lado do client/LLM durante a execução, em vez de fazer todo o trabalho sozinho. Isso é útil quando o fluxo precisa de um texto intermediário, uma recomendação ou um rascunho padronizado para seguir adiante. A documentação do recurso e o anúncio oficial colocam sampling dentro do conjunto de capacidades stateful habilitadas no runtime (docs, anúncio oficial).
Já as progress notifications resolvem uma dor clássica em tarefas longas: o usuário não fica sem retorno enquanto a operação caminha. O servidor publica atualizações de progresso durante a execução, o que melhora observabilidade e experiência de uso em fluxos com busca, orquestração e múltiplas ferramentas (blog oficial, anúncio oficial).
Na prática, esses dois recursos combinados mudam a UX do agente. O client pode apresentar progresso, receber uma solicitação de geração e depois retomar a sessão com o contexto preservado. Para o desenvolvedor, isso reduz a necessidade de inventar um protocolo paralelo de callbacks, polling manual ou filas ad hoc só para atravessar uma tarefa de longa duração.
Como pensar o ciclo de sessão
O detalhe operacional mais importante é que a continuidade depende da sessão. A AWS indica que, quando a sessão expira ou termina, novas chamadas podem retornar 404 e o client precisa recomeçar com um novo identificador de sessão. Isso é um lembrete de que o estado é temporal e não deve ser tratado como memória infinita (docs oficiais).
Essa mecânica também ajuda a pensar em isolamento. Como o estado está associado à sessão, você reduz o risco de misturar contexto entre usuários ou entre tarefas paralelas. Em ambientes reais, isso é importante para governança e para evitar um problema comum em agentes: carregar resquícios de uma interação anterior para dentro de uma execução nova, algo que costuma ser difícil de depurar quando tudo é feito em um único loop stateless.
Esta seção descreve a versão atual do runtime e das capacidades MCP stateful. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Gateway e desenho de produção
Para produção, a AWS também posiciona o AgentCore Gateway como ponto de entrada para governança e roteamento, com suporte a streaming, session management, elicitation e primitives como prompts e resources (blog oficial). Isso sugere um desenho em camadas: o gateway concentra observabilidade e controle, enquanto o runtime executa os servidores MCP com estado.
Esse tipo de separação é útil quando você quer padronizar acessos, logs e credenciais sem esparramar responsabilidade pelos serviços internos. Em um time que mantém vários agentes, o gateway funciona como fronteira operacional: deixa o tráfego e o ciclo de sessão mais previsíveis, ao mesmo tempo em que mantém a semântica MCP necessária para o fluxo continuar.
Exemplo de leitura arquitetural
Um cenário simples ajuda a visualizar. Pense em um agente de suporte que precisa analisar um pedido, pedir uma confirmação antes de acionar um passo sensível e, durante a execução, informar o avanço ao usuário. Sem stateful MCP, isso vira uma combinação frágil de estados externos, polling e lógica paralela. Com session state, elicitation e progress, o próprio protocolo carrega a continuidade do processo (blog oficial, docs oficiais).
O caminho mais seguro é tratar a sessão como uma unidade de trabalho com começo, meio e fim. Isso vale tanto para agentes internos quanto para integrações com interfaces que o time controla. Se a execução pode durar vários segundos ou envolver uma pergunta intermediária, vale modelar explicitamente que o servidor pode pausar e retomar, em vez de assumir uma resposta monolítica.
Por que importa pro dev brasileiro
Esse tipo de recurso conversa bem com a realidade de muitos times no Brasil, especialmente em fintechs, bancos e SaaS que operam com integrações sensíveis e orçamento apertado. O Brasil também tem exigências concretas de governança por causa da LGPD, então ações como confirmação intermediária, isolamento por sessão e controle do que o agente pode pedir ou processar reduzem risco de tratamento indevido de dados pessoais (LGPD).
Outro ponto prático é infraestrutura. Muitos times brasileiros ainda têm dependência de regiões específicas da AWS em cenários de menor latência ou de integração com legados, e qualquer fluxo de agente que fique “cego” durante uma operação longa tende a piorar percepção de qualidade. Progress notifications e retomada por sessão ajudam a construir uma experiência mais previsível para produto, suporte e operação, sem exigir que o usuário fique esperando em silêncio.
O que testar primeiro
Se você quer avaliar isso em um projeto real, comece por um fluxo pequeno: uma tool que precise de confirmação humana no meio e outra que demore o suficiente para justificar progresso. Depois, verifique se o client preserva o Mcp-Session-Id, se o servidor consegue retomar corretamente e se a expiração da sessão está tratada como evento normal, não como falha inesperada (docs oficiais).
A partir daí, faça a integração com um gateway, se ele fizer parte da sua arquitetura, e documente onde o estado vive, por quanto tempo fica disponível e qual é o comportamento quando a sessão expira. Em produção, esse tipo de disciplina vale tanto quanto escolher o modelo certo.
Conclusão
O suporte a sessões MCP com estado no Amazon Bedrock AgentCore Runtime tira o agente do modo “uma chamada e pronto” e permite fluxos mais próximos do que times de produto de fato precisam: confirmação no meio, geração intermediária e feedback de progresso durante tarefas longas. Para produção, o ganho não é só conforto; é menos gambiarras de estado, menos reexecução e mais controle da experiência.
Se o seu time já usa AWS, o próximo passo mais útil é criar um protótipo com um tool simples que exija elicitation e retorne progress notifications, validando a continuidade por sessão do começo 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 e automação de fluxos em cenários reais.
- Nexa - Engenharia de Prompts na AWS com Claude — aborda fundamentos de prompt engineering e uso aplicado de IA generativa com Claude no ecossistema AWS.
- CrewAI Fundamentals — introduz o desenvolvimento de agentes colaborativos e a estrutura básica para construir automações com múltiplos agentes.
- Santander 2026 - AI Java Back-end — conecta backend Java, Spring Boot e IA generativa em um percurso voltado a aplicações modernas com integração externa.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
