AWS AgentCore CLI 1.0 Is GA: What Changed, What Breaks

AWS made the AgentCore CLI 1.0 generally available on 28 October 2026 — the tool you use to create agents on Amazon Bedrock AgentCore, test them locally and deploy them.

The pitch targets a specific failure: agent experiments that never leave the laptop. As one hands-on write-up of the release puts it, that is rarely the model's fault — what is usually missing is the boring part in between, namely how the code gets into a runtime environment, who is allowed to call it, and where the logs end up.

What you actually get

The CLI scaffolds a project, runs the agent locally and deploys it via AWS CDK to the AgentCore Runtime. According to the write-up, a TypeScript agent with its own tools takes about five commands and two files. CDK runs underneath, but you do not operate it yourself.

Four terms carry most of the platform:

• Runtime — the managed environment for your agent code, where every session gets its own isolated microVM.
• Harness — an agent defined purely by configuration (model, prompt, tools), with AgentCore running the agent loop and you writing no code.
• Memory — storage for conversation histories and facts derived from them, so an agent remembers across sessions.
• Gateway — exposes APIs and Lambda functions to agents as MCP tools.

You are not locked into the config-only path: a harness can be converted to code later with agentcore export harness if it becomes limiting.

What changed in 1.0

The @aws/agentcore npm package has existed since February 2026 in preview and 0.x versions. The write-up reports that AWS rebuilt the CLI for 1.0, citing the announcement: it starts faster, its commands follow one uniform structure, and it covers more resource types.

The practical changes matter more than the rewrite. Commands are grouped into Project, Resources and Settings. You can address existing resources directly by ID or ARN without adding them to a project first. The global --region, --json and --debug options behave identically on every command, which is what makes the difference in CI scripts. Running agentcore with no arguments opens an interactive terminal UI.

The upgrade trap

If you have a 0.x project, it does not just work. You convert it with agentcore migrate — and the author flags that several places in the online CLI reference still described old options, such as agentcore import instead of migrate. Their advice for the first few weeks is to trust agentcore --help over the published docs. They verified the article's commands against version 1.0.1.

Two other sharp edges from the same hands-on run: agentcore create without options produces a harness by default, so pass --template explicitly if you want code; and deleting the project folder deletes nothing in AWS, so tear down through the CLI.

One prerequisite is worth checking before you start: the TypeScript template needs access to a Claude model in Amazon Bedrock through a global inference profile. The model is set in model/load.ts and can be pointed at a different Bedrock model.

Is it worth moving to?

On cost, the runtime is billed per second across CPU and memory, and the write-up notes that per the pricing page, no CPU time is charged while your agent is only waiting on the model or a tool. For agents that spend most of their wall-clock time waiting — which is most agents with tool calls — that billing shape is the strongest argument here. Model tokens, CloudWatch logs and Memory are charged on top, and model tokens are usually the largest line.

The honest read: if you are already deploying on Bedrock, 1.0 is the version where the CLI stops being a preview and the CI story becomes workable. If you are on 0.x, budget time for agentcore migrate and expect the docs to lag. And if you are evaluating platforms rather than already committed, the per-second-minus-waiting billing is the number to carry into the comparison, not the scaffolding.