build
Add capabilities to your AgentCore agent project.
When to use
- Adding cross-session memory to your agent
- Calling your deployed agent from a web app, mobile app, or backend service
- Configuring VPC networking for private resources (RDS, internal APIs)
- Building multi-agent systems with orchestrator/specialist patterns
- Migrating an existing Bedrock Agent to AgentCore
- Adding the Browser tool so the agent can navigate websites
- Adding the Code Interpreter so the agent can execute code in a sandbox
- Removing resources from your project or tearing down a deployment
Do NOT use for:
- Connecting to external tools/APIs via Gateway (OpenAPI specs, Lambda, MCP servers, credentials, policies) → use
- Scaffolding a new project → use
- Deploying → use
Input
- A capability: "memory", "integrate", "vpc", "multi-agent", "migrate", "browser", "code-interpreter", "teardown"
- A description of what they want: "remember user preferences", "call from React app", "scrape a website", "run pandas in the agent", "delete my agent", "clean up resources"
- Empty — the skill will determine the workflow from context
Process
Step 0: Verify CLI version
Run
. This skill requires v0.9.0 or later.
If older: "Run
to get the latest version."
Step 1: Read project context
Read
to understand the current project — framework, existing resources, agent configuration.
- Check if the developer is in the wrong directory. Look for in parent directories (up to 3 levels). If found, tell them: "Found an AgentCore project at . Are you working in that project?"
- If no project exists anywhere nearby, ask what capability they wanted to add. Then offer two paths:
- "I can walk you through creating a project first and then adding CAPABILITY — want to do that?" (run the get-started flow inline, then continue with the build workflow)
- "If you already have a project elsewhere, into it and try again."
Do not just say "go use agents-get-started" and stop — that loses the developer's context about what they actually wanted to do.
Step 2: Determine the workflow
Important disambiguation — before routing to a build reference, check if the prompt is actually a connect or debug concern:
- If the phrase mentions external APIs, Lambda functions, OpenAPI specs, gateways, credentials, MCP servers, or policies → this is , not build
- If the developer says something is broken (wrong answers, errors, tool failures) → this is , not build
- Build is for adding new capabilities to a working project, not fixing broken ones
Based on the developer's prompt and
, load the appropriate reference:
| Developer intent | Reference to load |
|---|
| Add memory, remember things, user preferences, cross-session | |
| Call agent from app, invoke from code, streaming, SDK client, agent URL, execute shell in session | |
| VPC, private network, RDS, internal API, subnet, security group | |
| Multi-agent, orchestrator, specialist, A2A, delegation, agent handoff | references/multi-agent.md
|
| Custom headers from caller to agent, header allowlist, tenant ID/correlation ID/trace propagation | references/request-headers.md
|
| Migrate Bedrock Agent, import agent, move to AgentCore | |
| Browser tool, web navigation, form filling, scraping, Nova Act, Playwright, live view | |
| Code Interpreter, execute code, sandbox, run Python/JS/TS, data analysis in agent, pandas | references/code-interpreter.md
|
| Delete agent, remove resource, tear down, clean up, destroy, start fresh | |
| Change model, switch model, use Haiku/Sonnet/Nova, different model | Inline — see "Changing the model" below |
If the developer asks about the difference between local dev and deployed (e.g., "why does my memory work after deploy but not locally?"), load
references/local-vs-deployed.md
alongside the specific workflow reference.
Read the matching file into context and follow its Process section step by step — do not summarize.
If the intent is ambiguous, ask the developer which capability they want to add.
Changing the model
The model is configured in
app/<AgentName>/model/load.py
(scaffolded by
). To change it:
- Open
app/<AgentName>/model/load.py
- Change the parameter in the constructor
python
# Default (scaffolded by CLI)
return BedrockModel(model_id="global.anthropic.claude-sonnet-4-5-20250929-v1:0")
# Switch to Haiku for cost savings
return BedrockModel(model_id="us.anthropic.claude-3-5-haiku-20241022-v1:0")
# Switch to Nova Lite
return BedrockModel(model_id="amazon.nova-lite-v1:0")
Cross-region inference profile prefixes (
,
,
,
) control where inference runs. Use
for maximum throughput, or a geographic prefix for data residency. Not all models support all prefixes — check the Bedrock inference profiles docs.
After changing the model:
- Verify the model is enabled in your region: AWS Console → Amazon Bedrock → Model access
- For cross-region profiles, enable in all destination regions
- If using , update the IAM policy to scope to the new model ARN
- Run to test locally, then to update the deployed agent
No
change is needed — the model is configured in code, not in the project config.
Pre-flight: validate any before generating the CLI command
Whichever reference you load, most end up producing an
agentcore add <resource> --name <something>
command. The CLI fails
late on invalid names — you'll see the error after walking through prompts, not before running the command. Validate up front:
| Resource | Max chars | Allowed | Starts with |
|---|
| Agent () | 48 | alphanumeric + | letter |
| Memory, gateway, gateway-target, credential, evaluator, online-eval, policy, policy-engine | 48 | alphanumeric + | letter |
Count the characters before constructing the command. If the name is over the limit or contains hyphens, dots, or spaces, push back: "
is N characters / uses
, which the CLI rejects. How about
?" Never run the command with an invalid name hoping the CLI message will be clear.
Note:
(the project name) has a
stricter 23-char limit and does not allow underscores. That's covered in
; if you see the developer re-running create, flag the 23-char limit specifically.
Output
Depends on the workflow — see the loaded reference for specific outputs.
Quality criteria
- The correct reference was loaded based on the developer's intent
- All output follows the loaded reference's quality criteria
- Cross-references to other skills (agents-connect, agents-deploy) are included where relevant