Agents Get Started

get-started

Walk a developer from zero to a running agent on AWS.

When to use

• Developer wants to build an agent on AWS and doesn't know where to start
• Developer wants to create a new AgentCore project
• Developer is choosing between frameworks (Strands, LangGraph, GoogleADK, OpenAI Agents)
• Developer just ran agentcore create and wants to know what to do next

Do NOT use for:

• Environment/prerequisite issues (CLI not found, credentials broken) → use agents-debug
• Adding capabilities to an existing project (memory, tools, policies) → use agents-build or agents-connect
• Migrating an existing Bedrock Agent → use agents-build (loads references/migrate.md)

Input

$ARGUMENTS can be:

• A framework preference: "using LangGraph", "with Strands"
• A protocol: "MCP server", "A2A"
• A description of what the agent should do: "a customer support agent"
• Empty — the skill will guide framework selection

Process

Step 0: Verify CLI version

agentcore --version

This skill requires v0.9.0 or later.

If the version is older:

Your AgentCore CLI is out of date (found vX.Y.Z, need v0.9.0+).

Offer to run the update: agentcore update. After the update completes, re-check the version to confirm it's ≥0.9.0 before continuing. Preserve any context the developer already provided (framework preference, project name, what they want to build) so they don't have to repeat themselves.

If agentcore is not found:

The AgentCore CLI isn't installed. Run npm install -g @aws/agentcore (requires Node.js 20+). If you're having trouble with installation, I can run the agents-debug skill (which loads references/doctor.md) to diagnose your environment.

Step 1: Determine intent — exploring or ready to create?

Before jumping into framework selection, figure out where the developer is:

Ask the developer: "Are you exploring options (comparing frameworks, understanding what AgentCore does) or ready to create a project?"

• Exploring → Go to Step 2 (framework comparison). Present the options, answer questions, and wait. Do not construct a create command until they signal they're ready.
• Ready to create → Skip to Step 3 (create the project). If they already specified a framework, skip Step 2 entirely.
• Already has a project → Look for agentcore/agentcore.json in the current directory. If found, read it and skip to Step 5 (what to do next). Don't re-scaffold.

If the developer's intent is clear from $ARGUMENTS (e.g., "create a Strands agent called MyBot"), skip straight to Step 3.

Step 2: Framework selection

Check conversation context first. If the developer already discussed frameworks earlier in this conversation (e.g., from a previous skill invocation), don't re-present the full table. Summarize what was discussed and ask if they've decided, or if anything changed.

If this is the first time discussing frameworks, present the options:

Supported frameworks (CLI-scaffolded, Python):

Ask the developer to choose. Present the options and wait for their selection. Don't assume a default unless they explicitly say they have no preference.

Note on naming: The CLI flag value is the exact string to pass to --framework. In prose use the shorter names.

Default recommendation (only when the developer says "no preference" or "you pick"): Strands — AWS-native framework with the tightest AgentCore integration and the most samples/docs.

Key decision points to surface:

• "Do you have existing agent code in LangGraph or OpenAI Agents?" → use that framework
• "Do you need complex graph-based workflows with conditional branching?" → LangGraph
• "Starting fresh with no preference?" → Strands

Framework not listed?

If the developer asks about a framework not in the table above, handle it:

BYO Container path (any framework, any language):

For frameworks or languages not scaffolded by the CLI, AgentCore Runtime accepts any container that implements the HTTP contract (POST /invocations, GET /ping). The workflow:

1. agentcore create --name <ProjectName> --defaults to scaffold the project structure
2. agentcore add agent --type byo --build Container --language <Language> --code-location <path> to register your code
3. Write a Dockerfile that builds and runs your agent
4. agentcore deploy handles ECR push, CDK infra, and runtime creation

Language-specific notes:

The rest of this skill (deploy, status, logs, invoke) applies once the container builds correctly.

Framework vs. model provider — a common confusion

The framework is how your agent orchestrates (Strands, LangGraph, etc.). The model provider is which LLM it calls (Bedrock, Anthropic, OpenAI, Gemini). These are independent choices:

• Strands + Bedrock (default) — AWS-native everything
• Strands + Anthropic — Strands orchestration, direct Anthropic API for the model
• LangGraph + Bedrock — LangGraph orchestration, Bedrock for the model
• OpenAI Agents + OpenAI — OpenAI everything

If the developer says "I want to use Claude" they mean the model provider (Bedrock or Anthropic), not the framework. If they say "I want to use LangGraph" they mean the framework.

Step 3: Create the project

Build the agentcore create command based on the developer's choices.

Before constructing the command — validate the project name. The CLI fails late: if the name is invalid, you'll see the error after walking through prompts or building the full command. Save the round-trip and check these rules up front. Reject the name and ask for a new one if any rule fails:

• Length ≤ 23 characters (this is shorter than most developers assume — MyCustomerSupportAgent is 22 chars and fits; CustomerSupportChatbot is 22 and fits; MyCustomerSupportBotApp is 23 and just fits; MyCustomerSupportChatBot is 24 and fails)
• Alphanumeric only — no hyphens, underscores, dots, or spaces
• Must start with a letter

Say the count back out loud when close to the limit: "That name is 24 characters — the CLI caps project names at 23. Want to shorten it to <suggestion>?" Do not run the command with an invalid name on the assumption that the CLI error message will be clear — it isn't always, and the developer's mental model will be wrong for subsequent commands.

Construct the command, then present it for confirmation before the developer runs it. Show the full command with all flags and explain what each choice means. Wait for the developer to confirm or adjust before proceeding.

Example presentation:

Here's the command I'd recommend based on what you've told me:

agentcore create --name MyAgent --framework Strands --model-provider Bedrock --build CodeZip --memory none

This creates a Strands agent using Bedrock models, deployed as a code zip (no Docker needed). Memory can be added later.

Want to run this, or change anything?

Do NOT execute the command automatically — present it and wait.

Minimal (defaults — Strands, Bedrock, CodeZip, no memory):

agentcore create --name <ProjectName> --defaults

With specific options:

agentcore create \
  --name <ProjectName> \
  --framework <Framework> \
  --model-provider Bedrock \
  --build CodeZip \
  --memory none

Flag reference:

Guidance on choices:

• Protocol: Use HTTP unless the developer specifically needs MCP tool serving or A2A agent-to-agent communication
• Build: Use CodeZip unless the developer needs custom system dependencies (CodeZip is faster to deploy and doesn't require Docker locally)
• Model provider: Use Bedrock unless the developer has a specific reason for another provider (Bedrock doesn't require managing API keys)
• Memory: Start with none — memory can be added later via agents-build (loads references/memory.md) when the developer needs it