From data to decisions: Conversational supply chain intelligence with Amazon Quick and Amazon Bedrock AgentCore

Giving supply chain teams direct access to the systems behind their decisions. Every supply chain generates constant signals: orders in approval, shifting lead times, slowing ports, drifting prices, disruptions. The problem isn’t scarce data. It’s the distance between the data and the decision-maker. Answering “which top-revenue SKUs are exposed to the current port closure, and what will it cost?” used to mean knowing which system held each piece and stitching them together by hand while the domain expert waited. Could that manager instead ask in plain language and get an actionable, cross-system answer in seconds? Amazon Bedrock AgentCore is the intelligence layer, exposing enterprise Model Context Protocol (MCP) servers as a composable tool layer. Amazon Quick turns that into action for personas with no setup. Answers come from live systems of record and grounded documents, not model recall, and every change waits for a named human. In this post, we walk through this pattern end to end, from a conversational walkthrough in Amazon Quick to the AgentCore tool layer behind it, and we show you how to deploy it yourself. The problem: Data-rich, insight-poor Figure 1: Domain expertise sits with users while operational data is fragmented across ERP, monitoring, procurement, and email Each question needs its own tool: inventory from the enterprise resource planning (ERP) system, disruptions from email or news, a request for quotation (RFQ) from procurement, and compliance from a checklist. Correlating is manual. A day in the life A manager’s morning traditionally spans the ERP (inventory exceptions), monitoring tool (alerts), procurement (alternatives), email (RFQ), and a tracker: 45–60 minutes across five systems with a dozen-plus context switches. Conversationally it’s three prompts in one tool, “Any critical disruptions affecting my top-revenue SKUs?” → “Assess the TechComp halt and issue an emergency RFQ to approved alternatives” → “Looks good. Send it.”, in minutes. Figure 2: Traditional multi-tool flow versus a single conversational thread orchestrated by AgentCore Deep dive: Supply chain scenario walkthrough The following five steps follow one disruption from detection to an approved emergency RFQ, all in a single Amazon Quick conversation. Step 1: Discovery – “What tools do I have?” The user asks “What supply chain tools do I have?” and Amazon Quick lists the supply chain MCP servers published in AWS Agent Registry. Because an administrator has turned on the registry integration, the four business MCP servers already appear as connector cards, with connection details pre-populated and no URLs to enter by hand. The orchestration agent is added as its own MCP connector. Step 2: Querying – “Show me active disruptions” “Check active supply disruptions” calls the Disruption Alerts MCP ( assess_disruption_impact ): three disruptions with severity, region, and SKU counts. How we solve it: Quick routes the request through AgentCore to the MCP server, which queries backend monitoring and returns a structured result, no dashboard or export. Step 3: Drill-down – “Assess the critical one” The user opens the TechComp Production Halt. assess_disruption_impact(disruption_id="DISR-002") correlates order, customer, and inventory data: $750K at risk, 23 orders, three days of supply. How we solve it: one MCP tool call fans out across systems of record, so the manager gets a consolidated impact read without touching the ERP. Step 4: Action – “Get mitigation recommendations” The user asks for mitigation. recommend_mitigation(disruption_id="DISR-002") chains the Governance MCP (verify approved alternatives) and Quoting MCP (contract-aligned quote), one flow from one request. How we solve it: the agent plans and sequences the calls, so a single ask spans disruption, governance, and quoting with no manual hand-offs. Step 5: Automated follow-up The user then sets up proactive monitoring (“Alert me every morning if there’s a new critical disruption”). The same flow can run unattended from an inbound supplier email. How we solve it: the same agent and tools run on a schedule or email trigger, posting review-ready cards to the Activity Feed for a person to approve. Put end to end, those five steps are a single runtime sequence: Figure 3: Runtime sequence for the walkthrough, where every result returns to Amazon Quick for approval Solution architecture That’s the experience. Here’s how it is built: the pattern separates the intelligence layer from the interface layer, so each evolves independently, with Amazon Quick as the interface and AgentCore as the intelligence. Figure 4: End-to-end architecture from Amazon Quick to AgentCore (Gateways, Runtime, Identity, Policy) to backends, with AWS Agent Registry alongside Amazon Bedrock AgentCore: The intelligence layer Amazon Bedrock AgentCore is a modular agentic platform for building, deploying, and operating agents securely at scale. It offers more than we use here. Four of its services are relevant to this pattern: Runtime – Serverless hosting for MCP servers and agents, with session isolation and built-in identity. Gateway – Turns APIs, AWS Lambda functions, and services into MCP-compatible tools behind a secure managed endpoint, standardizing tool access. Reasoning is the calling agent’s. Identity – Authentication and credential management, compatible with existing identity providers. Policy – Deterministic authorization rules, authored in natural language or Cedar, that intercept every tool call before execution, keeping an agent in its lane on procurement and financial data. The MCP protocol: How tools communicate MCP is an open standard for how AI models interact with external tools. Each server exposes tools with typed parameters: { "server_name": "sc-disruption-alert-gateway", "tools": [{ "name": "assess_disruption_impact", "parameters": { "disruption_id": {"type": "string"}, "context": {"type": "object"} // order, inventory, revenue data } }] // plus classify_severity, recommend_mitigation, get_escalation_chain } This means: AI clients (Quick, custom agents, other MCP apps) can consume the same servers. Backends (SAP, Oracle, custom microservices) can be wrapped as an MCP server. Tool discovery is automatic. Clients query the registry for schemas at runtime. AWS Agent Registry: The discovery layer The registry is the governed discovery layer: a publisher submits a record, a curator approves it, and only then is it discoverable through hybrid search, browsing, or the registry’s MCP endpoint. One scale reality worth noting: because schemas are discovered at runtime, treat each as a contract, versioning new alongside old for breaking changes. Figure 5: Publishing an MCP server record to AWS Agent Registry, a curator approving it, an administrator linking it to Quick, and approved records becoming connector cards Multi-step orchestration The reasoning layer is an agent on AgentCore Runtime, an agent record at its direct invocation URL through a Custom MCP connector, with no Lambda or gateway. Here, it’s the Order Fulfillment Agent. Given one request it plans which tools to call and in what order: User: "A supplier just went down. Find alternatives, verify compliance, issue an emergency RFQ." Disruption Alerts MCP -> identify the disruption Governance MCP -> approved alternatives + compliance + budget authority Quoting MCP -> contract-aligned quote -> one consolidated recommendation Security and governance architecture Every tool call passes through the same AgentCore control set before it reaches a backend. Figure 6: The uniform AgentCore control set before the backend (IAM auth, per-tool authorization, input validation, policy evaluation, rate limiting, data-boundary enforcement, audit logging) The MCP servers in this pattern MCP server Capabilities Example queries Quoting Engine ( sc-quoting-gateway ) Quote generation, pricing rules, validation “Contract-aligned quote for 500 units of SKU-A” Governance Engine ( sc-governa