AWS Bedrock AgentCore: o que mudou na release mais recente
TL;DR
A release mais recente material do AWS Bedrock AgentCore fecha o pacote de produção com três peças que se complementam: runtime instances em GA para computação persistente, managed session storage para manter estado entre pausas e AgentCore Evaluations para medir qualidade em operação. Na prática, isso reduz a necessidade de montar uma infraestrutura própria só para sustentar sessões longas, armazenar artefatos e acompanhar regressões em agentes.
Para quem constrói agentes no Brasil, o impacto aparece rápido em cenários com custo controlado em BRL, times enxutos e integrações com sistemas legados que exigem sessões mais longas e rastreabilidade. O resultado é um caminho mais direto para levar um agente do protótipo ao ambiente real sem abrir mão de governança.
O que entrou na release mais recente
O ponto central da atualização é o runtime instances, anunciado como generally available em 2026, com computação persistente baseada em EC2 e sessões de até 14 dias (fonte). Isso amplia o alcance do AgentCore para cargas que não cabem bem no modelo serverless de curta duração.
O blog oficial descreve também a possibilidade de escolher famílias de instância via capacity provider, incluindo opções com GPU, memória e computação mais especializados (fonte). Em vez de tratar o agente como apenas uma função efêmera, o runtime passa a se parecer mais com um ambiente contínuo, mas ainda gerenciado pela plataforma.
Esse ponto conversa com o anúncio detalhado do blog AWS, que posiciona a feature como computação persistente para agentes de produção. É uma mudança importante porque workloads agentic costumam misturar chamadas a modelo, ferramentas externas, filas, arquivos temporários e estados intermediários que nem sempre sobrevivem bem a uma execução curta.
Runtime instances versus runtime tradicional
Antes dessa novidade, o runtime principal do AgentCore era mais próximo de uma abordagem serverless com janela de execução menor. Agora, o runtime instances abre espaço para sessões bem mais longas e para uma escolha explícita de capacidade computacional (fonte).
Na prática, isso faz diferença em tarefas como análise de documentos extensos, processamento de lotes, automação de atendimento com múltiplas etapas e agentes que dependem de bibliotecas pesadas ou aceleração por GPU. Se o seu fluxo precisa ficar vivo por horas ou dias, a nova opção encaixa melhor do que tentar contornar limites de execução curtos.
O ganho não é só técnico; ele também é operacional. Sem esse tipo de runtime, o time tende a empurrar parte da complexidade para infraestrutura própria, scripts de retomada, filas auxiliares e mecanismos de reidratação manual de contexto. Com a plataforma assumindo essa camada, sobra mais espaço para cuidar da lógica do agente e menos para administrar um mini-orquestrador paralelo.
Estado persistente com managed session storage
Outra peça relevante é o managed session storage, anunciado em março de 2026 como preview para o runtime do AgentCore (fonte). A proposta é simples: permitir que o agente persista estado de filesystem entre Stop e Resume sem exigir checkpoint manual em cada etapa.
O anúncio oficial informa armazenamento de até 1 GB por sessão e retenção de até 14 dias de inatividade (fonte). Isso é útil quando o agente precisa manter artefatos intermediários, rascunhos, índices locais, arquivos de trabalho ou configurações derivadas de uma tarefa que não deve ser perdida ao pausar a execução.
Na prática, runtime instances e session storage se complementam. Um cuida do tempo e da forma da computação; o outro cuida da continuidade do estado. Para agentes que fazem investigação, resumem relatórios, orquestram ferramentas ou percorrem fluxos longos em empresas brasileiras, a combinação reduz bastante o atrito de implementação.
Esta seção descreve recursos do AgentCore em 2026. APIs e limites de serviços de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
AgentCore Evaluations e qualidade em produção
A release também vem acompanhada do AgentCore Evaluations, que passou a GA em 2026 (fonte). O anúncio separa dois modos: avaliação online contínua, amostrando traces em produção, e avaliação sob demanda para verificar interações específicas.
Esse tipo de suporte muda a conversa sobre agente em produção porque sai do campo do “testar no final” e entra no campo de monitoramento operacional. Em vez de depender só de avaliação manual ou revisão esparsa, você passa a ter uma camada estruturada para acompanhar regressões, comportamento indevido e qualidade de respostas ao longo do tempo.
O material oficial cita 13 built-in evaluators, cobrindo dimensões como qualidade, segurança, uso de ferramentas e conclusão de tarefas (fonte). Para times que publicam agentes em fluxos de atendimento, suporte interno ou automação documental, isso é valioso porque reduz a chance de degradar silenciosamente um comportamento que parecia estável em testes isolados.
Gateway e a especificação MCP 2026-07-28
O outro eixo técnico relevante é o AgentCore Gateway com suporte à especificação MCP 2026-07-28, detalhado em blog oficial da AWS (fonte). A atualização é importante porque o ecossistema de ferramentas e servidores MCP vem mudando em direção a contratos mais estáveis de metadados e capacidades.
O blog explica que a migração pode ser feita com uma única chamada de UpdateGateway para adicionar a nova versão em supportedVersions (fonte). Isso simplifica a atualização quando o objetivo é alinhar o gateway às mudanças do protocolo sem recriar toda a topologia de integração.
Também vale notar o recorte arquitetural: o post destaca mudanças incompatíveis entre versões, especialmente na forma de transportar metadados e capacidades (fonte). Se o seu agente conversa com ferramentas externas por MCP, essa verificação de compatibilidade deixa de ser detalhe e vira parte do processo de atualização.
Por que isso importa pro dev brasileiro
No Brasil, o ganho é prático porque muitos times trabalham com orçamento em real, equipes pequenas e backends que precisam conviver com legado, filas e integrações bancárias ou corporativas. Quando um agente exige sessão longa, persistência de arquivos e observabilidade de qualidade, a chance de o time acabar montando uma solução artesanal cresce rápido.
É aqui que o AgentCore fica interessante: a plataforma reduz a necessidade de costurar, por conta própria, os blocos de compute, estado e avaliação. Para empresas sujeitas à LGPD, também faz diferença centralizar a governança de sessão e rastreamento em vez de espalhar dados e checkpoints por múltiplos serviços sem controle claro de retenção e auditoria.
Existe ainda um detalhe operacional bem brasileiro: latência e custo de região importam muito quando parte da infra fica em us-east-1 e o time precisa respeitar janela de suporte, orçamento mensal e previsibilidade de carga. Um runtime persistente gerenciado pode simplificar esse desenho, mas continua exigindo que o time modele bem o que entra em filesystem, o que fica em memória e o que precisa ser tratado como dado sensível.
Como pensar na adoção
O caminho mais sensato é começar por um caso de uso com fronteiras claras: um agente que consulta ferramentas, mantém contexto por muitas etapas e se beneficia de estado persistente. Depois, avalie se a execução realmente pede runtime instances ou se o modelo padrão ainda resolve.
Em seguida, habilite session storage apenas para o que fizer sentido persistir. Se o fluxo depende de artefatos, rascunhos ou índices locais, isso ajuda bastante; se depende só de estado transitório, talvez a complexidade adicional não compense.
Por fim, trate Evaluations como parte do ciclo de entrega. Antes de aumentar tráfego ou colocar o agente em uma operação crítica, rodar avaliações sob demanda e acompanhar traces em produção ajuda a descobrir falhas de prompt, mudança de comportamento de ferramenta ou regressões de segurança.
Conclusão
A release mais recente do AWS Bedrock AgentCore aponta para uma plataforma mais completa para agentes em produção: compute persistente, estado de filesystem gerenciado, avaliação contínua e gateway alinhado ao MCP mais recente (fonte). Para quem vinha improvisando essas camadas em serviços separados, a proposta agora fica mais coerente e agressivamente voltada a operação real.
Se você já tem um agente em protótipo, a melhor próxima ação é separar um caso de uso que precise de persistência e testar o fluxo com runtime instances e session storage juntos. Em menos de uma hora, você consegue ler a documentação oficial de release notes e do anúncio de runtime instances, mapear os limites aplicáveis ao seu cenário e decidir se vale um piloto controlado (releases).
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
