Agentes de IA chegaram à produção — e a infraestrutura precisou evoluir
Agentes de Inteligência Artificial (IA) deixaram de ser experimentos. Hoje eles processam solicitações de seguro, escrevem e revisam código, coordenam sistemas inteiros e operam por horas sem supervisão humana. À medida que essas cargas de trabalho ficam mais complexas e longas, a infraestrutura que as sustenta precisa acompanhar o mesmo ritmo.
Foi nesse contexto que a AWS construiu o Amazon Bedrock AgentCore: uma plataforma para que desenvolvedores possam criar, conectar e otimizar agentes com segurança e escala. O AgentCore Runtime é a camada de computação gerenciada dessa plataforma — um ambiente totalmente administrado onde você implanta e executa agentes sem precisar provisionar ou manter infraestrutura.
Desde o lançamento, milhares de equipes utilizaram o serviço para rodar agentes em produção. O feedback coletado apontou três necessidades claras: maior responsividade à medida que as cargas crescem, controle mais fino sobre alocação de recursos e um modelo de cobrança que reflita o uso real. A AWS respondeu a esse feedback com o lançamento do novo AgentCore Runtime.
A evolução dos agentes: de chatbots a processos autônomos
Para entender por que o novo runtime importa, vale acompanhar como os agentes evoluíram. No início, a maioria funcionava como chatbots simples: você perguntava, o agente respondia em segundos e a conversa terminava. Depois vieram agentes de codificação, capazes de trabalhar por minutos ou horas mantendo contexto ao longo de muitos passos.
Agora os agentes estão se tornando ambient — sempre ativos, acionados por eventos, operando sem supervisão e sinalizando apenas quando um trabalho termina ou quando uma decisão humana é necessária. E há muito mais deles: não são mais novidades, mas componentes embarcados em produtos, por trás de funcionalidades cotidianas e, cada vez mais, lançados por outros agentes.
A primeira versão do AgentCore Runtime criou uma base sólida para esse espectro: modelo serverless, isolamento de sessão, escala até zero e pagamento apenas pelo que é usado. A nova versão estende essa base para cobrir todo o espectro — mantendo velocidade e consistência para agentes interativos, e durabilidade com custo acessível para agentes de longa duração e mais autônomos.
O que o AgentCore Runtime oferece
O modelo de consumo do AgentCore Runtime tem dois pilares que justificam sua adoção:
- Pagamento apenas pelo que é consumido, sem cobrança por Unidade Central de Processamento (CPU) ociosa aguardando Entrada/Saída (I/O). Não há custo fixo por capacidade provisionada “por precaução”.
- Escala até zero: quando um agente não está processando nada, não há nada rodando — e, portanto, nada a pagar. Quando o trabalho chega, a plataforma provisiona a capacidade necessária.
Juntos, esses dois pilares tornam barato manter muitos agentes ociosos na maior parte do tempo, sem abrir mão da capacidade de atender picos de demanda. O modelo de consumo se adapta à carga de trabalho, não o contrário.
Os dois desafios que o novo runtime resolve
Memória cara: você pagava pelo pico
No runtime original, uma sessão mantinha a memória alocada desde o momento em que a reservava até o encerramento da sessão — nada era liberado ao longo do caminho. Isso funciona quando a memória alocada é usada para atender requisições subsequentes sem incorrer em latência para buscá-la novamente. Porém, um agente de longa duração ou com picos de uso continuava pagando pelo ponto mais alto de consumo durante todo o tempo de execução, muito depois de ter parado de usar aquela memória.
Cold starts imprevisíveis
Toda nova sessão precisa inicializar antes de executar qualquer trabalho. Isso é especialmente crítico quando uma pessoa aguarda a resposta de um agente que pausou para receber input e precisa retomar. O problema é que a inicialização a frio (cold start) — que envolve subir um novo ambiente, baixar a imagem e inicializar o agente — crescia proporcionalmente ao tamanho da imagem e à concorrência. Sob tráfego em rajada, exatamente quando mais sessões chegam e menos ambientes prontos existem, a latência era pior.
Para contornar esses problemas, equipes precisavam construir e manter a própria infraestrutura: manter ambientes reservados para evitar cold starts, otimizar alocação de memória e depois desligar tudo para controlar custos. Trabalho indiferenciado que nada tem a ver com o agente em si.
O que muda com o novo AgentCore Runtime
Memória alocada sob demanda e liberada quando não é mais usada
O novo runtime inicia cada sessão a partir de um perfil de memória pequeno e eficiente, em vez de um footprint totalmente provisionado. Memória adicional é alocada e carregada sob demanda conforme a carga de trabalho precisa. Com base na análise de padrões de alocação em bilhões de sessões, a AWS ajustou o novo runtime para recuperar memória quando ela fica “fria” e é improvável que seja acessada novamente — sem esperar o fim da sessão para fazer isso.
No runtime original, a memória alocada permanecia retida mesmo que não fosse usada por requisições subsequentes, então o uso rastreava o pico histórico. Com o novo runtime, memória liberada ou fria é recuperada, e a cobrança acompanha essas variações ao longo do tempo de vida da sessão.
Cold starts rápidos e consistentes, independente do tamanho da imagem
Como o perfil de inicialização é menor, os cold starts ficam mais rápidos como consequência direta. O novo runtime prepara o ambiente uma vez, captura um snapshot desse estado e restaura esse snapshot para cada nova instância. Como o snapshot permanece pequeno e consistente, os tempos de inicialização também ficam — independentemente do tamanho da imagem ou do nível de concorrência.
Em vez de repetir o trabalho de boot e inicialização a cada cold start, a plataforma restaura um ambiente já pronto. O trabalho de inicialização é pago uma única vez, e cada instância herda esse estado instantaneamente. Além disso, o runtime mantém o snapshot enxuto: em vez de capturar todo o estado em memória de um processo em execução (incluindo caches e memória transitória que inflariam o snapshot), o novo runtime remove esse excesso. O resultado é um snapshot cujo tamanho permanece aproximadamente constante conforme a imagem do container cresce.
Números medidos pela AWS
Para isolar o que a plataforma em si adiciona a um cold start, a AWS testou um agente echo vazio — que apenas retorna o input sem chamar nenhum modelo ou ferramenta. Um cliente Python em uma instância do Elastic Compute Cloud (EC2) na região us-west-2 chamou agentes em us-east-1 pela internet pública sem emparelhamento de Nuvem Virtual Privada (VPC), usando o SDK boto3. Foram enviadas 5.000 invocações frias por agente em ambas as versões e em cinco tamanhos de imagem.
O resultado: o novo runtime entrega uma latência de cold start no Percentil 75 (P75) de aproximadamente 2 segundos, de uma imagem de 200 MB até 2 GB — o tamanho da imagem não tem efeito. A latência do runtime original, por contraste, sobe com o tamanho da imagem: de cerca de 5,4 segundos para quase 30 segundos.
Vale separar o tempo de cold start do que o usuário realmente espera. O tempo de inicialização é quanto tempo leva para ter um ambiente pronto antes que o código do agente processe a primeira requisição — não é o tempo que o agente passa trabalhando. Em produção, a maior parte do tempo percebido pelo usuário vem do loop do agente e das chamadas ao modelo, muitas vezes vários segundos cada. No teste echo, o código do próprio agente rodou em cerca de 34 milissegundos no P75 — quase tudo era tempo de inicialização da plataforma.
Dica prática para agentes interativos: é possível esconder quase completamente o tempo de cold start iniciando a sessão assim que o usuário abre o chat — antes mesmo de ele digitar qualquer coisa. A sessão aquece enquanto o usuário é recebido e enquanto digita a primeira mensagem, então quando ele envia, o ambiente já está pronto.
Cobrança mais justa: taxa maior, footprint muito menor
O novo runtime cobra pela memória que o agente realmente usa — carregada sob demanda e recuperada quando ociosa — não pela manutenção de toda a imagem do container em memória durante a sessão. A taxa por unidade é mais alta, mas incide sobre muito menos GB-hora. Para a maioria dos agentes, a redução do footprint supera o aumento da taxa, e a conta cai.
O que está por vir
Além do que foi entregue hoje, a AWS sinalizou que várias capacidades adicionais estão a caminho:
- Descontos por baseline comprometido: além do modelo de consumo atual (ideal para cargas com picos e escala a zero), haverá uma opção de precificação baseline — você reserva um piso de memória para uma sessão e ultrapassa esse limite sob demanda. Indicado para sessões de agentes sempre ativas que precisam de custo previsível.
- Computação e armazenamento maiores: mais RAM, vCPU e armazenamento de sessão para agentes que demandam mais recursos.
- Suporte a x86: execução de agentes, ferramentas ou ambientes já existentes em microVMs x86, sem necessidade de reescrever código ou dependências.
- Maior controle de ciclo de vida: suspender e retomar sessões com snapshotting de memória, além de hooks de runtime para serializar estado antes de uma sessão ativa ser encerrada — permitindo que sessões sejam retomadas indefinidamente.
- Identidade com escopo para agentes autônomos: chaves de contexto de sessão darão a cada sessão sua própria identidade com escopo, garantindo que um agente não supervisionado aja exatamente com as permissões definidas para ele — nem mais, nem menos.
Como começar
Para usar o novo runtime, basta definir o parâmetro platformVersion como V2 ao criar ou atualizar um runtime. O Guia do Desenvolvedor do AgentCore traz mais detalhes sobre como usar o runtime. Exemplos práticos estão disponíveis no repositório de exemplos do AgentCore no GitHub, incluindo um exemplo de teste de carga que demonstra a latência consistente de cold start do novo runtime na sua própria conta AWS.
Fonte
The new AgentCore runtime: Elastic, optimized, and consistently fast starts (https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)
Leave a Reply