--- title: Agentic Commerce on AWS — AgentCore, Gateway, Cedar, and an MCP catalog surface description: Reference architecture for eCommerce AI agents on AWS: AgentCore Runtime behind a Gateway tool boundary, Cedar authorization on writes, human approval on money-moving actions, and an MCP server exposing the catalog to inbound shopping agents. url: https://www.factualminds.com/patterns/agentic-commerce-on-aws/ category: ai publishDate: 2026-08-30 updateDate: 2026-08-30 --- # 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. ## 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 - **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. ## 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 Estimate 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 - generative-ai-rag-on-bedrock ## FAQ ### 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. --- *Source: https://www.factualminds.com/patterns/agentic-commerce-on-aws/*