AWS Bedrock AgentCore ganha compute persistente para agentes que rodam por até 14 dias

A Amazon Web Services↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → adicionou uma segunda opção de compute ao Bedrock AgentCore: as runtime instances, que rodam agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → sobre EC2 gerenciado dentro da conta do próprio cliente, mantendo as mesmas APIs, controles de identidade e modelo de observabilidade do AgentCore original. O anúncio foi publicado no blog do Bedrock AgentCore e detalhado pelo principal developer advocate Sebastien Stormacq.

O ponto central é o tempo de execução. O AgentCore nasceu baseado em sessões serverless sobre microVMs, com teto de oito horas por sessão. As runtime instances quebram esse limite: oferecem sessões persistentes lastreadas em EC2 que podem durar até 14 dias, com sistema de arquivos compartilhado, tipos de instância acelerados por GPU e suporte a Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → e imagens de container.

O que muda na prática para times multi-agente

A grande diferença arquitetural é a colocação de vários agentes no mesmo host. Em vez de cada handoff entre agentes virar uma chamada de API, múltiplos agentes podem ser implantados em um mesmo runtime e colaborar através de um diretório de sessão compartilhado. Segundo Stormacq, os agentes podem "chamar uns aos outros como ferramentas dentro de uma sessão compartilhada, iterando de forma autônoma até que o trabalho esteja concluído".

O exemplo usado no anúncio ilustra o padrão que a feature quer atender: vários agentes especializados operando sobre um diretório de trabalho comum, com código, testes, documentação e artefatos de segurança. É o tipo de fluxo em que a latência e o custo de ficar serializando estado entre chamadas de API pesavam.

Para quem já escreve agentes, a adoção tende a ser de baixo atrito. Frameworks como CrewAI, LangGraph, LlamaIndex e Strands rodam sem mudança no modelo de empacotamento, usando um decorator @app.entrypoint e entregando ou um arquivo zip ou uma imagem de container. O engenheiro Kosti Vasilakakis observou no LinkedIn que as runtime instances reutilizam as mesmas APIs do AgentCore e o modelo de session pinning que os times já usam, reduzindo o custo de migração.

O primitivo de capacity provider

Um guia de engenharia da Enkompass aprofunda o novo primitivo que sustenta as runtime instances: o capacity provider. Ele define as famílias de instância permitidas, o sistema operacional, a rede e o armazenamento, funcionando como um contrato entre os agentes e a capacidade EC2 que o AgentCore vai provisionar, aplicar patches e escalar por conta própria.

O time define limites como número mínimo e máximo de instâncias e utilização alvo, e então anexa um ou mais runtimes de agente a esse provider, com TTL de sessão de até 14 dias. Na prática, isso evita ter que gerenciar Auto Scaling groups, launch templates ou pipelines de AMI na mão, que era o trabalho braçal que empurrava times a manter frotas EC2 separadas.

Quando usar cada modelo (e o cálculo de custo)

A AWS posiciona as runtime instances como complementares aos microVMs, não como substituição. A recomendação da Enkompass é clara sobre a divisão:

• microVMs continuam sendo o default para agentes curtos, em rajada, no estilo request/response, porque iniciam rápido, isolam sessões e cobram por segundo sobre CPU real e pico de memória, até o teto de oito horas.
• runtime instances brilham em cargas que precisam de mais de oito horas contínuas, exigem GPU ou grande footprint de memória, ou se beneficiam de vários agentes co-localizados no mesmo host.

Um padrão híbrido incentivado pela própria AWS: um agente orquestrador em microVMs despacha trabalho longo para workers em instances.

O custo é o ponto onde a decisão fica concreta. Uma análise da eCorpIT detalha o trade-off: as runtime instances são cobradas às tarifas padrão de EC2 para o tipo de instância escolhido, mais uma taxa de gerenciamento. Já os microVMs cobram por vCPU-hora e por GB-hora, sem taxa de gerenciamento separada, o que os deixa mais baratos para agentes com baixa utilização sustentada de CPU e longos períodos ociosos.

O ponto de equilíbrio apontado fica em torno de 24% de utilização sustentada de CPU para as runtime instances, antes de qualquer desconto de Savings Plan. E como as instances rodam na conta do cliente, descontos de compromisso EC2 (Savings Plans e Reserved Instances) valem para a parte de compute, mas não para a taxa de gerenciamento. Os dois principais controles de custo, segundo a análise, são co-localizar vários agentes num único host e parar as sessões assim que o trabalho termina.

O contexto: evolução do AgentCore e o movimento da concorrência

As runtime instances são mais um passo numa trajetória que a AWS vem construindo em torno de agentes: do lançamento original do AgentCore, passando pelo suporte ao protocolo Agent-to-Agent para workflows multi-agente interoperáveis, até o Agent Registry e a plataforma de referência Loom para deploys governados.

O movimento não está isolado. A Microsoft seguiu abordagem parecida com os agentes hospedados no Azure Foundry, que provisionam sandboxes de VM por sessão com diretórios home e armazenamento persistentes, restaurando estado automaticamente quando a sessão retoma após ociosidade ou reinício, com suporte a execuções multi-agente integradas a Teams e Microsoft 365 Copilot.

O que isso muda para quem constrói no Brasil

Para equipes brasileiras que já operam sobre a nuvem da AWS, a novidade tira do caminho um obstáculo prático: cargas de agente longas, com estado ou dependentes de GPU deixam de exigir uma frota EC2 paralela gerenciada manualmente. Rodar na própria conta também mantém os dados e o compute dentro da infraestrutura já contratada, ponto relevante para quem lida com requisitos de residência de dados e usa Savings Plans para controlar custo.

O que fica em aberto é a análise financeira caso a caso. Com o break-even em torno de 24% de utilização de CPU e a taxa de gerenciamento fora dos descontos de compromisso, a escolha entre microVM e instance passa a depender de medir o perfil real de cada agente, não de uma regra única. A disponibilidade por região no Brasil e as tarifas locais também precisam entrar na conta antes de mover workloads em produção. A documentação técnica está na página de runtime instances do AgentCore.

Fonte: InfoQ