AWS Bedrock AgentCore em produção: runtime persistente

TL;DR

O Amazon Bedrock AgentCore Runtime saiu do desenho apenas serverless e passou a oferecer sessões persistentes para agentes que precisam ficar vivos por mais tempo em produção. Na prática, isso muda o jogo para workloads que exigem estado contínuo, GPU ou coordenação entre múltiplos agentes, sem abandonar o controle de capacidade e lifecycle.

O ponto central é simples: você escolhe entre microVMs, com teto de até 8 horas, ou Runtime Instances via capacity providers, que podem chegar a 14 dias. Para operação real, isso se combina com quotas de concorrência, novas sessões por segundo e timers de idle e lifetime, o que ajuda a sair do protótipo e entrar em um desenho operacional previsível.

O que mudou no AgentCore Runtime

O anúncio da AWS sobre Runtime Instances explicita a direção do produto: agentes de produção precisam de persistência, não apenas de invocação curta. O runtime agora separa o tipo de compute de acordo com a necessidade do workload, em vez de tratar todo agente como uma execução efêmera.

Isso aparece de forma clara na documentação de compute types do AgentCore Runtime: microVMs para execução serverless e Runtime Instances para cenários long-running. É uma divisão útil porque o desenho técnico do agente passa a refletir o ciclo de vida real da aplicação, e não só a chamada HTTP que dispara a sessão.

microVMs e Runtime Instances: quando usar cada um

Segundo a documentação oficial de AgentCore Runtime, microVMs suportam sessões de até 8 horas, enquanto Runtime Instances chegam a 14 dias. Isso não é apenas uma diferença de tempo; é uma diferença de arquitetura.

As microVMs fazem mais sentido quando você quer start rápido, escala sob demanda e uma operação mais simples. Já Runtime Instances entram quando o agente precisa manter estado por mais tempo, rodar com GPU ou coordenar vários agentes na mesma máquina. A documentação de how it works mostra que a sessão está vinculada ao `runtimeSessionId`, o que permite retomar a execução de forma consistente.

Esta seção descreve o comportamento atual da plataforma. APIs e limites de serviços de IA mudam rápido — confira a documentação oficial antes de usar o desenho em produção.

Persistência prática: sessão, restart e volume

Em Runtime Instances, a persistência não é só conceitual. A AWS documenta que, ao atingir a máxima lifetime, o AgentCore encerra a instância, mas mantém volumes persistentes; ao retomar com o mesmo `runtimeSessionId`, o runtime re-provisiona e reanexa o storage. Esse detalhe é importante para agentes que mantêm contexto local, arquivos temporários ou artefatos intermediários.

Na prática, isso evita que a lógica do agente dependa apenas de memória volátil. Para times que já sofreram com perda de contexto em orquestrações longas, essa combinação de sessão persistente e armazenamento reanexável reduz retrabalho de engenharia e simplifica a retomada de fluxos interrompidos.

Capacidade e limites: o que controla a operação em produção

O outro eixo do problema é capacidade. A atualização da AWS sobre default runtime quota limits aumentou os limites padrão para suportar carga operacional maior, com números diferentes conforme a região. Isso importa porque um agente “funcionando” em laboratório pode falhar quando começa a concorrência real de um time inteiro.

Os números destacados no anúncio incluem até 5.000 sessões concorrentes ativas em us-east-1 e us-west-2, 2.500 em outras regiões, além de 200 interações por segundo e 25 novas sessões por segundo. Para arquitetura, isso significa que o gargalo não é só o modelo de IA: o runtime, a criação de sessão e a cadência de entrada também entram no planejamento.

Lifecycle settings por sessão

A documentação de lifecycle settings mostra que `idleRuntimeSessionTimeout` e `maxLifetime` são configuráveis por sessão. O comportamento padrão citado é de 900 segundos para idle timeout e 28.800 segundos para maxLifetime em microVMs, com extensão até 1.209.600 segundos quando a execução roda em capacity provider.

Esse modelo é útil porque permite alinhar custo e comportamento. Se a sessão pode ser retomada com segurança após uma pausa, faz sentido deixar o runtime sobreviver mais tempo; se a interação é curta e previsível, vale encurtar timers para reduzir consumo desnecessário.

Onde está o ponto de atenção real

O ponto de atenção não é só “quantas sessões cabem”, mas como o sistema se comporta quando encosta no limite. O lifecycle pode encerrar uma instância, reprovisionar outra e manter o estado, mas isso precisa casar com idempotência, recuperação de falhas e armazenamento bem definido. Se o agente espalha estado em cache local sem estratégia de persistência, a promessa de continuidade vira apenas uma pausa com perda de contexto.

Também vale observar que regiões fora de us-east-1 e us-west-2 têm default menor de sessions concorrentes. Para times que operam no Brasil, isso pesa no desenho inicial porque boa parte do consumo corporativo brasileiro ainda fica ancorada em regiões dos EUA, e a latência de ida e volta para cargas interativas pode afetar tanto UX quanto custo de retry.

O papel dos capacity providers

O blog da AWS sobre Runtime Instances trata capacity providers como a forma de contratar o compute certo para o runtime. A ideia operacional é selecionar a capacidade permitida, em vez de deixar a execução totalmente abstrata.

Esse desenho ajuda quando o agente tem exigências não triviais de hardware. Se você precisa de GPU ou de um host com perfil específico para rodar múltiplos componentes cooperando, o runtime deixa de ser apenas “inferência” e passa a ser uma unidade operacional com requisitos bem definidos.

Por que importa para o dev brasileiro

No Brasil, o impacto aparece em duas frentes concretas: custo e operação. Muitos times trabalham com orçamento em BRL sensível à cotação do dólar, então um agente que fica recomeçando ou perdendo contexto tende a gerar mais chamadas, mais persistência externa e mais engenharia de cola. Além disso, uma parcela relevante das cargas corporativas brasileiras ainda opera em regiões da AWS nos EUA, o que torna a escolha entre sessão curta e runtime persistente um ponto de latência real e não só teórico.

Há também o aspecto regulatório. Quando o agente lida com dados pessoais, logs e artefatos de conversa, o desenho de persistência precisa considerar a LGPD, especialmente na forma como o estado é armazenado, reanexado e eliminado. Persistência técnica sem política de retenção e descarte vira risco operacional, não só uma escolha de produto.

Para quem trabalha em empresas brasileiras de varejo, finanças ou atendimento, isso é especialmente prático: um assistente que mantém uma sessão longa para resolver um caso complexo evita reabrir o mesmo contexto várias vezes, mas precisa ter controles claros de timeout, expiração e auditoria. Em ambiente real, o agente não conversa apenas com um usuário; ele também conversa com compliance, observabilidade e custos.

Como pensar a arquitetura antes de ir para produção

Um bom ponto de partida é separar o tipo de tarefa antes de escolher o compute. Conversas curtas, automações pontuais e fluxos com baixa necessidade de contexto podem ficar em microVMs; fluxos longos, coordenação entre agentes e tarefas que dependem de estado persistente pedem Runtime Instances. A documentação oficial de AgentCore Runtime já dá essa pista de forma explícita.

Depois disso, modele três dimensões: duração da sessão, volume de concorrência e tolerância à retomada. Se o fluxo pode ser interrompido e retomado com o mesmo `runtimeSessionId`, vale desenhar checkpoints e armazenamento persistente de forma deliberada. Se a sessão não pode voltar a um estado anterior, o custo de falha sobe rápido e o runtime persistente deixa de ser vantagem.

Por fim, trate os limites como parte do design. Os números de quota e os timers de lifecycle não devem ser lidos como detalhe administrativo, mas como contrato operacional. Em sistemas de agente, esse contrato é tão importante quanto o prompt ou o modelo, porque define se a experiência vai sobreviver ao uso real.

Conclusão

O Bedrock AgentCore Runtime sinaliza que a AWS está levando agentes para uma operação mais próxima de sistemas distribuídos do que de simples chamadas de IA. A diferença entre microVMs e Runtime Instances não é cosmética: ela define quanto estado você consegue manter, por quanto tempo e com qual controle de capacidade.

Se você estiver planejando um piloto em produção, comece mapeando quais fluxos realmente precisam de persistência de dias, quais podem viver com 8 horas e quais dependem de timers de idle mais agressivos. Em seguida, abra a documentação de lifecycle settings e revise os limites do seu caso antes de habilitar o primeiro agente em produção.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.