AWS Bedrock AgentCore Runtime ganha MCP stateful

TL;DR

Em 2026, o Amazon Bedrock AgentCore Runtime passou a suportar recursos stateful de MCP, o que permite manter contexto entre chamadas, pedir esclarecimentos no meio da execução e emitir progresso em tempo real. Na prática, isso tira o fluxo agente-tool do padrão “pedido-resposta” e aproxima a experiência de uma sessão interativa, com melhor controle de estado e de UX operacional.

O que mudou no AgentCore Runtime

O anúncio oficial da AWS descreve a chegada de stateful MCP server features no Amazon Bedrock AgentCore Runtime. O ponto central é que o servidor passa a conseguir sustentar mais do que uma troca pontual: ele pode preservar estado, pedir dados adicionais ao cliente e acompanhar a execução com eventos de progresso.

Isso é relevante porque muitos fluxos de agentes não são lineares. Uma tool pode precisar de confirmação humana, gerar texto intermediário ou avisar que está processando algo demorado. O suporte novo organiza isso em cima de sessão, em vez de forçar o desenvolvedor a simular continuidade só com armazenamento externo.

Sessão, afinidade e `Mcp-Session-Id`

A documentação do contrato MCP do AgentCore mostra que o header `Mcp-Session-Id` é o mecanismo usado para manter a continuidade da sessão e a afinidade de roteamento. Em vez de uma invocação isolada, o cliente precisa reenviar esse identificador para que a plataforma preserve o estado correto entre requisições subsequentes.

Em termos práticos, isso evita que um servidor stateful perca o contexto no meio de um fluxo. Para quem implementa integrações, a mudança é simples de entender: capture o id de sessão e trate-o como parte do contrato da conversa, não como detalhe interno descartável.

Um formato mínimo de integração fica assim:

undefined

Esse padrão vale especialmente quando a execução depende de múltiplas voltas entre cliente e servidor dentro da mesma interação.

Elicitation: quando a tool precisa parar e perguntar

Com suporte stateful, o servidor MCP pode solicitar informações adicionais durante a execução, algo chamado de elicitation. A documentação da AWS dá o exemplo de um agente de reservas de viagem que precisa interromper a execução para pedir um dado faltante antes de seguir com a operação, em vez de falhar ou improvisar resposta.

Esse comportamento é útil em cenários empresariais onde a automação não pode assumir nada sensível. No Brasil, isso conversa bem com fluxos regulados, como atendimento em bancos, seguradoras e fintechs, onde a confirmação de dados de cliente costuma impactar consentimento, compliance e rastreabilidade.

Sampling: conteúdo gerado no meio da execução

Outro recurso habilitado é o sampling, em que o servidor solicita ao cliente a geração de texto durante uma tool call. A documentação do Gateway da AWS aponta que esse tipo de interação depende de sessions e de response streaming para funcionar com eventos em tempo real.

Na prática, isso permite cenários como enriquecer uma resposta com instruções dinâmicas, criar texto contextualizado ou gerar uma lista específica para a operação em andamento. Em vez de encerrar a tool e abrir outra chamada, a sessão continua viva e o fluxo fica mais natural para o usuário e para o agente.

Progresso em tempo real com SSE

A camada de streaming é o que torna as interações anteriores visíveis para o cliente enquanto acontecem. A doc oficial de MCP response streaming explica que, ao enviar Accept: text/event-stream, o gateway devolve eventos SSE com progresso, logs e outros eventos de sessão conforme a execução avança.

Isso é particularmente importante em tarefas longas, como busca, orquestração ou validação de múltiplos passos. Sem streaming, o usuário só vê começo e fim; com SSE, o sistema pode mostrar que está vivo, reduzir sensação de travamento e abrir espaço para interrupção controlada quando necessária.

Esta seção descreve o release e o contrato atuais do AgentCore em 2026. APIs de IA e de agentes mudam rápido — confira a documentação oficial antes de adotar em produção.

O que isso muda para projetos com tool-use

Na prática, o conjunto stateful + streaming corrige limitações clássicas de agentes construídos apenas com request-response. Fluxos como reserva, triagem, coleta de dados e assistência guiada ficam mais próximos de uma conversa de verdade, com memória de sessão e pontos de parada explícitos.

Para arquiteturas com MCP, isso também muda o desenho do backend. Você passa a pensar em handlers que toleram pausa, retomada e eventos intermediários, em vez de supor que toda tool vai terminar em uma única resposta síncrona.

A documentação de stateful MCP server features também deixa claro que, se a sessão expirar ou terminar, o cliente pode precisar re-inicializar e obter um novo session id. Isso exige tratamento de falhas mais cuidadoso, especialmente em integrações de longa duração.

Por que isso importa pro dev brasileiro

O contexto brasileiro torna esse release mais concreto porque muitos times trabalham com APIs em AWS us-east-1, atendendo usuários no Brasil com latência que já precisa ser administrada com cuidado. Quando a conversa entre tool e cliente passa a depender de sessão e streaming, cada ida e volta na rede pesa mais do que em integrações puramente locais.

Além disso, o Brasil tem forte presença de bancos, varejo e empresas orientadas por requisitos de auditoria e tratamento de dados pessoais sob a LGPD. Em fluxos de elicitation, o fato de a plataforma suportar continuidade de sessão ajuda a desenhar verificações mais explícitas, com menos improviso na coleta de dados sensíveis e melhor rastreabilidade do que uma automação que “chuta” o próximo passo.

Também vale notar o custo: no mercado brasileiro, muita equipe precisa justificar cada camada adicional de infraestrutura em BRL. Se um recurso nativo da plataforma reduz a necessidade de orquestração paralela, polling agressivo ou hacks de estado em serviços externos, isso simplifica manutenção e pode diminuir custo operacional do time.

Como pensar a implementação

Se você já usa MCP, o primeiro ajuste mental é tratar sessão como recurso central. O cliente precisa armazenar o Mcp-Session-Id, reenviá-lo corretamente e aceitar que a execução pode gerar eventos parciais antes da resposta final.

Um desenho típico inclui três cuidados: habilitar streaming no gateway, manter o id de sessão ao longo da conversa e implementar fallback para expiração. Isso evita que a experiência quebre quando o servidor pedir clarificação ou quando a tool estiver executando algo demorado.

Para um time brasileiro que já usa Bedrock ou está avaliando agentes em produção, esse é um bom momento para separar claramente tarefas síncronas de tarefas sesssion-aware. Nem toda tool precisa de estado, mas as que envolvem dados incompletos, jornadas longas ou validação humana tendem a se beneficiar bastante desse modelo.

Conclusão

O suporte stateful de MCP no Amazon Bedrock AgentCore Runtime fecha uma lacuna prática na construção de agentes: agora dá para manter sessão, pedir esclarecimento no meio do caminho, receber geração assistida e mostrar progresso ao vivo. Para quem desenha experiências com tools, isso reduz gambiarras de estado e abre espaço para fluxos mais confiáveis.

Se você quer validar isso em menos de uma hora, abra a documentação oficial do stateful MCP e do response streaming, e compare com o seu fluxo atual de tool-use para identificar onde a sessão pode eliminar polling ou redesenhar uma etapa de confirmação humana.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.