ai newsDo., 22. Okt.
EilmeldungNVIDIA Unveils Minerva to Bring End-to-End Observability for AI Factories

Amazon Quick und Bedrock AgentCore machen Lieferketten per Chat abfragbar

Lieferkettendaten liegen oft verstreut in ERP, Monitoring und Beschaffung. Amazon Bedrock AgentCore stellt diese Systeme als kontrollierte Toolschicht bereit, Amazon Quick bündelt sie in einer Konversationsoberfläche für Entscheidungen.

AWS ML BlogDienstag 19:52 · 20.10.DE12 Min. Lesezeit
Bild: AWS ML Blog

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.

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 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

The following five steps follow one disruption from detection to an approved emergency RFQ, all in a single Amazon Quick conversation.

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.

“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.

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.

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.

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

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 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:

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:

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

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)

Amazon Quick puts AgentCore tools before business users through chat, agents, the Activity Feed, and automated workflows, with no technical setup.

The Activity Feed is the proactive surface of Amazon Quick, a unified inbox where agents post results, alerts, and recommendations. Feed items are:

AgentCore tools plus the proactive capabilities of Amazon Quick give two paths, time-based and email-driven, through a common trigger → agent → output pipeline.

Figure 7: Three-stage pipeline from trigger (schedule or email) to autonomous agent (assess_disruption_impact, check_supplier_approval, apply_approval_rules, validate_quote) to review-ready card

Suppliers reply to an emergency RFQ by email with pricing. The agent validates each (approved supplier? within guidelines?) and stages the result. It does not author a quote, pick a winner, or issue a purchase order (PO).

Phase 1: Setup (one-time, approximately 5 minutes)

Supply chain procurement assistant. On a supplier RFQ reply with pricing: 1) extract SKU(s), quantities, pricing; 2) validate approved vendor (Governance MCP); 3) check pricing within guidelines (Quoting MCP); 4) post a review-ready card (approved-supplier, within-guidelines); do NOT draft a PO or select a supplier. Create Schedule: “Every 2 hours during business hours, check for new supplier replies and validate them.” Phase 2: Runtime (fully automated)

Schedule -> email from "TechSupply Co" (MCU-7200, 10,000 units @ $2.45/unit) -> Governance MCP: approved? | Quoting MCP: within guidelines? -> "Supplier Response - Ready for Review" card The feed card carries the validation results and decision-relevant facts:

The reviewer compares validated responses and either selects a supplier and issues the PO, or rejects with a logged reason. Selection and the PO stay with a person.

Schedule-triggered, the same pattern applies: a daily 8:30 AM agent checks for new critical or high-severity disruptions, assesses impact, flags anything under seven days of supply as URGENT, and posts an alert card with an Issue Emergency RFQ action.

This isn’t a “replace everything” argument. Dashboards remain superior for trend visualization, collaborative analysis, regulatory reporting, and exploratory analysis. Use conversational AI for real-time operational decisions and BI for strategic analysis. They complement, not compete.

One Quick Agent serves all three personas: the manager maintains continuity, procurement sources with compliance-awareness, the analyst correlates signals. Persona also bounds reach, through row/column-level security and per-persona MCP-tool scoping, so procurement does not see finance data.

Deploying the pattern takes three phases: provision the infrastructure, connect Amazon Quick to your data and the registry, and turn on monitoring.

Setup uses two surfaces, so each of the following steps names where it happens: the Amazon Quick web console in a browser (Amazon Quick Sight permissions, Agent Registry linking, connectors, and agent settings) and the Quick Desktop App (connecting Outlook for email automation). The conversational experience in the Desktop App comes last, once setup is done.

Everything is open source and scripted: clone the quick-for-supply-chain example in the aws-samples/sample-amazon-quick-suite-knowledge-hub repository and follow its README.md, or point a coding agent like Kiro at it.

The README.md covers three phases. Phase 1 deploys the AgentCore stack: the identity layer (an Amazon Cognito user pool and app client, authorization-code OAuth flow, plus a test user), four business-rule MCP servers (each an AWS Lambda function fronted by its own AgentCore Gateway, a capability of Amazon Bedrock AgentCore, using CUSTOM_JWT authorization), the gateway targets mapping the tools of each Lambda function, and sc-order-fulfillment-agent on AgentCore Runtime as a container, with least-privilege IAM roles. Phase 2 uploads the synthetic dataset to Amazon S3. Phase 3 verifies gateways and runtime are Ready. Six Agent Registry records are approved.

Figure 8: AWS Agent Registry console with six approved records (four MCP Server, one Agent, one Skills)

In the Amazon Quick web console (browser): grant Amazon Quick access from the Amazon Quick Sight admin page (Manage Quick Sight → Security and permissions) to both the S3 bucket and Amazon Athena, since each table is served through an Athena source over an AWS Glue database. Without the Athena grant, dataset creation fails.

Figure 9: Amazon Quick Sight Security and permissions, with Amazon Athena alongside Amazon S3

Linking the registry is one-time and administrator-level. Creating a connector is per-user. Both happen in the Amazon Quick console. See the AWS Agent Registry integration guide.

An administrator links one Agent Registry to the Quick account. In the Amazon Quick web console (admin): go to Manage account → Permissions → AWS Agent Registry and turn on the registry ( sc-supply-chain-registry, one per account). Only registries in your account and Region, agent-registry namespace, AWS_IAM (SigV4) authorization, and READY status appear. The Quick-managed service role links it.

Figure 10: Linking the registry, where only READY, AWS_IAM registries are selectable

After the registry is linked, approved MCP server records become connector cards: the four business MCPs as cards, the order-fulfillment agent added manually. At scale, federate connector authentication through your identity provider and provision connectors to groups, with the Cognito user pool as the seam.

In the Amazon Quick web console (per user): the four cards appear on the Connectors page ( sc-quoting-mcp, sc-governance-mcp, sc-invoice-processing-mcp, sc-disruption-alert-mcp ). Authenticate through the OAuth authorization-code flow ( OAUTH2_AUTHORIZATION_CODE ) with client ID, secret, and token, authorization, and redirect URLs from the deploy script. Sign in as the test user, turn on tools, create and share.

Figure 11: The four business-MCP connector cards, with the order-fulfillment agent added manually

Registry-sourced connectors are Custom MCP connectors (relevant for custom permissions). Removing the link later doesn’t delete connectors already created.

Figure 12: The Authenticate step using the authorization-code OAuth flow (OAUTH2_AUTHORIZATION_CODE)

In the Amazon Quick web console: because it is an agent record, create its connector manually (Connectors → Create for your team → Model Context Protocol → Create new): name it sc-order-fulfillment-agent, point it at the AgentCore Runtime direct invocation URL from the deploy script, complete the same OAuth sign-in, create and share.

Figure 13: Creating the sc-order-fulfillment-agent connector, pointed at the AgentCore runtime invocation URL

The deployment creates the Supply Chain agent: a Quick Space, imported datasets and S3 knowledge base, and the agent with instructions, starter prompts, and welcome message. What remains is attaching the connectors.

In the Amazon Quick web console (agent settings): open the deployment-created Supply Chain agent (default id sc-supply-chain-agent ) and attach all five connectors (four business MCPs plus sc-order-fulfillment-agent ), or pass the five connector IDs to the setup script.

To make it proactive, Quick runs the same agent on a schedule or on incoming email and posts results to the Activity Feed. Both paths reuse the agent and tools you configured.

In the Quick Desktop App (Settings → Connections): connect Outlook and turn on email monitoring. Then, in Quick Chat, create two natural-language schedules, time-based (“Every morning, check for new critical disruptions”) and email-driven (“Every two hours in business hours, check supplier replies and validate”). The agent extracts pricing, runs the checks, and posts a card.

With the agent and connectors ready, ask in natural language in Amazon Quick Chat. Each prompt shows the data-then-rules pattern.

AgentCore and Amazon Quick are a repeatable enterprise-AI pattern: separate intelligence from interface. AgentCore turns fragmented backends into a composable, governed, AI-accessible layer through standard MCP interfaces. Amazon Quick democratizes access in natural language.

The gain is the collapsed decision chain: detect, research, decide, act, and log once spanned five tools, now one conversation. The AI researches, correlates, validates. The person decides. Every call is authenticated, authorized, policy-checked, and audited, and a 45-60 minute routine across five systems can collapse to minutes.

That is the shift from data-rich, insight-poor to data-rich, decision-ready. Start with one MCP server and one persona. The registry grows and the experience stays the same.

Vineet is a Sr. Worldwide Agentic AI Solution Architect at AWS, focused on Amazon Quick. He works closely with enterprise customers and partners to design, deploy, and scale AI-driven solutions. Vineet also co-led the AWS for Legal Tech initiative, helping legal and compliance organizations harness AI/ML to drive business value. He loves building and tinkering with agentic AI solutions and considers himself a lifelong learner. Vineet regularly speaks at AWS events and industry conferences, sharing his expertise on generative AI and agentic architectures.

Kamlesh is a Senior Specialist Solutions Architect for Generative AI at Amazon Web Services (AWS), focused on the automotive and manufacturing industries. He helps customers design scalable, secure, and cost-effective architectures that use generative AI, agentic AI, and machine learning to solve complex business problems and speed up time to value.

Sachin is a Head of Data and AI GTM and Architectures at AWS, where he advises enterprise leaders on their data and AI transformations. He partners with CXOs to design, deploy, and scale AI-driven solutions that turn strategy into measurable business value, with focus on supply chain, commercial excellence, new product introduction, manufacturing operations, and enterprise business services. Sachin is the author of “The 12 Factors of Enterprise Agentic AI: A Value Chain,” a vendor-agnostic framework for building production-grade agentic systems, and a recognized voice on operationalizing generative and agentic AI at scale.

Originaltitel: From data to decisions: Conversational supply chain intelligence with Amazon Quick and Amazon Bedrock AgentCoreQuelle: AWS ML Blog (AWS ML Blog). Original öffnen