AWS Bedrock AgentCore runtime: o que mudou
TL;DR
O runtime do AWS Bedrock AgentCore saiu de um modelo mais orientado a comandos pontuais para uma camada de execução mais rica, com sessão isolada em microVM, shell interativo persistente via WebSocket e uma API one-shot para execução de comandos. Na prática, isso permite manter estado de ambiente, transmitir headers selecionados para o agente e dar suporte a fluxos mais “session-aware”, como MCP stateful.
As mudanças também trouxeram ajustes importantes de operação e segurança, como o requisito de MMDSv2, versões imutáveis de runtime e aumento de quotas. Para times que constroem agentes e automações na AWS, especialmente no Brasil, isso muda arquitetura, observabilidade e como lidar com contexto sensível e integração com sistemas internos.
O que mudou no runtime
O ponto central é que o runtime deixou de ser apenas um ponto de invocação do agente e passou a oferecer formas distintas de execução dentro da mesma sessão isolada. A documentação do runtime descreve a arquitetura baseada em microVM e versões imutáveis, com isolamento por sessão e ciclo de vida controlado da infraestrutura (docs.aws.amazon.com).
Além disso, agora existem duas superfícies relevantes para execução de comandos: uma API one-shot, `InvokeAgentRuntimeCommand`, para rodar comandos e receber saída sem manter um shell contínuo, e o shell interativo, `InvokeAgentRuntimeCommandShell`, que mantém estado via WebSocket (docs.aws.amazon.com) (docs.aws.amazon.com).
Execução one-shot e shell persistente
A diferença prática entre as duas APIs é simples: `InvokeAgentRuntimeCommand` resolve tarefas pontuais, enquanto `InvokeAgentRuntimeCommandShell` foi desenhado para fluxo interativo, com persistência de variáveis de ambiente, diretório atual e histórico de comandos dentro da mesma sessão (docs.aws.amazon.com).
Isso altera bastante o desenho de ferramentas internas. Antes, muitas automações precisavam reconstituir contexto a cada chamada. Agora, é possível abrir uma sessão, executar múltiplos passos e manter o estado no runtime, sem empurrar tudo de volta para o prompt. Para debug e suporte, isso também aproxima a experiência de um terminal remoto, mas com isolamento em microVM.
Esta seção descreve a versão atual do runtime e APIs associadas. Serviços de IA mudam rápido — confira a documentação oficial e o changelog antes de adotar em produção.
Headers mais flexíveis no caminho do agente
Outra mudança importante é a expansão da propagação de headers. A documentação de allowlist mostra que o runtime passou a permitir headers customizados dentro de limites explícitos, com até 20 headers por runtime e limite de 4 KB por valor (docs.aws.amazon.com). As release notes também registram a evolução para suportar custom header passthrough (docs.aws.amazon.com).
Na prática, isso abre espaço para repassar metadados úteis para o agente sem inflar o payload principal: `trace-id`, `session-id`, assinatura de webhook, contexto de tenant ou marcação de origem da chamada. Para integrações corporativas, essa mudança reduz gambiarras em que contexto operacional era enfiado dentro do corpo da requisição, com impacto ruim em observabilidade e segurança.
MCP stateful dentro do runtime
O runtime também passou a suportar recursos stateful em servidores MCP executados dentro da sessão, com interação multi-turn, sampling e progress notifications (aws.amazon.com). O detalhe relevante é que o contexto passa a ficar associado à sessão, com `Mcp-Session-Id`, em vez de depender só de chamadas isoladas.
Isso aproxima o Bedrock AgentCore de casos de uso em que o servidor não é apenas um endpoint de ferramentas, mas um componente conversacional de longa duração. Em agentes que negociam passos, pedem confirmação ou fazem operações demoradas, esse statefulness muda a arquitetura do backend e reduz a necessidade de criar sua própria camada de memória paralela.
Segurança, isolamento e requisitos de infraestrutura
O runtime continua fortemente baseado em isolamento por microVM, com sessão dedicada e limpeza de estado ao final do ciclo de vida (docs.aws.amazon.com). Em vez de confiar só em boas práticas da aplicação, o serviço coloca uma fronteira de execução mais rígida entre sessões.
Ao mesmo tempo, houve uma mudança operacional importante: a partir de 30 de junho de 2026, runtimes sem MMDSv2 deixam de ser invocáveis, retornando `ValidationException` até que a configuração seja atualizada (docs.aws.amazon.com). Esse tipo de exigência é típico de plataformas que vão maturando o plano de segurança e forçam compatibilidade com o tempo.
Versões imutáveis e rollback
Outro detalhe que afeta a operação é o modelo de versões imutáveis. Mudou imagem de container, rede ou protocolo? O runtime gera uma nova versão, preservando histórico e permitindo rollback mais controlado (docs.aws.amazon.com).
Esse desenho é valioso para times que precisam auditar mudanças em agentes, principalmente quando o comportamento do sistema depende de prompts, bibliotecas auxiliares, toolchains ou conectores internos. Em vez de tentar inferir “qual runtime estava rodando”, a plataforma passa a registrar a evolução da configuração.
Capacidade e operação em escala
Além das capacidades funcionais, o runtime recebeu aumento de quotas padrão para suportar mais sessões concorrentes e maior throughput (aws.amazon.com). O anúncio cita limites como 5.000 sessões concorrentes em us-east-1 e 2.500 em outras regiões, além de tetos de 200 interações por segundo e 25 novas sessões por segundo em regiões atendidas.
Na prática, isso importa porque o gargalo de agentes não é só inferência. Sessão, reconexão, persistência operacional e coordenação de contexto também entram na conta. Para uma arquitetura com pico de uso, esse tipo de quota pode definir se uma automação aguenta uma campanha, um processo de backoffice ou um pico de atendimento.
Por que isso importa pro dev brasileiro
No Brasil, esse tipo de mudança pesa em pelo menos três frentes concretas: LGPD, custos em moeda forte e integração com sistemas legados. Quando o agente passa a carregar headers, sessões e contexto mais explícitos, fica mais fácil separar dados mínimos de identificação de conteúdo de negócio, o que ajuda a reduzir exposição indevida de dados pessoais sob a LGPD.
Também existe o lado financeiro. Muitos times brasileiros operam com orçamento em BRL, mas usam infraestrutura precificada em dólar, então cada tentativa de escalar uma automação sem controlar sessão, debounce e quota vira custo real. Nesse cenário, um runtime que mantém estado dentro da microVM e uma API one-shot para tarefas pontuais permite escolher melhor quando abrir uma sessão persistente e quando encerrar rápido.
Há ainda um impacto arquitetural bem comum no mercado local: SaaS brasileiros e times internos costumam integrar bancos, ERPs, CRMs e filas em ambientes mistos, muitas vezes com dependências regionais e latência sensível. Shell persistente, headers allowlisted e MCP stateful ajudam quando o agente precisa conversar com ferramentas internas sem transformar tudo em uma sequência de requisições sem memória.
Como pensar adoção na prática
Se você já usa Bedrock AgentCore, a primeira revisão deve ser a separação entre tarefas pontuais e sessão longa. Comandos curtos e idempotentes podem ficar no fluxo one-shot; inspeção, depuração, execução de pipelines e ferramentas conversacionais combinam melhor com shell persistente e stateful MCP (docs.aws.amazon.com) (docs.aws.amazon.com).
Depois, vale revisar quais headers realmente precisam chegar ao runtime. A allowlist é útil, mas o limite existe por um motivo. Quanto menos metadado sensível for propagado, menor a superfície de vazamento e mais simples fica a observabilidade.
Por fim, trate MMDSv2 e versões imutáveis como parte do deploy, não como detalhe administrativo. Plataformas de agente tendem a mudar rápido, e a disciplina de versionamento evita que uma alteração pequena no runtime derrube automações críticas.
Conclusão
O runtime do AWS Bedrock AgentCore ficou mais próximo de uma plataforma de execução de agentes de verdade: com sessão isolada, estado útil, shell interativo, headers flexíveis e suporte a integrações stateful. Ao mesmo tempo, ele também ficou mais exigente em termos de configuração, compatibilidade e operação.
Se você quer avaliar isso sem sair do escopo de uma hora, abra a documentação oficial do shell interativo do AgentCore (docs.aws.amazon.com), compare com a API one-shot e desenhe uma matriz simples no seu time: o que deve ser persistente, o que deve ser efêmero e quais headers realmente precisam atravessar o runtime. Esse exercício já revela onde o novo modelo reduz complexidade e onde ele exige mais disciplina.
Conteúdos da DIO para quem quer aprofundar
- AWS - Agentes de IA em Campo — trilha prática para construir soluções com Amazon Bedrock, agentes autônomos e integrações com serviços da AWS.
- Formação AWS Cloud Foundations — base para entender os serviços essenciais da AWS antes de avançar para cenários com runtime de agentes.
- XP Inc. - Cloud com Inteligência Artificial — bootcamp sobre soluções de IA em nuvem, com projetos e práticas aplicadas.
- AWS - Cloud Amazon Web Services — programa amplo para consolidar fundamentos AWS, certificações e arquitetura cloud.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
