Amazon Bedrock AgentCore New Features: CLI, Harness, Persistent Files, and Coding Agent Skills

On April 22, 2026, AWS added a set of Amazon Bedrock AgentCore features that changes the early developer workflow more than the runtime architecture. The update is not just “more agent tooling.” It gives developers a managed harness preview, an AgentCore CLI, coding assistant skills, session filesystem persistence, shell access, and a clearer path from prototype to infrastructure-as-code.

That matters if your team is trying to move from a notebook demo to a production agent without inventing a mini orchestration framework along the way.

The official announcement is here: Amazon Bedrock AgentCore adds new features to help developers build agents faster. This post focuses on what changed for engineers building production agents, not just what looks good in a launch note.

What changed on April 22, 2026

Here is the practical summary.

The headline is the managed harness. The deeper change is that AWS is trying to make AgentCore feel less like a pile of service APIs and more like a developer platform. You can still build your own orchestration layer, but the default path is becoming: describe the agent, run it, test it, export it, govern it, deploy it.

That is the right direction. Most teams do not fail at agents because they cannot call a model. They fail because the surrounding loop becomes messy: tool selection, memory, traces, local files, state recovery, evaluations, deployment, and permissions.

Why the managed harness matters

The managed harness preview lets you define an agent by specifying a model, a system prompt, and tools. Then it runs the agent loop for you. AWS says the harness handles reasoning, tool selection, action execution, and response streaming.

That is a big deal because the agent loop is where a lot of prototype code turns into technical debt.

In many first versions, the loop starts as a simple while block:

1. Send prompt to model.
2. Parse the tool call.
3. Execute the tool.
4. Feed the result back.
5. Stream the final answer.

That looks fine until you add retries, partial streaming, tool timeouts, file writes, session recovery, model switching, and evaluation hooks. At that point, your demo orchestration is now production infrastructure, but nobody designed it like infrastructure.

The harness gives teams a managed baseline. If the use case fits, you avoid writing that loop. If it does not fit, AWS says you can export the harness orchestration as Strands-based code when you need full control.

That export path is important. A managed harness with no escape hatch would be a demo feature. A managed harness that can turn into code is a migration path.

If you are new to AgentCore itself, read the broader AWS Bedrock AgentCore production guide first. The new harness features make more sense once you understand the runtime, gateway, memory, and tool model.

Filesystem and shell access changes the type of agents you can test

AWS says each managed harness session gets its own microVM with filesystem and shell access. That is more than a convenience feature.

Many practical agents need local working state. A coding agent may need to read a repo, patch files, run tests, and inspect output. A DevOps agent may need to generate a plan, write an artifact, execute a command, and revise the result. A data agent may need to stage intermediate files before producing a report.

Without a filesystem, you end up pushing everything into memory, object storage, or a custom state API too early. Without shell access, the agent cannot validate work the same way an engineer would.

The microVM model also matters because shell access is not something you casually bolt onto a shared process. You need isolation, scoped permissions, limits, and cleanup. A per-session execution environment gives AWS a place to put those controls.

For teams deploying MCP servers beside agents, this also changes the prototyping boundary. The MCP on ECS guide covers when a persistent server process makes more sense than Lambda or a fully managed agent tool. The new AgentCore harness gives you a faster way to test the agent side before deciding where every tool backend should live.

Filesystem persistence is the quiet production feature

Filesystem persistence is in preview, but it may be the most operationally interesting part of the announcement. AWS says it externalizes local session state so agents can suspend mid-task and resume where they left off.

That sounds small until you list the failure modes in real agent work:

• the model has to stop because a task runs longer than expected
• a tool call times out after partial file generation
• the user closes a session before the work is complete
• a deployment review pauses the workflow
• the agent needs to retry with a different model
• a human wants to inspect intermediate artifacts before continuing

If local files disappear at every boundary, every workflow becomes fragile. Durable state lets you design agent tasks like resumable jobs instead of one-shot chat messages.

The gotcha is that “persistent” does not mean “governed.” You still need retention, encryption expectations, data classification, and cleanup policies. If an agent writes customer data, generated code, credentials by accident, or large build outputs to its filesystem, that state now has a lifecycle.

Treat persistent session files like any other workload data. Define who can access it, how long it lives, what should never be written there, and how it appears in audit trails.

The CLI and IaC workflow

The AgentCore CLI matters because production teams do not want console-only agent management. They want repeatable builds, reviewable changes, and controlled promotion across environments.

AWS says the AgentCore CLI deploys with infrastructure-as-code governance and auditability. AWS CDK is supported today as a resource manager, with Terraform coming soon.

That points to a realistic workflow:

That last part matters for DevOps teams. A prototype can be flexible, but production cannot be mysterious. If your agent changes behavior, routes to new tools, or gains shell access, that needs the same review discipline as any other production workload.

For cost ownership, connect this with Amazon Bedrock granular cost attribution. Agent platforms get expensive when every team shares the same role, the same gateway, and the same billing line. The earlier you map agents to owning identities, the easier chargeback becomes.

Coding assistant skills are not just documentation

AWS says AgentCore skills are available through Kiro Power, with Claude Code, Codex, and Cursor support coming next week from the April 22 announcement.

This is easy to dismiss as assistant branding, but it solves a real developer problem: service-specific drift. AgentCore is evolving quickly. If your coding assistant is working from stale examples, it may generate code that uses old APIs, misses region limits, or wires the wrong resource pattern.

Prebuilt skills can help the assistant answer questions closer to the current AgentCore model. The useful version of this is not “write my whole agent.” It is:

• scaffold the correct AgentCore resource shape
• explain which resource belongs in CDK
• suggest where the harness is enough and where code export is safer
• help wire memory, gateway, and evaluations consistently
• catch obvious gaps before pull request review

You should still review every generated change. A skill can improve the assistant’s context, but it does not replace architecture ownership.

Practical checklist before you use this in production

Use this checklist before a prototype becomes a deployed agent:

• Confirm whether the managed harness preview is available in your target Region.
• Keep prototype accounts separate from production accounts.
• Define which tools are safe for shell access and which are not.
• Decide what data can be written to persistent filesystem state.
• Add cleanup rules for generated files, logs, and temporary artifacts.
• Use one IAM role per agent or owning application where possible.
• Add evaluations before treating the agent as stable.
• Export orchestration code when the managed harness hides behavior you need to inspect.
• Deploy through CDK today if you need reviewable infrastructure.
• Track Terraform support if your organization requires Terraform for all production resources.
• Send logs, traces, and operational events to CloudWatch from the start.
• Budget for model calls, tool calls, retries, and failed experiments.

The theme is simple: let the new features accelerate the first mile, but do not let them erase the controls you need at the last mile.

Gotchas to watch

Preview means design for change

The managed harness and filesystem persistence are in preview. Do not build an irreversible production architecture around preview behavior unless you are comfortable changing it later.

Shell access increases blast radius

Shell access is powerful because the agent can validate work. It is dangerous for the same reason. Restrict what the session can reach, especially package managers, network destinations, credentials, and internal repositories.

Persistent files can leak context

Agents often write more than humans expect. Temporary notes, intermediate code, downloaded files, debug logs, and tool outputs may contain sensitive data. Persistence turns that from a transient problem into a data governance problem.

Model switching can change behavior mid-session

AWS says the harness is model agnostic and can switch models mid-session. That is useful, but it complicates evaluation. A workflow tested on one model may not behave the same way on another model, especially for tool selection and shell command generation.

IaC does not make agent behavior deterministic

CDK can version the infrastructure. It cannot fully freeze model behavior, prompts, tool outputs, or external system state. You still need evaluations and regression tests for agent behavior.

My recommendation

Use the managed harness for fast discovery, especially when you are still deciding the right tools, prompt structure, memory design, and model. Use filesystem persistence for longer tasks, but treat the stored state as governed workload data. Use the CLI and CDK when the agent becomes something a team depends on.

Once the workflow becomes business-critical, stop treating it like a chat experiment. Give it an owner, an IAM boundary, a deployment pipeline, cost attribution, CloudWatch telemetry, and a rollback path.

The April 22 AgentCore update is useful because it shortens the distance between “I have an agent idea” and “I can test a realistic version of it.” The teams that benefit most will be the ones that keep that speed while still applying normal production engineering discipline.