/agents-build

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",
  "payments middleware for my agent",
  "integrate x402 payments with the agent I'm building",
  "enable my agent project with x402 payments".
  External APIs via Gateway: use agents-connect. New project:
  use agents-get-started. CLI/dev-server errors: use agents-debug.
  Runtime x402 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-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 content, 402 Payment Required, 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`](referenc