AWS Bedrock AgentCore com sessões MCP stateful
TL;DR
O Amazon Bedrock AgentCore Runtime passou a suportar recursos stateful de MCP em produção, com foco em sessão, afinidade e continuidade de contexto. Na prática, isso muda a forma de desenhar servidores MCP: em vez de tratar cada chamada como isolada, você passa a pensar em ciclo de vida de sessão, propagação de `Mcp-Session-Id` e suporte a elicitation, sampling e progress notifications.
Esse padrão importa porque reduz a fricção de manter estado entre chamadas e abre espaço para experiências mais ricas em ferramentas de IA. Para equipes no Brasil, isso é especialmente relevante quando o agente precisa conversar com fluxos longos, integrar backends corporativos e respeitar requisitos de dados e auditoria em ambientes regulados.
O que mudou no AgentCore Runtime
A camada de runtime do AgentCore ganhou suporte explícito a stateful MCP server features, incluindo elicitation, sampling e notificações de progresso durante a execução de tools. O anúncio oficial da AWS e a documentação do contrato MCP descrevem que a plataforma usa `Mcp-Session-Id` para preservar a continuidade da sessão e rotear chamadas para a mesma microVM associada ao contexto.
Na prática, isso significa que um servidor MCP hospedado no AgentCore não precisa ficar “adivinhando” qual conversa está em andamento. O estado fica ancorado em uma sessão, e o cliente ou gateway reutiliza o mesmo identificador nas chamadas subsequentes para preservar contexto e afinidade.
Fontes primárias: AWS What’s New, MCP protocol contract.
Como a sessão funciona no Gateway e no Runtime
A documentação do gateway mostra o ciclo básico: habilitar `sessionConfiguration` em `protocolConfiguration.mcp`, inicializar a sessão e capturar o `Mcp-Session-Id` retornado no header da resposta. Depois disso, o mesmo identificador deve ser propagado nas chamadas seguintes para manter o encadeamento das tool calls e a continuidade do fluxo.
Já no runtime, a plataforma também pode adicionar `Mcp-Session-Id` automaticamente em requisições sem esse header, o que ajuda a manter compatibilidade com clientes MCP. O ponto principal, porém, é o mesmo: se você quer estado consistente, trate o session id como parte obrigatória do contrato de integração.
Essa abordagem fica bem natural em arquiteturas com um gateway na frente do MCP server. O gateway inicia a sessão, segura o contexto e repassa o identificador ao cliente, enquanto o runtime garante a afinidade com a microVM correta.
Fonte primária: Use MCP sessions with your AgentCore gateway, Deploy MCP servers in AgentCore Runtime.
Por que `Mcp-Session-Id` importa mais do que parece
Em sistemas MCP sem sessão bem definida, cada tool call tende a ser tratada como unidade isolada. Isso funciona para consultas simples, mas complica fluxos em que o servidor precisa lembrar uma etapa anterior, aguardar uma resposta parcial do usuário ou notificar progresso em tarefas demoradas.
No AgentCore, o `Mcp-Session-Id` cumpre duas funções ao mesmo tempo: identifica a sessão e ajuda no roteamento sticky para a mesma microVM. Essa combinação é o que torna viável manter estado de execução sem depender exclusivamente de memória externa para tudo.
O desenho prático é direto: primeira chamada sem `Mcp-Session-Id`, captura do header de resposta, e reaproveitamento do mesmo valor nas próximas requisições. Parece detalhe de transporte, mas na implementação é o que sustenta a continuidade da experiência.
Fonte primária: MCP protocol contract.
Onde entram elicitation, sampling e progress notifications
Os novos recursos stateful citados pela AWS ampliam o que um MCP server pode pedir ao cliente durante a execução. Elicitation permite solicitar input do usuário no meio do fluxo; sampling permite pedir ao cliente gerar texto com um LLM; progress notifications servem para operações longas que precisam de feedback intermediário.
Esse trio é relevante para experiências reais de agente porque evita um servidor silencioso e “travado” enquanto executa uma tarefa longa. Em vez disso, o servidor pode pedir mais dados, reduzir ambiguidades ou informar que ainda está trabalhando, sem perder o contexto da sessão.
Para equipes que operam atendimento, busca, booking ou automação corporativa, isso muda o desenho da ferramenta. O agente deixa de ser só um chamador de API e passa a participar de uma conversa mais rica com o cliente MCP.
Fonte primária: AWS What’s New.
Um fluxo de produção que faz sentido
Um fluxo prático para produção começa no gateway, onde a sessão é inicializada e o `Mcp-Session-Id` é armazenado pela camada intermediária. Em seguida, cada tool call usa o mesmo identificador, garantindo que o servidor MCP continue no mesmo contexto e que a afinidade de execução seja preservada ao longo da sessão.
Quando a tarefa for longa, o servidor pode emitir progress notifications. Se houver necessidade de input adicional, a elicitation entra no meio do processo. Se o cenário exigir texto gerado pelo cliente, sampling completa o ciclo sem quebrar a continuidade.
Um desenho mínimo de integração costuma ficar assim:
undefined
O exemplo acima é apenas para mostrar o contrato de transporte: o valor real do session id vem da resposta do gateway ou do runtime, e precisa ser reaproveitado nas próximas chamadas de forma consistente.
Esta seção descreve o comportamento documentado do AgentCore Runtime e do MCP em 2026. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
O que observar em ambientes reais
Mesmo com sessão stateful, ainda vale projetar para falhas de rede, expiração de sessão e retomada parcial. O brief não trouxe limites exatos de TTL, capacidade por sessão ou garantias fora da microVM associada, então a recomendação segura é não assumir persistência além do que a documentação explicita.
Outra atenção prática está no acoplamento entre sessão e memória do servidor. Se o estado for crítico, considere persistência externa para os dados que não podem se perder caso a sessão termine. A afinidade da microVM ajuda, mas não substitui desenho resiliente.
Nos repositórios de exemplo citados no material de pesquisa aparecem padrões para tarefas longas, proxy MCP e memória persistente integrada ao AgentCore. Eles são um bom sinal de que o ecossistema já está testando combinações entre sessão stateful e memória externa conforme o tipo de workload.
Fontes primárias: sample long-running tasks, sample MCP proxy, sample memory MCP server.
Por que isso importa pro dev brasileiro
No Brasil, muita solução de IA em produção precisa conviver com integrações legadas, auditoria e restrições de dados pessoais. Isso conversa diretamente com a LGPD, porque agentes com estado podem acumular contexto sensível ao longo da interação e exigem mais cuidado com retenção, minimização e governança do que um endpoint sem memória.
Além disso, boa parte dos times brasileiros ainda opera com orçamento em BRL e dependência de regiões AWS fora do país, o que torna relevantes padrões que reduzam retrabalho de integração e chamadas repetidas. Quando o custo de tempo de engenharia e latência pesa, um contrato de sessão bem definido evita soluções improvisadas para manter contexto entre tools.
Em empresas brasileiras como bancos, varejo e SaaS B2B, fluxos de atendimento e automação costumam misturar APIs internas, autenticação corporativa e trilhas de auditoria. O modelo stateful do AgentCore encaixa bem nesse cenário porque torna explícito onde o estado está e como ele circula entre cliente, gateway e runtime.
Conclusão
O recado central é simples: com AgentCore Runtime, MCP deixa de ser apenas um protocolo de tool calling e passa a suportar experiências com sessão, afinidade e interação contínua. `Mcp-Session-Id` vira o ponto de ancoragem para estado de execução, enquanto elicitation, sampling e progress notifications ampliam o que um servidor pode fazer sem quebrar o fluxo.
Se você já trabalha com agentes na AWS, vale revisar suas integrações pensando em sessão desde o início, e não como detalhe posterior. Em menos de 1 hora, abra a documentação de MCP sessions no AgentCore gateway e compare o seu fluxo atual com o contrato de `sessionConfiguration`, `Mcp-Session-Id` e continuidade entre requests.
Conteúdos da DIO para quem quer aprofundar
- AWS - Agentes de IA em Campo — trilha prática para construir soluções com Amazon Bedrock, AgentCore, automação e agentes aplicados em cenários reais na AWS.
- Nexa - Fundamentos de IA Generativa com Bedrock — jornada curta para entender os fundamentos de IA generativa na AWS e aplicar Bedrock, Nova e AgentCore em projetos.
- Formação AWS Cloud Foundations — base para quem quer consolidar fundamentos de cloud, arquitetura e serviços essenciais da AWS antes de avançar para agentes.
- XP Inc. - Cloud com Inteligência Artificial — bootcamp focado em soluções de IA na nuvem, com projetos aplicados e práticas de engenharia de prompt.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
