agents-build — Claude Code skill: extend an agent project
Adds memory, VPC, multi-agent routing, Browser, Code Interpreter and payments to an agent project that already runs. Built for extending, not scaffolding.
npx skills add aws/agent-toolkit-for-aws --skill agents-build -a claude-codeWhat agents-build does
The skill reads agentcore/agentcore.json to see what your project already has, then picks the matching reference file from references/ and follows its steps. No project file in the current directory? It looks up to three levels of parent directories and asks whether you meant to work there. If nothing turns up, it offers to walk you through creating a project first instead of sending you away.
Covered capabilities: cross-session memory, calling the agent from an app, VPC access to private resources such as RDS, orchestrator and specialist patterns, migration from Bedrock Agent, the Browser tool, Code Interpreter, payments over x402 and MPP, and resource teardown. Model changes happen inline — edit the model_id argument in the BedrockModel() constructor inside app/<AgentName>/model/load.py. The inference profile prefix (us., eu., apac., global.) decides where inference runs.
Check your CLI version first: the skill wants agentcore 0.9.0 or later and will tell you to run agentcore update otherwise. It is not a repair tool. Broken answers, tool failures and dev-server errors belong to agents-debug, and wiring external APIs through Gateway belongs to agents-connect.
What it helps with
- give the agent memory that survives across sessions
- call a deployed agent from a React app
- open VPC access so the agent reaches RDS and internal APIs
- set up an orchestrator that delegates to specialists
- move an existing Bedrock Agent over to AgentCore
Example prompts for the agent
- add memory to my agent so it remembers user preferences
- set up VPC, the agent can't reach our internal API
- switch the model to Haiku to cut cost
How to install agents-build
1Skills CLI (Vercel)
npx skills add aws/agent-toolkit-for-aws --skill agents-build -a claude-code2Manually: put the files in place
~/.claude/skills/agents-build/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/agents-build/
1Skills CLI (Vercel)
npx skills add aws/agent-toolkit-for-aws --skill agents-build -a codex2Manually: put the files in place
.agents/skills/agents-build/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add aws/agent-toolkit-for-aws --skill agents-build -a cursor2Manually: put the files in place
.cursor/skills/agents-build/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install aws/agent-toolkit-for-aws agents-build2Manually: put the files in place
.github/skills/agents-build/SKILL.md1Skills CLI (Vercel)
npx skills add aws/agent-toolkit-for-aws --skill agents-build -a gemini-cli2Platform CLI
gemini skills install https://github.com/aws/agent-toolkit-for-aws --path plugins/aws-agents/skills/agents-buildManually: put the files in place
.devin/skills/agents-build/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add aws/agent-toolkit-for-aws --skill agents-build -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about agents-build
How do I install agents-build in Claude?
Run npx skills add aws/agent-toolkit-for-aws --skill agents-build -a claude-code. The skill lands at ~/.claude/skills/agents-build/SKILL.md.
What does agents-build do?
It extends an existing agent project with memory, app integration, VPC, multi-agent patterns, migration, Browser, Code Interpreter, payments or teardown. It loads the matching reference from references/ and works through its steps.
How is agents-build different from agents-connect and agents-debug?
agents-build adds new capabilities to a working project. External APIs and MCP servers through Gateway go to agents-connect, while CLI and dev-server errors go to agents-debug.
Source text
SKILL.md · Apache-2.0
--- name: agents-build description: > Use to extend an existing agent project with memory, app integration, VPC, multi-agent, migration, model, browser, code interpreter, payments, or resource removal. Triggers: "add memory", "remember across sessions", "call agent from app", "invoke agent from code", "agent auth", "streaming", "VPC", "VPC connectivity", "can't reach from VPC", "multi-agent", "A2A", "A2A auth", "orchestrator not delegating", "specialist not called", "migrate Bedrock Agent", "migration issue", "change model", "browser tool", "code interpreter", "delete agent", "tear down", "agentcore remove", "cross-account memory", "add payments capability to my agent", "wire payments plugin", "integrate x402 payments with the agent I'm building", "add MPP payments", "Machine Payments Protocol". External APIs via Gateway: use agents-connect. New project: use agents-get-started. CLI/dev-server errors: use agents-debug. Runtime x402/MPP payments: use agents-pay. Migration-specific Strands vs LangGraph routes here. allowed-tools: Read Grep Glob Bash metadata: type: skill version: "1.0.0" author: aws-agentcore requires-cli: ">=0.9.0" --- # 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 - Adding AgentCore Payments so the agent can pay for x402- or MPP-protected APIs, tools, or content - 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 `agents-connect` - Scaffolding a new project → use `agents-get-started` - Deploying → use `agents-deploy` ## Input `$ARGUMENTS` can be: - A capability: "memory", "integrate", "vpc", "multi-agent", "migrate", "browser", "code-interpreter", "payments", "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 `agentcore --version`. This skill requires v0.9.0 or later. If older: "Run `agentcore update` to get the latest version." ### Step 1: Read project context Read `agentcore/agentcore.json` to understand the current project — framework, existing resources, agent configuration. If `agentcore/agentcore.json` is not found: 1. **Check if the developer is in the wrong directory.** Look for `agentcore/agentcore.json` in parent directories (up to 3 levels). If found, tell them: "Found an AgentCore project at `<path>`. Are you working in that project?" 2. **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, `cd` 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 `agents-connect`, not build - If the developer says something is broken (wrong answers, errors, tool failures) → this is `agents-debug`, not build - Build is for **adding new capabilities** to a working project, not fixing broken ones Based on the developer's prompt and `$ARGUMENTS`, load the appropriate reference: | Developer intent | Reference to load | |---|---| | Add memory, remember things, user preferences, cross-session | [`references/memory.md`](references/memory.md) | | Call agent from app, invoke from code, streaming, SDK client, agent URL, execute shell in session | [`references/integrate.md`](references/integrate.md) | | VPC, private network, RDS, internal API, subnet, security group | [`references/vpc.md`](references/vpc.md) | | Multi-agent, orchestrator, specialist, A2A, delegation, agent handoff | [`references/multi-agent.md`](references/multi-agent.md) | | Custom headers from caller to agent, header allowlist, tenant ID/correlation ID/trace propagation | [`references/request-headers.md`](references/request-headers.md) | | Migrate Bedrock Agent, import agent, move to AgentCore | [`references/migrate.md`](references/migrate.md) | | Browser tool, web navigation, form filling, scraping, Nova Act, Playwright, live view | [`references/browser.md`](references/browser.md) | | Code Interpreter, execute code, sandbox, run Python/JS/TS, data analysis in agent, pandas | [`references/code-interpreter.md`](references/code-interpreter.md) | | Payments, pay for x402 or MPP content, 402 Payment Required, Machine Payments Protocol, WWW-Authenticate: Payment, microtransactions, paid API/tool, payment manager/connector | [`references/payments.md`](references/payments.md) | | Delete agent, remove resource, tear down, clean up, destroy, start fresh | [`references/teardown.md`](references/teardown.md) | | 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`](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 `agentcore create`). To change it: 1. Open `app/<AgentName>/model/load.py` 2. Change the `model_id` parameter in the `BedrockModel()` 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 (`us.`, `eu.`, `apac.`, `global.`) control where inference runs. Use `global.` 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 `agents-harden`, update the IAM policy to scope to the new model ARN - Run `agentcore dev` to test locally, then `agentcore deploy` to update the deployed agent No `agentcore.json` change is needed — the model is configured in code, not in the project config. ### Pre-flight: validate any `--name` 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 (`add agent`) | 48 | alphanumeric + `_` | letter | | Memory, gateway, gateway-target, credential, evaluator, online-eval, policy, policy-engine, payment-manager, payment-connector | 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: "`<name>` is N characters / uses `-`, which the CLI rejects. How about `<suggestion>`?" Never run the command with an invalid name hoping the CLI message will be clear. Note: `agentcore create --name` (the project name) has a **stricter 23-char limit** and does not allow underscores. That's covered in `agents-get-started`; 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
© aws-agentcore · Apache-2.0 · aws/agent-toolkit-for-aws