Build eCommerce Store AI Agents on Amazon Bedrock AgentCore (2026)

AWS lifecycle notice (June 30, 2026) — Amazon Bedrock Agents Classic is in maintenance for new customers after July 30, 2026. Net-new agent builds should use Bedrock AgentCore. Full matrix: lifecycle roundup.

On June 17, 2026, AgentCore Harness reached general availability on the same platform as Runtime, Memory, Gateway, Identity, and Policy (What’s New). For an eCommerce storefront, that stack is the paved road: a supervisor that routes to sales, order ops, support triage, and inventory specialists — with Gateway as the write-path choke point.

This post is an end-to-end sample architecture with cloneable stubs. It is not an anonymized client engagement. Commerce order volumes, refund rates, and fixture IDs (ORD-1001, SKU-TEE-BLU-M) are demo data.

First-party signals we reuse (not eCommerce outcomes) — Gateway server-side tools cut median tool round-trip ~180 ms → ~95 ms on a B2B CRM assistant (12 tools, ~8k turns/day) — Gateway post. Platform TCO silhouette: support-style AgentCore at 50K sessions/mo ~$791/mo platform + model (decision guide). Model your own mix on the AgentCore pricing calculator.

Reproduce this — Clone the artifacts under examples/architecture-blog-2026/ecommerce-agentcore-store-agents/. python3 -m py_compile supervisor_agent.py specialists/*.py syntax-checks the stubs. Deploy steps and Policy gates are in monday-checklist.md.

Why multi-agent for commerce (and when not to)

A single agent with catalog search, cancel, refund, and warehouse adjust tools will mis-route under load. The multi-agent supervisor pattern still applies — but on AgentCore Runtime, not Classic InvokeAgent + action groups.

Opinionated take: use Runtime + Strands for supervisor and specialists when routing, hop caps, and role-aware tools are product logic. Collapse to one Harness agent only if you have ≤5 tools, one team, and no associate-only writes. Trade-off: multi-agent adds invoke latency and ops surface; you buy clearer prompts, IAM, and Policy scopes.

Reference architecture

Shopper/Associate → IdP JWT → AgentCore Identity
        → Supervisor Runtime (Strands)
              ├─ Sales Runtime      (catalog / cart)
              ├─ Orders Runtime     (status / cancel)
              ├─ Support Runtime    (returns / escalate)
              └─ Inventory Runtime  (stock / merch)
        → AgentCore Memory (user-scoped)
        → AgentCore Gateway (8 OpenAPI tools)
              → Policy (Cedar) → OMS / catalog / WMS APIs
        → Observability (OTEL → CloudWatch)

Open the draw.io diagram.

Specialist contracts

Sales / shopping assistant

Read-heavy: product search, SKU detail, cart. No payment capture in this sample (Payments / x402 and Browser checkout are out of scope — see What this post doesn’t cover).

Local fixtures live in specialists/sales_agent.py. Production should call Gateway searchProducts / getProduct / getCart instead of in-process dicts.

Order automation

Status, shipment tracking, cancel/modify inside the cancel window. Delivered orders should DENY cancel and route to support for returns.

Support triage

Returns, refunds under a cap ($75 in the demo Cedar), policy FAQs, human escalation for chargebacks / legal / over-cap amounts.

Inventory / merchandising

Stock reads for associates (and optionally via sales for availability). Writes require associate or admin claims — shopper JWTs must fail at Policy even if the model asks.

Supervisor routing

Intent → agent matrix: routing-decision-matrix.md.

Rules we bake into the supervisor:

1. Classify once; invoke one specialist per turn (unless the specialist returns an explicit follow-up).
2. Cap hops at 2; then clarify or escalate_to_human.
3. Never call cancel/refund/inventory write tools from the supervisor — specialists + Gateway own writes.

Context: Python 3.12+, strands-agents ≥ 1.x, bedrock-agentcore Runtime entrypoint, model pin global.anthropic.claude-sonnet-4-5-20250929-v1:0 (swap per region). Full file: supervisor_agent.py.

# Excerpt — dry-run route tools; replace invoke_specialist with InvokeAgentRuntime.
@tool
def route_to_orders(user_message: str) -> str:
    """Route order status, cancel, modify, and shipment tracking to the orders agent."""
    return invoke_specialist("orders", user_message, {"hop": 1})

@tool
def escalate_to_human(reason: str, user_message: str) -> str:
    """Hand off when risk is high or specialists are ambiguous."""
    return json.dumps({"status": "escalated", "reason": reason, "queue": "commerce-tier2"})

Gateway tool catalog (8 tools)

Attach gateway/commerce-openapi.yaml as an OpenAPI target:

When the catalog grows past ~10 tools, use Gateway semantic search so the model sees a shortlist — same failure mode called out in the Gateway server-side tools post.

Cedar Policy on the write path

Sample policies: policy/refund-and-cancel.cedar.

NL equivalents:

• Shoppers/associates may cancelOrder only while status is processing or pending.
• createReturn auto path only when refundUsd <= 75.
• updateInventory only when JWT role is associate or admin.

Run Policy in LOG_ONLY for a canary window, then ENFORCE. Prompt text is not a substitute.

// Excerpt — auto-refund ceiling (demo). Align entity shapes to your Gateway schema.
permit (
  principal,
  action == Action::"createReturn",
  resource
)
when {
  principal has role &&
  ["shopper", "associate", "admin"].contains(principal.role) &&
  resource has refundUsd &&
  resource.refundUsd <= 75
};

What broke (counter-case)

What broke — Early supervisor drafts that “helpfully” called all four specialists on ambiguous prompts (help with my purchase). Result: duplicate tool calls, conflicting status text, and cancel attempted on a delivered fixture after support also opened a return. Detection: Gateway traces showed two write tools in one turn; Policy LOG_ONLY logged a would-be DENY on cancel. Fix: hop cap = 2, clarify-first on ambiguous intents, forbid cancel on delivered at Cedar, escalate chargeback language. Lesson: multi-agent without hop and Policy discipline is worse than a single agent.

Observability

Enable AgentCore Observability (OTEL into CloudWatch) on supervisor and Gateway. Track:

• Routing distribution (sales / orders / support / inventory / escalate)
• Specialist and Gateway p95 latency (platform signal from CRM canary: ~95 ms median tool RTT after server-side Gateway — your OMS will dominate absolute numbers)
• Policy ALLOW vs DENY counts (aws.agentcore.policy.authorization_decision spans)
• Escalation rate to commerce-tier2

Traces show what happened. Pair with AgentCore Evaluations before you scale session volume — region availability has been preview-limited; confirm before launch.

What this post doesn’t cover

• AgentCore Payments / x402 checkout and card data (keep payment capture out of agent tools)
• AgentCore Browser for third-party seller portals
• Full ERP / Shopify / Magento connectors (replace the OpenAPI host with yours)
• AgentCore Optimization A/B on prompts
• Classic Agents migration playbooks (see production guide)
• Measured eCommerce engagement KPIs — this sample does not invent them

What to do this week

1. Clone ecommerce-agentcore-store-agents and run python3 -m py_compile on the stubs.
2. Stand up Identity JWT with role claims (shopper | associate | admin).
3. Upload commerce-openapi.yaml to Gateway; attach Cedar from refund-and-cancel.cedar in LOG_ONLY.
4. Deploy supervisor + four specialist Runtimes; wire ARNs into supervisor env.
5. Prove DENY paths: cancel on ORD-1001 (delivered), refund $100, inventory write with shopper JWT.
6. Build a CloudWatch dashboard for routing + Policy DENY; alarm on DENY spikes.
7. Flip Policy to ENFORCE only after the canary week.
8. Model platform + token cost on the AgentCore pricing calculator.

Full gate list: monday-checklist.md.

If you only do one thing

Put Gateway Policy in front of cancelOrder, createReturn, and updateInventory before you polish the shopping prompt. A clever sales agent without write gates is an automated refund machine.