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

This note is for the person who will build it. The store decision it protects: ship one lookup this week (usually where-is-my-order or a support answer from the order record), keep a person on money (refunds, cancels, stock changes, discounts), and skip the agent when a rule already closes the case. We have no published agent case study that invents ticket or conversion results. Everything below is a sample supervisor-plus-specialists architecture with cloneable stubs — for your technical lead, not for Monday Slack. Pass it to them after you agree the week-one boundary.

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 shopper payment capture in this sample. AgentCore Payments reached GA on August 18, 2026 for gated agent-to-API spend with a session budget — it is still not a replacement for checkout. 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-5-5 (Claude Sonnet 5.5, Global cross-Region profile). 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 — batch, online, and A/B testing are generally available as of June 2026; confirm your Region before launch.

Shopify on this architecture

There is still no native Shopify AgentCore connector as of 25 September 2026. The storefront sits behind an app you own. The shopper path on current UCP Catalog, Cart, and Checkout MCP is Amazon Bedrock Shopify integration. This page stays the multi-agent store sample.

• Admin GraphQL, current stable version pinned in the app, with X-Shopify-Access-Token on that app’s token — not a staff password.
• Week-one scopes are reads (read_orders, read_products, read_inventory or the narrower set the field actually requires). write_orders stays off.
• Webhooks (ORDERS_CREATE and the topics you name) notify your adapter. The agent does not poll Admin in a loop. Each topic needs the matching scope. HTTPS, EventBridge, or Pub/Sub are the documented destinations.
• Gateway exposes getOrder and getShipment, not “run this GraphQL string.”
• The longer platform note is Shopify AI agents. Adobe Commerce and BigCommerce use the same Gateway shape with different tokens: Magento, BigCommerce. The shopper path on BigCommerce Storefront MCP is Amazon Bedrock BigCommerce integration. Order and stock reads on Odoo are Amazon Bedrock Odoo integration.

Where this sits in the control loop

The sample is a supervisor and four specialists. It is not a production store, and it is not a client engagement. Writes in the local stubs do not commit unless an approval token is passed in tool context, and even then the stub does not call a live order system. A shopper message is untrusted data. It is not appended to the system prompt and it is not parsed for approval.

Gateway and Cedar remain the deploy-time policy. The Python harness.py next to the sample is the local stand-in so a prompt cannot act as a permission. The wider loop is the AWS store-agent architecture.

What this post doesn’t cover

• AgentCore Payments as shopper checkout or card capture. Payments GA (August 18, 2026) is for agent-to-API / MCP / content microtransactions with a PaymentSession budget — not PAN in Memory, not unbounded purchase. Architecture: production guide.
• AgentCore Browser for third-party seller portals
• Full request collections for every ERP. The boundary is in the integration post. Platform specifics are the Shopify, Magento, and BigCommerce posts linked above.
• 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.

Related reading

This post is the store-agent reference build. The workflow-by-workflow treatment lives in the eCommerce AI Agents series — 64 parts covering support and WISMO, inventory reorder, autonomy per action, and when one agent stops being enough.

Frequently asked questions