AWS added persistent session storage and shell command execution to Bedrock AgentCore

AWS added persistent session storage and shell command execution to Bedrock AgentCore

AWS demonstrated how to solve two typical problems of agent environments in Amazon Bedrock AgentCore Runtime: loss of files after session termination and execution of predictable commands like tests or git operations through the model itself. The new capabilities allow you to preserve an agent's working state between restarts and execute shell commands directly within its environment.

What's changing

Previously, an agent session in AgentCore lived inside a separate microVM with isolated resources, its own memory, and file system. This is good for security, but inconvenient in practice: if an agent spent 20 minutes installing dependencies, generating a project, and modifying code, all of this could disappear after the session stopped. On the next startup, you had to re-download the repository, deploy the environment, and redo the work already completed. For agent workflows, this meant wasted time and unnecessary computational costs.

The second problem is deterministic actions. When you simply need to run a test suite, linter, or git push command, there's no point in sending this through an LLM. The model adds latency, token costs, and unnecessary uncertainty where the command is already known in advance. AWS proposes dividing the roles: the agent handles reasoning and code changes, while the platform directly executes commands in the same session. For production scenarios, such a separation of responsibilities looks much more practical.

How it works

The first feature — managed session storage — is currently in public preview status. When creating a runtime, you can specify a persistent directory, such as a path within the /mnt directory. Everything the agent writes to this folder is preserved between stop and resume, even if the microVM itself is destroyed and a new computational environment is spun up on the next launch. At the same time, the save logic is built into the runtime, so the agent doesn't need separate code for checkpointing, serialization, or manual file uploads to object storage.

AWS shows a scenario close to real development: on day one, the agent downloads the project, unpacks it, and sets up dependencies, and on day two continues working with the same runtime-session-id. It sees the same source code, node_modules folder, build artifacts, and .git history without re-initialization.

By default, such data is stored for 14 days of inactivity, and the maximum size per session is 1 GB. For teams working with large code bases, this is already sufficient for a full multi-day cycle.

Yesterday's computational environment is already gone, but the file

system has been preserved.

The second feature — InvokeAgentRuntimeCommand. It executes shell commands directly within the active AgentCore Runtime session and streams stdout and stderr as it executes. An important detail: the command runs not in a separate sidecar process and not through an external orchestrator, but in the same container and with the same file system where the agent operates. If the agent wrote a file to the working folder, the command can immediately read it, test it, or commit it. At the same time, each command starts as a separate bash process: without a shared shell session, without command history transfer, and without environment variable preservation between calls.

Where this will be useful

For engineering teams, this combination is especially useful in scenarios where an agent doesn't just answer in a chat, but actually leads a working cycle over a code base. AWS specifically emphasizes that shell commands are best used where the result should be strictly reproducible and observable. In other words, the model reasons and makes changes, while all predictable verification and delivery steps are better handed over to the platform without unnecessary tool-calling through the LLM.

• Running tests after agent changes: npm test, pytest and other checks
• Git operations: branch creation, commit, push without version control logic inside the LLM
• Environment preparation: cloning a repository, installing packages, configuring build tools
• Validation gates: linters, type checkers, security scanners before commit
• Environment debugging: checking installed packages, disk space, and processes during agent failures

There are also limitations. The basic microVM doesn't have a full set of development tools, so git, npm, language runtimes, and other dependencies need to be added to the container image in advance or installed during operation. Additionally, state is not preserved between commands, so changing directories or exporting variables needs to be included directly in the command itself. This is a one-shot execution model that works well for tests and builds, but doesn't replace a live interactive shell session.

What it means

AWS is making Bedrock AgentCore closer not to chatbots, but to a full-fledged environment for agent development. If previously the agent lost context at the file level and required external integration for tests and git commands, now both tasks are handled within a single runtime. For teams building coding agents, this reduces unnecessary orchestration and makes the "agent writes — platform verifies — work is saved" cycle significantly more practical. Especially where a multi-day process of working on the same repository is important.