A Amazon Web Services (AWS) anunciou em 18 de setembro de 2026 o novo AgentCore runtime, a camada de computação gerenciada do Amazon Bedrock AgentCore. A empresa apresenta a atualização como resposta a três exigências de agentes de IA em produção: responsividade sob escala, controle mais fino sobre a alocação de recursos e custos que acompanham o uso real.
A AWS descreve o AgentCore runtime como o ambiente totalmente gerenciado em que desenvolvedores implantam e executam agentes sem construir ou manter infraestrutura. Segundo a empresa, milhares de equipes usam o serviço para operar agentes em produção desde o lançamento.
Essa base ajudou a moldar a nova versão.
Do chatbot ao agente sempre ligado
O material da AWS traça uma evolução. Muitos agentes nasceram como chatbots: pergunta, resposta, troca encerrada em segundos.
Depois vieram os agentes de programação, que trabalham por minutos ou horas e mantêm contexto ao longo de vários passos, com ou sem alguém olhando.
Agora, diz a empresa, os agentes se tornam ambientes: sempre ligados, disparados por eventos, rodando sem supervisão e aparecendo apenas quando um trabalho termina ou quando encontram uma decisão que exige uma pessoa.
Eles também são muito mais numerosos, embutidos em produtos, atrás de funcionalidades cotidianas e, cada vez mais, acionados por outros agentes.
A primeira geração do runtime oferecia serverless, isolamento de sessão, escala até zero e cobrança apenas pelo que fosse usado. A nova versão, segundo a AWS, estende essa base para todo o espectro.
Permanece rápida e consistente para agentes interativos e durável e acessível para agentes autônomos de longa duração.
Memória no pico e a conta que não fecha
O primeiro gargalo apontado pela AWS é a memória. Em modelos anteriores, uma sessão mantinha a memória alocada do momento da reserva até o encerramento, porque nada a recuperava no caminho.
Isso funciona quando o espaço reservado serve a recursos seguintes sem o custo de latência de buscá-los de novo. O problema aparece em agentes longos ou com picos: eles continuam pagando pelo ponto mais alto durante toda a execução, mesmo depois de terem deixado de usar aquela memória.
Para um agente que dá picos ocasionais e fica parado a maior parte do dia, é a diferença entre pagar pelo pico 24 horas por dia e pagar pelo uso real.
O novo runtime devolve a memória no instante em que a sessão se encerra, em vez de retê-la no pico.
Cold start previsível, independente do tamanho
O segundo gargalo é o tempo de inicialização. Toda sessão precisa subir antes de trabalhar, e a AWS lembra que a previsibilidade importa especialmente quando uma pessoa espera por um agente que pausou para receber uma entrada e precisa retomar.
Há um detalhe técnico: pelo isolamento imposto por hardware de que essas sessões dependem, uma sessão que cai em um ambiente já inicializado começa em menos de 100 milissegundos. Mas manter ambientes quentes o suficiente para garantir isso significa segurar computação reservada.
Na prática, a maioria das sessões começa com cold start: inicializar um ambiente novo, baixar a imagem e preparar o agente antes da primeira requisição.
Essa penalidade de latência cresce com o tamanho da imagem e com a concorrência, e é pior sob tráfego em rajada, exatamente quando chegam mais sessões e restam menos ambientes prontos. A inconsistência, diz a AWS, é o que o usuário sente.
O novo runtime promete cold starts consistentes independentemente do tamanho do contêiner ou da concorrência do agente.
Por que isso importa
O modelo de cobrança é parte central da proposta. A AWS afirma que o cliente paga apenas pelo que consome, e não por CPU ociosa esperando operações de entrada e saída.
A cobrança acompanha o uso de recursos, sem tarifa fixa por capacidade provisionada "por precaução". A plataforma escala até zero: quando não há trabalho, nada roda e nada é cobrado; quando o trabalho chega, a capacidade necessária é disponibilizada.
Combinados, os dois fatores tornam barato manter muitos agentes parados a maior parte do tempo e também barato operar um agente que fica ocupado. O modelo de consumo se ajusta à carga, em vez de forçar a carga a se ajustar a ele.
A AWS também reconhece que, diante desses dois desafios, clientes costumavam construir o próprio maquinário para contorná-los. A nova versão busca eliminar essa alternativa pesada ao incorporar a gestão de memória e a previsibilidade de inicialização na própria camada gerenciada.
Para equipes que operam agentes acionados por eventos e sem supervisão, a mudança desloca o esforço de engenharia de infraestrutura para o comportamento do agente em si.
Fontes e links
- AWS — matéria original: "The new AgentCore runtime: Elastic, optimized, and consistently fast starts", publicada em 18 de setembro de 2026.
