AWS Bedrock AgentCore runtime: o que mudou em 2026

TL;DR

Em 2026, a AWS passou a tratar o Amazon Bedrock AgentCore Runtime menos como uma peça “experimental” de orquestração e mais como uma base de execução para agentes com estado, sessão e interação contínua. As mudanças mais relevantes foram suporte a MCP stateful, execução de comandos via API, protocolo AG-UI, Node.js e armazenamento gerenciado de sessão.

Na prática, isso importa porque vários fluxos de agente deixam de depender de um desenho artesanal de estado, arquivo temporário e ponte customizada com interface. Para equipes no Brasil, o efeito é direto em custo operacional, manutenção e velocidade de entrega, especialmente em projetos que precisam respeitar LGPD e operar com menos folga de orçamento.

O que mudou no AgentCore Runtime

Se você acompanha a evolução de agentes em produção, deve ter percebido uma mudança de foco: sair da prova de conceito e entrar no terreno da execução persistente. O conjunto de anúncios da AWS em março e abril de 2026 aponta exatamente nessa direção, com a runtime ganhando recursos que antes exigiam bastante cola entre serviços, filas, storage e processos auxiliares. As páginas stateful MCP, shell command execution, AG-UI, Node.js support e managed session storage deixam isso explícito.

O ponto comum entre esses anúncios é simples: o runtime passou a assumir mais responsabilidade sobre continuidade de contexto. Isso inclui preservar filesystem por sessão, executar comandos no ambiente do agente, suportar protocolos que exigem conversa incremental e abrir caminho para workloads mais parecidos com produtos do que com demos.

MCP stateful: quando o agente não precisa fingir que é stateless

O suporte a MCP stateful é relevante porque muda o tipo de interação que a infraestrutura consegue sustentar. Em vez de tratar cada chamada como uma troca isolada, o runtime passa a suportar capacidades como elicitation, sampling e progress notifications, que são úteis quando uma ferramenta precisa pausar, pedir entrada estruturada ou voltar com sinais parciais enquanto continua processando.

Isso parece detalhe, mas afeta bastante o desenho de agentes que trabalham com etapas longas: análise de documentos, coleta de requisitos, revisão de artefatos e execução de tarefas em múltiplas rodadas. Com estado explícito, o sistema fica menos dependente de memória improvisada em aplicação ou em banco externo, e mais alinhado ao ciclo real da tarefa.

Execução de comandos via API: mais poder, mais responsabilidade

A adição de shell command execution via API é um daqueles recursos que aceleram muito o desenvolvimento, mas exigem cuidado redobrado. A AWS apresentou a possibilidade de executar comandos diretamente no runtime por meio de uma chamada como InvokeAgentRuntimeCommand, o que abre espaço para automatizar tarefas de sistema, setup de ambiente e etapas de tooling sem construir um serviço paralelo só para isso.

Na prática, isso diminui o atrito em agentes que precisam instalar dependências, rodar scripts de validação, gerar artefatos ou manipular repositórios. O ganho vem junto com a exigência óbvia de sandbox, isolamento e controle de permissões, porque qualquer runtime que executa comando precisa ser tratado como superfície sensível.

Esta seção descreve a linha de recursos anunciada em 2026 para o AgentCore Runtime. APIs de IA e de plataforma mudam rápido — confira o changelog oficial antes de adotar em produção.

AG-UI: o runtime encosta mais perto da camada de produto

O suporte ao AG-UI sinaliza uma integração mais natural entre agente e interface. Em vez de cada time criar um contrato próprio para eventos, sessão, autenticação e rotação de contexto, a runtime passa a suportar o protocolo com isolamento por sessão e escala gerenciada. Isso ajuda muito quando o agente deixa de ser apenas backend e vira parte da experiência do usuário.

Esse tipo de integração é especialmente útil em fluxos onde a interface precisa refletir progresso em tempo real, aceitar entrada do usuário no meio da tarefa e manter coerência entre telas, eventos e estado do agente. Para produto, isso reduz custo de coordenação entre frontend e backend; para engenharia, reduz a quantidade de contratos customizados que acabam difíceis de manter.

Node.js e armazenamento de sessão: menos cola, mais continuidade

O suporte a Node.js amplia o alcance da runtime para equipes que já constroem ferramentas e servidores de agente nesse ecossistema. Para muita empresa, isso importa mais do que parece: grande parte dos times de aplicação já tem bibliotecas, padrões e observabilidade em JavaScript ou TypeScript, então suportar esse stack reduz o custo de adoção.

Já o managed session storage resolve um problema clássico de agentes que precisam parar e voltar sem perder o trabalho anterior. A AWS descreve persistência de filesystem por session id, o que ajuda em cenários com arquivos fonte, pacotes instalados, artefatos de build e continuidade de repositório. Em termos práticos, o agente deixa de se comportar como uma execução descartável e passa a manter um espaço de trabalho reutilizável.

Leituras práticas para arquitetura de agentes

Se você vai avaliar essas novidades em um projeto real, vale separar o que é ganho estrutural do que é apenas conveniência. Stateful MCP e session storage atacam continuidade; shell command acelera automação; AG-UI aproxima produto e agente; Node.js reduz fricção de stack. Juntos, eles apontam para uma runtime menos dependente de componentes externos para lembrar, continuar e interagir.

O desenho mais interessante agora é o de agentes que alternam entre passos automáticos, observações do usuário e comandos de sistema sem perder contexto. Isso é bem diferente de um pipeline simples de prompt e resposta. Aqui estamos falando de fluxo de trabalho com pausa, retomada e persistência real de sessão.

Quando isso faz diferença de verdade

Esses recursos fazem diferença quando o agente precisa lidar com algo mais próximo de operação contínua do que de geração pontual. Exemplos comuns são revisão de código, coleta assistida de requisitos, geração de documentação com artefatos intermediários, investigação de incidentes e automação com interação humana no meio do processo. Nesses casos, a pergunta deixa de ser “o modelo responde?” e passa a ser “como manter o trabalho íntegro entre etapas?”.

Para times de plataforma, a resposta muda custo e governança. Menos cola significa menos pontos de falha, menos retrabalho e menos lógica espalhada entre serviços que não foram pensados para se coordenar como uma única sessão de agente.

Por que isso importa pro dev brasileiro

No Brasil, o efeito dessa evolução é prático porque o custo de montar uma camada própria de sessão, estado e ponte com interface pesa mais cedo no orçamento. Em muitos times o ambiente padrão ainda é AWS em regiões próximas aos Estados Unidos, o que torna cada componente extra de coordenação mais sensível a latência e a conta mensal em BRL, principalmente quando o produto cresce e sai do piloto.

Há também o recorte de LGPD: quando um agente mantém contexto, arquivos e interações por sessão, o time precisa deixar claro o que fica persistido, por quanto tempo e com qual finalidade. Isso não é um detalhe “jurídico” separado da engenharia; é parte do desenho técnico da solução. Um runtime que assume mais controle sobre sessão reduz improviso, mas exige que o time saiba mapear retenção, acesso e descarte de dados desde o começo.

Outra diferença concreta no cenário brasileiro é a formação de times. É comum encontrar squads com mistura de backend, dados e automação, nem sempre com um especialista dedicado em plataforma de agentes. Quando a runtime absorve mais responsabilidades de sessão e execução, o time ganha velocidade sem precisar criar uma mini plataforma interna para sustentar cada experimento.

Como pensar adoção sem exagero

Essas novidades não significam que todo agente deva virar runtime stateful amanhã. Se o mecanismo é simples, com uma única chamada e pouca necessidade de retomada, a complexidade adicional pode não compensar. O ganho aparece quando há sessão longa, ferramentas encadeadas, artefatos intermediários e interação com usuário ou sistema em pontos distintos do fluxo.

Um bom critério é perguntar se o seu agente hoje depende de alguma combinação entre fila, storage temporário, web socket, banco de estado e orquestração manual para simular continuidade. Se a resposta for sim, vale testar o AgentCore Runtime como camada de execução mais integrada. Se não for, talvez seja melhor manter a arquitetura simples e avaliar as novidades apenas quando a jornada do agente crescer.

Conclusão

O update de 2026 do Amazon Bedrock AgentCore Runtime mostra que a AWS está tratando agentes como workloads persistentes, interativos e sensíveis a sessão, não só como chamadas isoladas de modelo. Para quem constrói produto, isso reduz a necessidade de colar várias peças manualmente e abre espaço para uma arquitetura mais limpa em fluxos com estado, interface e execução de comandos.

Se você quiser avaliar isso em uma hora, abra a documentação oficial do stateful MCP e do managed session storage, e compare esses recursos com o fluxo atual do seu agente; em seguida, desenhe onde você ainda depende de estado improvisado e identifique um ponto pequeno para piloto.

Conteúdos da DIO para quem quer aprofundar

• Nexa - Fundamentos de IA Generativa com Bedrock — Introduz fundamentos de IA generativa na AWS e coloca Amazon Bedrock, PartyRock, Amazon Nova e AgentCore em contexto prático.
• Nexa - Análise Avançada de Imagens e Texto com IA na AWS — Trabalha integrações com serviços de IA da AWS para análise, transcrição e síntese de conteúdo multimodal.
• CI&T - Backend com Java & AWS — Ajuda a conectar APIs, escalabilidade e deploy em nuvem com uma base de backend que conversa bem com workloads de agentes.

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