Build Coding Agents on AgentCore: Shell Commands and Persistent Session Storage

Amazon Bedrock AgentCore got two features in March 2026 that matter far more than the marketing language around them. On March 17, 2026, AWS launched shell command execution in AgentCore Runtime. On March 25, 2026, AWS added managed session storage in public preview for persistent filesystem state. Put those together and Bedrock stops looking like a demo runtime and starts looking like something you can use for real coding agents.

This is the missing bridge between LLM reasoning and deterministic engineering work. An agent can think about a bug, but a production workflow still needs exact commands like npm test, pytest, git status, or terraform plan. AWS now exposes that split directly instead of forcing you to build the plumbing yourself.

If you want the broad platform view first, start with AWS Bedrock AgentCore in 2026. If you care about tool orchestration boundaries, AgentCore Gateway server-side tool execution is the right companion topic. This post is narrower: shell plus filesystem persistence.

What AWS Actually Launched

The March 17, 2026 launch added InvokeAgentRuntimeCommand, which runs shell commands inside an active AgentCore Runtime session. According to the AWS documentation, commands execute in the same container, filesystem, and environment as the agent invocation, stream output back over HTTP/2, and return an exit code when the command finishes.

That matters because you no longer need custom sidecar logic just to distinguish “think about the problem” from “run the test suite.” AWS also documents an important constraint that many teams will miss on first read: command execution is one-shot and non-interactive. Every command starts a fresh bash process. Shell history does not persist, and environment variable changes from one command do not carry into the next.

Session storage solves the other half of the problem. By default, AgentCore sessions are ephemeral. If the session stops, the next invocation gets a clean filesystem. The March 25, 2026 preview changes that by letting you attach a persistent mount path so files survive stop and resume cycles. AWS says the storage is isolated per session, supports standard Linux file operations, allows up to 1 GB per session, and deletes data after 14 days of inactivity.

That is the feature set coding agents actually need:

• model-driven reasoning
• deterministic shell execution
• persistent workspace state
• isolated per-session storage

Without that combination, “AI coding agent” usually means “chatbot that forgot what it edited ten minutes ago.”

Why Shell Commands Matter More Than Tool Calls

Structured tools are still the safer default for business operations. If the task is “create an IAM role” or “open a Jira ticket,” a typed API call is cleaner than a shell command. That is why stateful MCP on AgentCore is still important for multi-step enterprise workflows.

But coding work is different. Build systems, test runners, package managers, linters, compilers, and Git are already shell-driven. Pretending they should all become JSON tools adds abstraction without reducing risk.

AWS’s own runtime docs draw the line clearly:

• use InvokeAgentRuntime for reasoning work
• use InvokeAgentRuntimeCommand for deterministic execution

That is the right design. Let the model decide what to inspect or fix. Let the command runner perform known operations exactly.

The Practical Workflow Pattern

For a coding agent, the most useful loop now looks like this:

1. Invoke the agent to inspect code and propose a change.
2. Let the agent write files into a persistent workspace such as /mnt/workspace.
3. Run validation commands deterministically with InvokeAgentRuntimeCommand.
4. Feed failing output back to the agent.
5. Stop and resume later without losing the repo state.

That last step matters more than it sounds. Long-running agent sessions are brittle if all state lives in prompt context. Filesystem persistence gives you a real working directory instead of a memory trick.

AWS documents the runtime setup like this:

aws bedrock-agentcore-control create-agent-runtime \
  --agent-runtime-name "coding-agent" \
  --role-arn "arn:aws:iam::111122223333:role/AgentExecutionRole" \
  --agent-runtime-artifact '{
    "containerConfiguration": {
      "containerUri": "123456789012.dkr.ecr.us-west-2.amazonaws.com/my-agent:latest"
    }
  }' \
  --filesystem-configurations '[{
    "sessionStorage": {
      "mountPath": "/mnt/workspace"
    }
  }]'

Then your application can reason with the agent and validate with commands in the same session:

import boto3
import json

client = boto3.client("bedrock-agentcore", region_name="us-west-2")

AGENT_ARN = "arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/my-agent"
SESSION_ID = "12345678-1234-1234-1234-123456789012"

client.invoke_agent_runtime(
    agentRuntimeArn=AGENT_ARN,
    runtimeSessionId=SESSION_ID,
    payload=json.dumps({
        "prompt": "Inspect /mnt/workspace, fix the failing unit test, and explain the change."
    }).encode(),
)

response = client.invoke_agent_runtime_command(
    agentRuntimeArn=AGENT_ARN,
    runtimeSessionId=SESSION_ID,
    qualifier="DEFAULT",
    contentType="application/json",
    accept="application/vnd.amazon.eventstream",
    body={
        "command": '/bin/bash -c "cd /mnt/workspace && pytest -q"',
        "timeout": 300,
    },
)

The important design choice is not the specific command. It is the separation of concerns. The model writes and reasons. The runtime executes and reports exit codes.

What Engineers Should Watch Closely

Shell access makes AgentCore more useful, but it also expands the blast radius immediately. AWS is explicit that command security is your responsibility under the shared responsibility model. Inside the microVM, commands can access the container filesystem, environment variables, and any credentials you mounted or exposed.

Three operational details matter right away.

First, commands are stateless between invocations. If you need context, encode it inside the command itself:

/bin/bash -c "cd /mnt/workspace && export NODE_ENV=test && npm test"

Second, the runtime image does not magically include developer tools. AWS notes that git, npm, language runtimes, and similar binaries must already exist in your container image or be installed dynamically.

Third, the limits are real. As of April 10, 2026, AWS documents a command size range of 1 byte to 64 KB, a timeout range of 1 to 3600 seconds with 300 seconds as the default, and a per-agent rate limit of 25 TPS for InvokeAgentRuntimeCommand. Session lifecycle limits matter too: the default idle session timeout is 15 minutes, and maximum session duration is 8 hours.

Those constraints are fine for build-and-fix loops. They are not fine for pretending AgentCore is a general-purpose remote shell.

Session Storage Is Powerful, but Not a Real Shared Filesystem

Managed session storage is excellent for coding-agent workspaces, but teams should not misread it as EFS for agents. It is session-scoped storage, not a shared team drive.

AWS documents several behavior details that are easy to overlook:

• data is isolated per session
• hard links are unsupported
• extended attributes are unsupported
• advisory file locks do not persist across stop/resume
• stored permissions are not enforced inside the session because the agent is the only user in the microVM

There is another production detail worth calling out: if you run the runtime in VPC mode, session storage still needs outbound access to S3 because AWS stores the session data in AgentCore S3. If your S3 gateway endpoint policy is too strict, persistence will fail in confusing ways.

This is also where the storage story connects nicely with Amazon S3 Files for AI agents. S3-backed state is becoming a more normal primitive for agent platforms. The difference here is that AgentCore hides the replication and remount logic for you.

A Good Security Baseline

If I were deploying this in production, I would start with five controls:

1. Restrict bedrock-agentcore:InvokeAgentRuntimeCommand to a narrow set of principals.
2. Ship a minimal container image with only the binaries your workflow actually needs.
3. Keep the working directory under a dedicated mount path such as /mnt/workspace.
4. Log and alert on command activity with CloudWatch and audit API calls with CloudTrail.
5. Require explicit approval before any command that mutates infrastructure, pushes Git history, or touches production credentials.

That is not optional hardening. It is the baseline for not turning a coding agent into an unbounded shell bot.

Final Take

The March 17, 2026 shell-command launch and the March 25, 2026 session-storage preview are the Bedrock AgentCore updates that make coding agents believable. Shell commands give you deterministic execution. Persistent session storage gives you continuity. Together, they let an agent work like an engineer works: inspect, edit, test, pause, resume.

That still does not remove the need for strong IAM, logging, and operational boundaries. It just means Bedrock now exposes the right primitives. The teams that benefit most will be the ones disciplined enough to treat shell access as a controlled runtime feature, not as a shortcut around engineering controls.