Architecture Pattern
Agentic Commerce on AWS — AgentCore, Gateway, Cedar, and an MCP catalog surface
Both halves of agentic commerce on one AWS footprint — the agents you run, and the surface that lets other people agents buy from you.
Last updated: August 30, 2026Author: FactualMinds Engineering LeadershipReviewed by: FactualMinds AWS-certified architects (Solutions Architect – Professional)
Problem
An eCommerce team wants AI agents to handle support, inventory and margin work, and separately wants shopping agents inside ChatGPT and Gemini to be able to find and buy their products. Built naively, these become two unrelated projects with two sets of credentials, no shared authorization model, and an agent holding broad write access to the order system. The failure mode is not a bad model output — it is an agent with more write capability than anyone intended, discovered after it uses it, next to a PCI-scoped checkout it should never have been able to reach.
Solution
Put every tool call — inbound and outbound — behind a single governed boundary. Agents run on Bedrock AgentCore Runtime and reach tools only through AgentCore Gateway, which enforces authentication, rate limits, and Cedar policy on writes. Money-moving actions route to a human approval queue rather than executing. The same commerce data layer that backs internal agent tools is exposed outward through an MCP server for inbound shopping agents, so catalog attributes and join keys are fixed once and serve both directions.
AWS services in this pattern
| Service | Role |
|---|---|
| Amazon Bedrock AgentCore | Session-isolated agent runtime, Gateway tool boundary, Memory with fine-grained access control, identity propagation, Observability and Evaluations. |
| Amazon Bedrock | Foundation model inference with per-task model routing and Guardrails for content and PII filtering. |
| AWS Lambda | Tool implementations — order lookup, stock check, refund proposal — one narrow function per catalog entry. |
| Amazon DynamoDB | Approval queue and agent action ledger; low-latency reads for session and cart state. |
| Amazon Aurora | Commerce system of record — orders, customers, products, inventory — with read replicas serving agent reads away from the transactional path. |
| Amazon API Gateway | Public edge for the MCP catalog surface, with throttling and WAF in front. |
| AWS WAF | Rate-based rules and managed rule groups on the MCP surface and the checkout path. |
| Amazon EventBridge | Fan-out for agent-proposed actions into approval workflows and downstream systems. |
| Amazon CloudWatch | Per-conversation cost metrics, token budget alarms, and agent trace retention. |
Architecture components
Agent runtime
AgentCore Runtime gives each session an isolated execution environment, so one runaway loop cannot degrade a neighbour. Bring your own framework — Strands, LangGraph, or an explicit control loop.
The tool boundary
AgentCore Gateway is the only path from agent to tool. Every action is declared in a typed catalog; anything undeclared is unreachable regardless of prompt. Rate limits are configured per caller.
Authorization on writes
Cedar policies evaluate every mutating call outside the model. Changing a price or issuing a refund is a permission decision, not an instruction the model can be argued out of.
Human approval queue
Money-moving proposals land in DynamoDB with the assembled evidence and are actioned by a person. The agent makes the decision cheap to take correctly; it does not take it.
Eval harness
A golden dataset per agent with a pass bar enforced in the deployment pipeline through AgentCore Evaluations. Every production incident adds a case.
MCP catalog surface
An MCP server over product, inventory and order reads, fronted by API Gateway and WAF. One outward interface for every assistant, with one audit log and one place to rate-limit.
Cost ceilings
Per-conversation token budgets and model routing by task, with CloudWatch alarms that fire before the threshold rather than after the invoice.
Trade-offs
Pro
One authorization model covers internal agent writes and the outward catalog surface, so there is a single place to reason about blast radius.
Con
Gateway becomes a hard dependency on the request path for every agent action. It needs the same availability treatment as the checkout.
Pro
Fixing catalog attributes and join keys once serves both internal agents and inbound shopping agents.
Con
That data work is usually the largest and least visible part of the project, and it front-loads cost before anything demoable exists.
Pro
Human gates on money-moving actions make the system defensible in an audit and survivable in an incident.
Con
Gates only work while reviewers actually read the evidence. Above a certain volume they degrade into a click, and the answer is to narrow what is gated rather than add reviewers.
Pro
Bring-your-own-framework means no proprietary orchestration lock-in; the substrate is AWS-managed and the agent logic is yours.
Con
You still own framework churn. Agent framework APIs are moving fast and an upgrade is a real maintenance event.
Pro
Exposing the catalog through MCP means one interface rather than a bespoke integration per assistant.
Con
It is a public interface to commercial data. Scrape resistance, per-caller limits, and token blast radius must be designed, not assumed.
Cost notes
Dominated by model inference and AgentCore runtime session time, not storage or compute. The variables that actually move the number are conversation volume, tool calls per conversation, and which model each step routes to — a cheap model for classification and routing with a frontier model reserved for the hard turns changes the total substantially. Model your own workload with the AgentCore pricing calculator before committing; naive first estimates are usually low because tool-call volume per conversation is underestimated.
Related patterns
Event-driven microservices on AWS — EventBridge, Pipes, and the Outbox Pattern
Production event-driven architecture on AWS — EventBridge custom buses, EventBridge Pipes for the transactional outbox, SQS dead-letter queues, Step Functions for orchestration, and Lambda or Fargate workers. Decouple services without dual-writes.
Generative AI RAG on Bedrock — S3 Vectors + Knowledge Bases
Production retrieval-augmented generation on AWS — Bedrock Knowledge Bases on S3 Vectors for cost-efficient retrieval, Bedrock Guardrails for safety, and per-tenant inference profiles for spend caps. The 2026 AWS-native default for enterprise RAG.
Consulting engagements that deliver this pattern
eCommerce AI Agents on AWS
Production AI agents for eCommerce on Amazon Bedrock AgentCore — support and WISMO, inventory, merchandising, margin, returns and B2B. Tool boundaries, evals before launch, and a human on anything that moves money.
Agentic Commerce Readiness
Make your store sellable to AI shopping agents. ACP and UCP protocol surfaces, an MCP server over your catalog, and product data that survives an agent comparison — built on AWS.
Amazon Bedrock AgentCore Consulting
Production agent infrastructure on Amazon Bedrock AgentCore — Runtime, Gateway, Memory, Identity, Observability and Evaluations. Bring your own framework; we operate the substrate.
Deep dives
How FactualMinds Builds Production AI Agents for eCommerce on AWS (2026)
AWS AI agents for eCommerce on AgentCore Harness (GA June 17, 2026), Strands 1.0, and Bedrock Converse — not a native Shopify connector. Reuse Gateway ~180 to 95 ms and ~$791/mo at 50K sessions. Next.js is the ops dashboard, not the runtime.
Build eCommerce Store AI Agents on Amazon Bedrock AgentCore (2026)
Supervisor + 4 commerce specialists on AgentCore Runtime: 8 Gateway tools, Cedar write gates, and the same ~180→95 ms Gateway canary signal — sample architecture, not a client engagement.
How to Secure AI Agents Connected to Your eCommerce Store (2026)
Store-connected agents fail at secrets, PII, and payment tools — not at prompts. Reuse Gateway ~180 to 95 ms and ~$791/mo at 50K sessions. Cedar LOG_ONLY then ENFORCE.
Building a Multi-Agent eCommerce Operations Team (2026)
Staff Sales, Customer, Inventory, Product, and Finance as optional specialists — not week one. Supervisor + hop caps. Reuse Gateway ~180 to 95 ms and ~$791/mo at 50K sessions.
Frequently asked questions
Why route every tool call through Gateway instead of letting agents call Lambda directly?
Because a tool catalog written in a design document is a convention, and a convention constrains only the well-behaved case. Gateway makes it an enforced boundary: undeclared calls do not resolve, rate limits apply per caller, and Cedar evaluates writes outside the model. Under adversarial input this is the difference that matters — a prompt injection can persuade a model to attempt a destructive action, but it cannot make an undeclared tool exist.
When does this pattern not fit?
Three cases. If the decision you are automating is genuinely deterministic — a human follows the same rule every time with no judgement — build a workflow instead; it is cheaper, faster and easier to audit. If your orders, inventory and product systems disagree about what a SKU is, this architecture will faithfully deliver confidently wrong answers, so fix the join keys first. And if you have exactly one assistant needing exactly one system, the MCP surface is over-engineering; call the API directly.
What breaks first in production?
In our experience of the design reviews rather than a specific incident: the approval queue. Teams gate the obvious money-moving action, leave a broad generic write tool ungated beside it, and then discover volume has outstripped reviewer attention so approvals have become reflexive. The mitigations are narrow verb-shaped tools rather than generic patch endpoints, and pairing any deflection metric with a repeat-contact or reversal rate so a rubber-stamp gate shows up in the numbers.
Do we need the MCP surface if we only want internal agents?
No. The two halves are separable and most merchants start with internal agents only. The argument for planning both together is that they share the data layer — attribute completeness, typed specifications and reliable identifiers — so scoping that work once against both consumers avoids doing it twice. Skip the API Gateway and WAF edge until you actually want inbound agents.
How does the PCI-scoped checkout stay out of reach?
By not appearing in the tool catalog. The agent has no declared tool that touches the cardholder data environment, so there is no path to it through Gateway regardless of what the model attempts. Agent-originated orders reach checkout through the same authenticated application path a human order takes. Keep the CDE in its own account and VPC, and treat the agent as an untrusted caller of your ordinary order API.
Want this pattern deployed end-to-end?
Our team builds these patterns in production for SaaS, healthcare, fintech, and enterprise customers. Tell us your constraints and we'll scope the engagement.