AgentCore CLI & Skills for Coding Assistants

Using the CLI and packaged skills to scaffold agents faster.

Everything else in this section shows AgentCore through boto3 and AWS SDK v3 calls, because that is what your application code uses at runtime. Setting up a new agent project, though, is mostly one-time scaffolding and deployment work - not something worth hand-writing SDK calls for every time. AWS is expected to ship a dedicated CLI for exactly that, plus reusable templates ("skills") that let a coding assistant generate a working AgentCore project faster than starting from a blank file.

This page leans more heavily on hedged, illustrative commands than most others in this section, because CLI ergonomics and coding-assistant integrations are typically the last piece of a preview product to stabilize publicly. Confirm install method, subcommand names, and template mechanics against current AWS documentation before scripting around them.

Recipe

Quick-reference CLI commands - copy-paste ready, but subcommand names are illustrative; verify at build time. CLI interactions use plain shell commands, not a language-specific SDK.

# --- AgentCore CLI (illustrative - verify subcommands against current AWS docs) ---
pip install bedrock-agentcore-starter-toolkit   # representative package name only
 
agentcore configure --entrypoint my_agent.py --name my-agent
agentcore launch
agentcore status --name my-agent

• configure is expected to set up local project metadata (which file is the entrypoint, execution role, region) once per project.
• launch is expected to package and deploy that configuration as a live AgentCore Runtime resource, the CLI equivalent of the control-plane calls shown on the basics page.
• status is a reasonable convenience command for checking deployment state without writing a list/describe control-plane call yourself.
• Treat every subcommand name here as representative - the actual CLI's exact verbs and flags should be confirmed before you build scripts or CI steps around them.

Working Example

Scaffolding a new agent project from a starter template, then invoking the deployed result with the SDK - the CLI handles setup, the SDK still handles runtime traffic.

# --- AgentCore CLI (illustrative - verify subcommands against current AWS docs) ---
agentcore init --template basic-agent --name support-bot   # representative subcommand only
cd support-bot
agentcore configure --entrypoint agent.py
agentcore launch

# --- Python (boto3) --- invoking the runtime the CLI just deployed
import boto3, json
 
client = boto3.client("bedrock-agentcore", region_name="us-east-1")
resp = client.invoke_agent_runtime(
    agentRuntimeArn="arn:aws:bedrock-agentcore:us-east-1:111122223333:runtime/support-bot",
    payload=json.dumps({"prompt": "What's your return policy?"}).encode(),
)
print(json.loads(resp["response"].read()))

// --- TypeScript (AWS SDK v3) --- invoking the runtime the CLI just deployed
import { BedrockAgentCoreClient, InvokeAgentRuntimeCommand } from "@aws-sdk/client-bedrock-agentcore";
 
const client = new BedrockAgentCoreClient({ region: "us-east-1" });
const resp = await client.send(new InvokeAgentRuntimeCommand({
  agentRuntimeArn: "arn:aws:bedrock-agentcore:us-east-1:111122223333:runtime/support-bot",
  payload: new TextEncoder().encode(JSON.stringify({ prompt: "What's your return policy?" })),
}));
console.log(new TextDecoder().decode(resp.response as Uint8Array));

What this demonstrates:

• A CLI-driven init step is plausible for getting a runnable project skeleton (entrypoint file, dependency manifest, basic config) without copy-pasting boilerplate by hand.
• Everything after deployment - actual traffic - still goes through the same SDK invoke call covered on the basics page, whether or not you used the CLI to get there.
• The CLI and the SDK are complementary, not competing: CLI for one-time/occasional setup, SDK for request-time application code.
• --template (or an equivalent flag) is where "skills for coding assistants" and plain CLI usage likely overlap - a template a human runs via CLI and a template a coding assistant generates from could reasonably be the same underlying asset.

Deep Dive

Why a Dedicated CLI, Given Control-Plane APIs Already Exist

Nothing about the control-plane calls shown elsewhere in this section requires a CLI - you could call create_gateway or the runtime-creation operation directly from a script. A CLI exists for the same reason the AWS CLI exists generally: routine, occasional operations (deploy this, check status, tear this down) are more ergonomic as one shell command than as a small script importing an SDK. Expect the AgentCore CLI to be a thin, scriptable wrapper over the same control-plane operations documented elsewhere in this section, not a fundamentally different capability.

Packaged "Skills" as Coding-Assistant Templates

The idea behind packaged skills or starter templates for coding assistants is straightforward: a coding assistant (an IDE-integrated AI helper, or something like Amazon Q Developer) can produce a working AgentCore project - entrypoint, dependencies, basic tool wiring - much faster if it has a known-good template to start from and adapt, rather than generating the whole shape from a general prompt. This is analogous to how framework-specific project generators (a create-react-app-style tool, for instance) shortcut scaffolding versus writing every file by hand.

Treat the specific mechanics of this - whether it's a CLI-invocable template flag, a separate published skill/plugin artifact, or something else - as the least confirmed detail on this page. The concept (templates that shortcut AgentCore project setup, usable by a human via CLI or by a coding assistant) is very plausible given AWS's broader direction; the exact delivery mechanism is not something to hardcode assumptions about yet.

What Stays the Same Regardless of Tooling

However you get to a deployed runtime - hand-written control-plane calls, the CLI, or a coding-assistant-generated scaffold - the resulting resource is invoked the same way, through the data-plane client shown throughout this section. This matters practically: debugging, observability, and guardrail application (covered on their own pages) do not care how the agent was created, only how it behaves once deployed.

Gotchas

• Assuming CLI subcommand names shown anywhere (including here) are final. Preview-era CLI surfaces change. Fix: run --help on the actual installed CLI and cross-check against current AWS docs rather than trusting any cached example, including this page's.
• Treating a scaffolded template as production-ready without review. A starter template optimizes for "gets you started," not for your specific security or scaling needs. Fix: review generated IAM roles, guardrail wiring, and tool registrations before deploying past a dev environment.
• Skipping local testing because the CLI makes deployment easy. Fast deploys can tempt you to skip the local-server testing loop shown on the basics page. Fix: keep testing locally first; a fast deploy is not a substitute for catching an error before it reaches AWS.
• Assuming CLI-based deploys and SDK-based control-plane calls are interchangeable in every detail. They likely hit the same underlying operations, but confirm parity (e.g., does the CLI set every field an SDK call could). Fix: for anything security-sensitive, verify the resulting resource configuration directly (via a describe/get call) rather than trusting the CLI's success message alone.
• Not pinning the CLI/toolkit version in CI. A fast-moving preview tool can change behavior between versions. Fix: pin the exact installed version in any automated pipeline and upgrade deliberately.

Alternatives

FAQs

Related

• AgentCore Basics - the manual configure/launch/invoke flow this CLI wraps.
• AgentCore's Managed Agent Runtime - what actually gets created when you deploy.
• AgentCore via SDK Best Practices - the checklist for reviewing anything scaffolded before production use.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+). Amazon Bedrock AgentCore is a fast-moving 2026 preview capability - verify exact API/CLI surface against current AWS docs before relying on specific method names.