Amazon Bedrock AgentCore Runtime: MCP stateful e runtime gerenciado

TL;DR

Em 2026, o Amazon Bedrock AgentCore Runtime passou a suportar recursos MCP stateful, o que permite pausar fluxos para pedir confirmação ou clarificação, acionar sampling pelo servidor e emitir progresso em execuções longas. Na prática, isso tira boa parte da fricção de construir agentes multi-turn e ajuda a hospedar servidores MCP em um runtime gerenciado, com menos trabalho de infraestrutura. Veja a base oficial na página AWS What’s New e no guia de stateful MCP features.

O que mudou no AgentCore Runtime

A mudança central é simples de resumir: o AgentCore deixou de ser apenas um ambiente para executar integrações e passou a cobrir cenários em que o servidor MCP precisa manter contexto entre turnos. O anúncio oficial da AWS descreve o suporte a stateful MCP server features, enquanto o guia detalha as capacidades suportadas no modo stateful.

Essa diferença importa porque o modelo stateless limita a execução a um ciclo curto de request/response. Em cenários reais de automação, isso quebra o fluxo quando o servidor precisa pedir uma decisão humana no meio do caminho ou quando uma tarefa demora o suficiente para exigir feedback intermediário.

Stateless vs. stateful na prática

No modo stateless, o servidor não preserva a conversa como parte da execução. Isso é suficiente para chamadas diretas e comandos bem definidos, mas não cobre bem fluxos em que o agente precisa negociar o próximo passo. A própria AWS descreve essas limitações no post Introducing stateful MCP client capabilities on Amazon Bedrock AgentCore Runtime.

No modo stateful, o servidor consegue operar em ciclos mais ricos: pedir clarificação, aguardar resposta, continuar a execução e reportar progresso ao longo do trabalho. Para quem constrói automações com LLMs, isso aproxima a experiência do que um usuário espera de um assistente de verdade, e não apenas de uma função remota.

As três capacidades que mudam a experiência

A documentação oficial lista três blocos importantes: elicitation, sampling e progress notifications. Eles aparecem no guia da AWS sobre stateful MCP features e formam a base dos fluxos multi-turn.

Elicitation: pedir input no meio da execução

Elicitation é a capacidade de o servidor solicitar uma resposta do usuário durante a execução. Isso é útil quando o fluxo encontra ambiguidade, política de aprovação ou informação faltante. Em vez de falhar ou adivinhar, o servidor pode perguntar e continuar depois.

Esse detalhe parece pequeno, mas muda bastante a arquitetura. Em muitas empresas, a automação para neste ponto e devolve o problema ao humano sem contexto. Com elicitation, o sistema pode manter o fio da meada e reduzir retrabalho.

Sampling iniciado pelo servidor

O guia da AWS também cobre sampling acionado pelo servidor. Na prática, o servidor pode solicitar geração ao cliente/LLM em momentos específicos, em vez de concentrar toda a inteligência em um único request inicial. Isso dá mais flexibilidade para separar raciocínio, coleta de dados e geração de resposta.

Para o desenho de agentes, essa separação ajuda quando o servidor precisa orquestrar etapas e não apenas responder a uma pergunta isolada. O ponto não é “mais inteligência”, e sim melhor controle de execução.

Progress notifications para tarefas longas

Quando a tarefa é longa, o usuário precisa de sinais de vida. O suporte a progress notifications atende justamente esse caso. O post e os exemplos oficiais mostram o valor disso para cenários em que o trabalho acontece ao longo do tempo, não em um único retorno imediato.

Isso é relevante para workloads de busca, preparação de dados, análise de múltiplas etapas e integrações corporativas que dependem de filas, aprovação ou chamadas externas. Sem esse feedback, a UX degrada rápido, mesmo quando o sistema está funcionando corretamente.

Runtime gerenciado para hospedar MCP servers

Além das capacidades stateful, a proposta do AgentCore Runtime como ambiente gerenciado para hospedar servidores MCP aparece nos samples oficiais da AWS, como o repositório sample-hosting-mcp-server-on-agentcore-runtime. O foco é reduzir a carga de integração de infraestrutura para quem quer expor MCP servers como endpoints administrados.

O valor aqui não é eliminar toda configuração, mas concentrar menos esforço em detalhes que costumam consumir tempo de equipe: empacotamento, deploy, isolamento e operação. Para times que já vivem em AWS, isso tende a encaixar melhor do que uma solução artesanal espalhada em vários serviços.

Atenção: o ecossistema de APIs e runtimes de IA muda rápido. Antes de adotar esse desenho em produção, confira o changelog oficial da AWS e valide as limitações atuais do AgentCore Runtime no seu ambiente.

Como isso se encaixa em um fluxo real

Os samples oficiais ajudam a transformar a teoria em arquitetura. O repositório sample-agentcore-runtime-agui-stateful-mcp-demo demonstra uma experiência com UI para elicitation e conversas multi-turn. Já o sample sample-mcp-for-long-runing-tasks-with-amazon-bedrock-agentcore foca em tarefas long-running, onde progress notifications fazem diferença.

Na prática, isso permite separar três responsabilidades:

• o cliente conversa com o usuário e coleta contexto;
• o servidor MCP mantém a continuidade da execução;
• o runtime gerenciado hospeda e expõe o servidor com menos cola de infraestrutura.

Essa divisão é útil em aplicações corporativas porque simplifica auditoria e manutenção. Também ajuda a evitar que a lógica de diálogo fique misturada com código de deploy e observabilidade.

Por que isso importa pro dev brasileiro

No Brasil, o ponto não é só conveniência técnica. Em muitos times, o gargalo está em fazer mais com orçamento em BRL, janela curta de deploy e times pequenos que acumulam aplicação, infraestrutura e operação. Um runtime gerenciado na AWS pode reduzir custo operacional de manter endpoints próprios, especialmente quando a latência para regiões fora de South America é um fator real de experiência.

Há também um componente de governança que pesa mais em setores regulados, como bancos, fintechs e saúde. Quando o fluxo envolve dados pessoais, a LGPD exige cuidado com minimização, rastreabilidade e justificativa de tratamento. Se o agente precisa pedir confirmação no meio do processo, já é melhor projetar isso com contexto e controles desde o início do que adaptar depois num sistema improvisado.

Esse cenário conversa bem com a realidade de muitas equipes brasileiras: bootcamps, transição de carreira e participação de pessoas que precisam entregar valor rápido. Um stack mais claro, com stateful MCP e hosting administrado, tende a diminuir fricção de adoção para quem está subindo a curva de cloud e IA ao mesmo tempo.

Arquitetura mental para decidir adoção

Antes de comprar a ideia, vale responder três perguntas. Primeiro: seu caso precisa de interação no meio da execução? Se a resposta for não, o ganho do modo stateful pode ser pequeno. Segundo: você tem tarefas long-running com feedback útil ao usuário? Se sim, progress notifications já justificam parte do desenho.

Terceiro: vale a pena manter o hosting do MCP server em ambiente próprio, ou o runtime gerenciado já cobre o necessário? Em times pequenos, a resposta costuma pender para menos infraestrutura própria. Em sistemas com exigências específicas de rede ou compliance, o desenho precisa ser validado com mais cuidado.

Conclusão

O avanço do Amazon Bedrock AgentCore Runtime em 2026 não é apenas uma adição de feature. Ele sinaliza uma direção clara: agentes e servidores MCP estão migrando de chamadas simples para fluxos contínuos, com contexto, confirmação humana e feedback progressivo. Para quem trabalha com automação na AWS, isso abre espaço para experiências mais úteis sem exigir que cada equipe reconstrua toda a camada de orquestração.

Se você quer avaliar esse modelo com segurança, abra a documentação oficial de stateful MCP features e compare um fluxo seu que hoje depende de retries manuais ou mensagens soltas de status. Em até 1 hora, você já consegue mapear onde uma elicitation ou uma progress notification reduziria atrito no seu caso real.

Conteúdos da DIO para quem quer aprofundar

• Nexa - Fundamentos de IA Generativa com Bedrock — trilha introdutória para entender os fundamentos de IA generativa na AWS, com Amazon Bedrock e aplicações práticas.
• Formação AWS CLF-02 Practitioner — base para quem quer consolidar conceitos de cloud, segurança, cobrança e arquitetura na AWS.
• Nexa - Machine Learning para Iniciantes na AWS — trilha voltada a ML na AWS com foco prático, útil para entender serviços e fluxos que convivem com agentes.

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