A AWS adicionou ao Bedrock AgentCore armazenamento persistente de sessões e execução de comandos shell

AWS adicionou armazenamento persistente de sessões e execução de comandos shell ao Bedrock AgentCore

AWS demonstrou como resolver dois problemas típicos de ambientes de agentes no Amazon Bedrock AgentCore Runtime: perda de arquivos após o encerramento da sessão e execução de comandos previsíveis como testes ou operações git através do próprio modelo. Os novos recursos permitem preservar o estado de trabalho de um agente entre reinicializações e executar comandos shell diretamente em seu ambiente.

O que está mudando

Anteriormente, uma sessão de agente no AgentCore vivia dentro de uma microVM separada com recursos isolados, sua própria memória e sistema de arquivos. Isso é bom para segurança, mas inconveniente na prática: se um agente passou 20 minutos instalando dependências, gerando um projeto e modificando código, tudo isso poderia desaparecer após o encerramento da sessão. Na próxima inicialização, você tinha que baixar novamente o repositório, implementar o ambiente e refazer o trabalho já concluído. Para fluxos de trabalho de agentes, isso significava tempo desperdiçado e custos computacionais desnecessários.

O segundo problema é ações determinísticas. Quando você simplesmente precisa executar uma suíte de testes, linter ou comando git push, não faz sentido enviar isso através de um LLM. O modelo adiciona latência, custos de token e incerteza desnecessária onde o comando já é conhecido antecipadamente. AWS propõe dividir os papéis: o agente lida com raciocínio e alterações de código, enquanto a plataforma executa diretamente comandos na mesma sessão. Para cenários de produção, essa separação de responsabilidades parece muito mais prática.

Como funciona

O primeiro recurso — armazenamento de sessão gerenciado — está atualmente em status de visualização pública. Ao criar um runtime, você pode especificar um diretório persistente, como um caminho dentro do diretório /mnt. Tudo que o agente escreve nesta pasta é preservado entre parada e retomada, mesmo que a microVM em si seja destruída e um novo ambiente computacional seja iniciado no próximo lançamento. Ao mesmo tempo, a lógica de salvamento está integrada ao runtime, então o agente não precisa de código separado para checkpoint, serialização ou upload manual de arquivos para armazenamento de objetos.

AWS mostra um cenário próximo ao desenvolvimento real: no primeiro dia, o agente baixa o projeto, descompacta-o e configura as dependências, e no segundo dia continua trabalhando com o mesmo runtime-session-id. Ele vê o mesmo código-fonte, pasta node_modules, artefatos de build e histórico .git sem reinicialização.

Por padrão, esses dados são armazenados por 14 dias de inatividade, e o tamanho máximo por sessão é de 1 GB. Para equipes que trabalham com grandes bases de código, isso já é suficiente para um ciclo completo de vários dias.

O ambiente computacional de ontem já desapareceu, mas o sistema de

arquivos foi preservado.

O segundo recurso — InvokeAgentRuntimeCommand. Ele executa comandos shell diretamente dentro da sessão ativa do AgentCore Runtime e transmite stdout e stderr conforme é executado. Um detalhe importante: o comando é executado não em um processo sidecar separado e não através de um orquestrador externo, mas no mesmo container e com o mesmo sistema de arquivos onde o agente opera. Se o agente escreveu um arquivo na pasta de trabalho, o comando pode imediatamente lê-lo, testá-lo ou confirmá-lo. Ao mesmo tempo, cada comando é iniciado como um processo bash separado: sem uma sessão de shell compartilhada, sem transferência de histórico de comando e sem preservação de variáveis de ambiente entre chamadas.

Onde isso será útil

Para equipes de engenharia, essa combinação é especialmente útil em cenários onde um agente não apenas responde em um chat, mas realmente lidera um ciclo de trabalho sobre uma base de código. AWS enfatiza especificamente que comandos shell são melhor usados onde o resultado deve ser estritamente reproduzível e observável. Em outras palavras, o modelo raciocina e faz alterações, enquanto todos os passos previsíveis de verificação e entrega são melhor entregues à plataforma sem chamadas de ferramenta desnecessárias através do LLM.

• Executar testes após alterações do agente: npm test, pytest e outras verificações
• Operações git: criação de branch, commit, push sem lógica de controle de versão dentro do LLM
• Preparação do ambiente: clonagem de repositório, instalação de pacotes, configuração de ferramentas de build
• Portais de validação: linters, verificadores de tipo, scanners de segurança antes do commit
• Depuração do ambiente: verificação de pacotes instalados, espaço em disco e processos durante falhas do agente

Também existem limitações. A microVM básica não possui um conjunto completo de ferramentas de desenvolvimento, então git, npm, runtimes de linguagem e outras dependências precisam ser adicionadas à imagem do container com antecedência ou instaladas durante a operação. Além disso, o estado não é preservado entre comandos, então mudar de diretório ou exportar variáveis precisa ser incluído diretamente no próprio comando. Este é um modelo de execução única que funciona bem para testes e compilações, mas não substitui uma sessão de shell interativa ao vivo.

O que significa

AWS está tornando o Bedrock AgentCore mais próximo não de chatbots, mas de um ambiente completo para desenvolvimento de agentes. Se anteriormente o agente perdia contexto no nível de arquivo e exigia integração externa para testes e comandos git, agora ambas as tarefas são tratadas dentro de um único runtime. Para equipes que constroem agentes de codificação, isso reduz a orquestração desnecessária e torna o ciclo "agente escreve — plataforma verifica — trabalho é salvo" significativamente mais prático. Especialmente onde um processo de vários dias de trabalho no mesmo repositório é importante.