AWS AgentCore Ships Persistent Filesystem and Shell Execute — Production Coding Agents Without Custom Glue
Two problems have blocked production coding agents on Amazon Bedrock AgentCore since launch. Every session booted to a clean filesystem, so twenty minutes of scaffolding, dependency installation, and code generation vanished when a session stopped. And every deterministic operation — npm test, git push, pytest — had to route through the LLM, adding latency, token cost, and hallucination risk to commands that have no business touching a language model.
Both are now fixed.
Managed Session Storage: 1 GB Per Session, 14-Day Retention
The first capability adds a persistent directory at a mount path you specify — /mnt/workspace is the pattern — backed by S3 and transparent to agent code. Configure it once at runtime creation:
--filesystem-configurations '[{"sessionStorage": {"mountPath": "/mnt/workspace"}}]'
Agent code does not change. Files written to that path persist across stop/resume cycles. A session stopped overnight resumes with source files, node_modules, build artifacts, and .git history intact. The compute environment (microVM) is gone; the filesystem is not.
Limits: 1 GB per session. Data deleted after 14 days of idle time. Updating the agent runtime version resets the session to a clean state.
InvokeAgentRuntimeCommand: Shell Directly in the Agent’s Container
The second capability — InvokeAgentRuntimeCommand — executes shell commands inside the same container and filesystem as the running agent. No sidecar. No socket. No file transfer. A file the agent wrote at /mnt/workspace/fix.py is immediately visible to a command running cat /mnt/workspace/fix.py.
The response streams three event types: contentStart (command started), contentDelta (stdout/stderr as produced), contentStop (exit code + COMPLETED/TIMED_OUT status). Failures surface in the first few seconds rather than after the full run.
The design is explicit about what belongs in each path:
| Use execute command | Use the agent |
|---|---|
npm test, git push, cargo build | ”Analyze this code and fix the bug” |
| Validation gates before committing | Multi-step reasoning with tools |
| Environment bootstrapping | Creative or analytical work |
The Production Pattern
The combined workflow: agent reasons on a task, writes code to /mnt/workspace, execute command runs the test suite, exit code routes back to the agent for iteration. Stop overnight. Resume the next morning with the same workspace, test results, and git history. No warm-up.
# Agent writes the fix
client.invoke_agent_runtime(agentRuntimeArn=ARN, runtimeSessionId=SESSION,
payload=json.dumps({"prompt": "Read JIRA-1234 and implement the fix"}).encode())
# Command validates deterministically
exit_code = run_command('/bin/bash -c "cd /mnt/workspace && npm test"', timeout=300)
# Command commits if clean
if exit_code == 0:
run_command('/bin/bash -c "cd /mnt/workspace && git add -A && git commit -m Fix-JIRA-1234"')
run_command('/bin/bash -c "cd /mnt/workspace && git push origin fix/JIRA-1234"')
What This Means for Agent Infrastructure
Before these capabilities, every team building production coding agents on AgentCore was solving the same two problems with custom code: S3 checkpoint logic to survive session restarts, and external orchestration to run deterministic commands without touching the LLM. Both are now platform features.
The persistent filesystem also changes how context works. Agents that previously had to re-establish their environment on every invocation now treat the filesystem as extended memory. The context window handles reasoning; /mnt/workspace handles state.
Managed session storage is currently in public preview. Execute command is generally available. Both are live in us-west-2.