AWS Bedrock AgentCore: o que mudou nas release notes recentes
TL;DR
As release notes recentes do Amazon Bedrock AgentCore mostram três movimentos claros: o runtime amadureceu e chegou a GA, o suporte a MCP evoluiu com mudanças de sessão e de spec, e a observabilidade ficou mais padronizada para novos agentes. Na prática, isso reduz atrito para quem precisa operar agentes com fluxo longo, rastreabilidade e deploy mais previsível.
O que mudou no AgentCore runtime
O primeiro ponto que chama atenção é o avanço do runtime do AgentCore para disponibilidade geral, anunciado pela AWS em setembro de 2026. Isso importa porque o runtime deixa de parecer uma peça experimental e passa a ser tratado como base operacional para agentes em produção, com foco em execução isolada e continuidade de sessão quando necessário. Fonte primária: GA do AgentCore Runtime.
Em paralelo, a AWS publicou detalhes sobre o modo stateful do runtime com MCP. Nesse cenário, o serviço cria uma microVM por sessão e usa o header Mcp-Session-Id para continuar o contexto entre interações, o que é útil em fluxos longos, com pausas e retomadas. Isso é especialmente relevante quando o agente precisa pedir confirmação, aguardar uma etapa externa ou seguir executando depois de um “mid-execution pause”. Fonte: stateful MCP no runtime.
Como isso afeta o desenho da aplicação
Na prática, o runtime deixa de ser só um executor de chamadas curtas e passa a suportar ciclos de trabalho mais parecidos com um job distribuído. Para o time técnico, isso muda a decisão entre manter estado no próprio app, gravar contexto em storage intermediário ou confiar no runtime para persistir parte da interação. A arquitetura fica mais simples quando o caso de uso é claramente sesssion-based e precisa de isolamento por conversa ou por tarefa.
Esta seção descreve a versão recente do AgentCore Runtime e do suporte a MCP. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
MCP: sessões, spec 2026-07-28 e impacto no cliente
Outro eixo importante nas notas e posts recentes é o suporte ao MCP 2026-07-28. A documentação da AWS mostra que o AgentCore Gateway passou a alinhar o suporte ao novo spec, com mudanças que aproximam a interação de um endpoint HTTP mais stateless. Isso reduz algumas suposições antigas sobre handshake e lifecycle de sessão no lado do protocolo, o que tende a facilitar escala e interoperabilidade. Fonte: como o Gateway suporta o spec MCP 2026-07-28.
Ao mesmo tempo, a AWS também detalhou um caminho para sessões stateful no Gateway. Nesse modelo, a criação ou atualização do gateway recebe uma configuração de sessão, o servidor gera um Mcp-Session-Id e o cliente reenvia esse identificador nas próximas requisições. Isso encaixa bem em casos de elicitation, progress updates e workflows em que o agente não termina tudo numa única chamada. Fonte: extensão do suporte MCP no AgentCore Gateway.
O que o time precisa revisar
Se você integra um cliente MCP hoje, vale revisar três pontos: como o seu cliente passa metadados no handshake, como o backend lida com continuidade de estado e quais versões do spec estão habilitadas no gateway. As notas indicam atualização de suporte por versões, então o risco real está em assumir comportamento antigo enquanto o protocolo já mudou. Em ambientes com agentes conversacionais ou ferramentas de longa duração, essa revisão evita quebra silenciosa de fluxo.
Deploy e observabilidade: menos fricção, mais padronização
Nas release notes recentes, a observabilidade unificada ganhou peso maior como padrão para agentes novos. A AWS documenta a variável UNIFIED_TRACES_DESTINATION_ENABLED para controlar o destino dos spans, e indica que, a partir de 20 de julho de 2026, agentes recém-criados passam a usar o log group do próprio agente como destino padrão. Isso melhora o isolamento operacional do tracing e reduz a necessidade de caçar eventos em destinos compartilhados. Fonte: telemetria e traces unificados e release notes do AgentCore.
Do ponto de vista de deploy, a mudança mais útil é que a configuração fica mais declarativa. Em vez de tratar tracing como ajuste lateral, o time passa a considerar observabilidade como parte do runtime do agente. Isso é bom para ambientes com vários agentes, porque o custo de investigação em produção cai quando cada execução já nasce com uma trilha mais consistente.
Por que isso importa em produção
Agente sem observabilidade boa vira caixa-preta muito rápido, especialmente quando envolve ferramentas externas, chamadas síncronas e retomada de sessão. Com o conjunto runtime + MCP + traces unificados, a AWS parece empurrar a plataforma para um modelo mais operável: menos configuração manual, mais comportamento previsível e rastreamento por contexto do agente. Para quem opera isso em escala, é um ganho de governança mais do que de performance pura.
Como ler isso no contexto brasileiro
No Brasil, esse tipo de mudança pesa por um motivo bem concreto: muitos times trabalham com orçamento em BRL e infraestrutura em região externa, frequentemente com latência adicional para us-east-1. Quando o fluxo do agente depende de várias idas e voltas, sessão stateful e observabilidade consistente reduzem retrabalho de diagnóstico e custo de operação. Além disso, para aplicações que tratam dados pessoais, a LGPD exige mais disciplina na forma como contexto, logs e traces são armazenados e correlacionados, então centralizar telemetria por agente não é só conveniência técnica.
Outro ponto local é a composição típica dos times. No mercado brasileiro é comum encontrar squads que misturam devs generalistas, gente em transição de carreira e equipes menores com pouca folga para tooling extra. Nesse cenário, facilitar deploy, sessão e tracing numa plataforma gerenciada pode reduzir a quantidade de peças que o time precisa integrar e manter por conta própria.
Leituras práticas para quem vai implementar
Se você usa AWS Bedrock AgentCore ou está avaliando o stack, a triagem mais útil agora é esta: confirme a versão do MCP aceita pelo gateway, revise como o cliente armazena e reenvia o Mcp-Session-Id e verifique se a telemetria está indo para o destino esperado do agente. Depois disso, rode um fluxo curto de ponta a ponta com observabilidade habilitada e compare o que aparece no trace com o que a aplicação realmente fez.
Para reduzir risco, trate a atualização de spec e de runtime como mudança operacional, não só como upgrade de SDK. Se o seu agente chama ferramentas externas, vale testar retomada de sessão, timeout e recuperação depois de falhas parciais antes de abrir para usuários finais.
Conclusão
O quadro geral das release notes recentes é claro: o AgentCore está se tornando mais pronto para produção, com runtime em GA, suporte de MCP mais explícito e telemetria mais bem definida. Para o time técnico, isso significa menos improviso em sessão, menos ambiguidade de observabilidade e um caminho mais sólido para operar agentes em fluxo longo.
O próximo passo, se você quer validar isso na prática, é abrir a documentação oficial do AgentCore release notes, selecionar um agente de teste e reconfigurar a telemetria com UNIFIED_TRACES_DESTINATION_ENABLED para observar a diferença no trace antes de levar a mudança para produção.
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 aplicações voltadas ao ecossistema AWS.
- Formação AWS Cloud Foundations — base para entender os serviços essenciais da AWS antes de avançar para runtime, gateway e observabilidade.
- Formação DevOps Fundamentals — ajuda a conectar deploy, integração contínua e operação, que são parte central de qualquer agente em produção.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
