AI-Powered Supply Chain Root Cause Analysis and Investigation

continental · Automotive · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Automotive supply chain planning

Continental needed to answer supply-chain availability questions such as why a customer cannot get a tire across a global, highly interconnected planning network, without relying on slow manual root-cause investigation.

Constraints:

• the network spans 90,000 items, 800 locations, a planning horizon of more than one year, and more than one million intersections
• planning decisions are interconnected across plants, capacities, materials, and logistics flows
• the pilot needed to integrate with Continental's AWS data foundation and planning processes
• the agent needed to traverse supply-chain nodes without being overwhelmed by too many tools
• root-cause output had to be explainable to business analysts and avoid hallucinated answers

Architecture

Continental and AWS built an agentic supply-chain investigation system on top of Continental's AWS data foundation, Bedrock, Bedrock Agent Core, and AWS agent tooling. A user asks why an item is unavailable. The system starts from the demand location, traverses upstream through the supply-chain graph, queries nodes for relevant planning data, and then contracts the collected evidence into a root-cause analysis. The architecture evolved from one supply-chain agent with limited tools and hard-coded contraction into a multi-agent system with an orchestration agent, specialized node agents, a larger toolset, and a deep-reasoning agent that weighs evidence and tradeoffs before answering.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  planner-question-interface["planner-question-interface"] --> orchestration-agent["orchestration-agent"]
  orchestration-agent["orchestration-agent"] --> specialized-node-agents["specialized-node-agents"]
  orchestration-agent["orchestration-agent"] --> deep-reasoning-contraction-agent["deep-reasoning-contraction-agent"]
  specialized-node-agents["specialized-node-agents"] --> supply-chain-network-data["supply-chain-network-data"]
  specialized-node-agents["specialized-node-agents"] --> agent-toolset["agent-toolset"]
  agent-toolset["agent-toolset"] --> supply-chain-network-data["supply-chain-network-data"]
  supply-chain-network-data["supply-chain-network-data"] --> deep-reasoning-contraction-agent["deep-reasoning-contraction-agent"]
  deep-reasoning-contraction-agent["deep-reasoning-contraction-agent"] --> investigation-summary["investigation-summary"]
  investigation-summary["investigation-summary"] --> planner-question-interface["planner-question-interface"]
  aws-agent-platform["aws-agent-platform"] --> orchestration-agent["orchestration-agent"]
  aws-agent-platform["aws-agent-platform"] --> specialized-node-agents["specialized-node-agents"]
  aws-agent-platform["aws-agent-platform"] --> deep-reasoning-contraction-agent["deep-reasoning-contraction-agent"]

Components

Data flow

A planner asks why a tire or item is not available. The investigation starts at the regional distribution center where demand appears, then expands upstream through affected supply-chain nodes. Specialized agents query and retrieve data at each node using a broader toolset than the original single-agent version. The contraction phase aggregates the traversed information, uses a deep reasoning agent to weigh evidence and tradeoffs, and returns an investigation summary with issue, root cause, key facts, and a supply-chain graph for analyst validation.

Why this architecture

The system evolved to multi-agent orchestration because one agent with limited tools could miss signals, lose context, or become overwhelmed as 20-30 tools were added. Keeping the investigation/expansion/contraction workflow preserved the useful deterministic supply-chain traversal, while specialized agents improved scalability and a deep reasoning contraction agent replaced brittle hard-coded root-cause logic. The business-facing graph and concise summary were included to make the answer understandable and trusted by analysts.

Models used: Amazon Bedrock · Amazon Bedrock Agent Core · AWS agents SDK · agentic AI · deep reasoning agent

Scale

• Continental traces its tire technology history to 1871 and more than 150 years of experience.
  “we've been driving innovation in tire technology since 1871.”transcript, stated

  “operating in 54 countries worldwide with more than 150 years of experience.”transcript, stated
• Continental operates in 54 countries.
  “Operating in 54 countries doesn't only mean we sell tires in 54 countries.”transcript, stated
• The production network spans 19 production sites in 16 countries across five regions.
  “We have 19 production sites in 16 countries across five regions.”transcript, stated
• The planning problem covers 90,000 items, 800 locations, more than one year of horizon, and more than one million intersections.
  “we are looking at 90,000 items in our supply chain. We have 800 locations. We have a planning horizon of more than 1 year.”transcript, stated

  “in the total network, we have more than 1 million intersections.”transcript, stated
• The agentic pilot reduced investigation time up to 90%, from one hour to five minutes for a specific use case.
  “we can reach up to 90% faster investigation time. So, for specific use case of reducing the investigation time from 1 hour to 5 minutes.”transcript, stated
• The single-agent design raised concerns about adding 20 or 30 new tools.
  “down the line I might add, you know, 20, 30 new tools? At some point my agent becomes overwhelmed”transcript, stated

Alternatives considered (roads not taken)

Classic on-premises server and application setup

Rejected because: It limited scalability and slowed innovation before Continental moved the supply-chain foundation to AWS.

Single supply-chain agent

Rejected because: It had limited tools, scalability concerns, and a deterministic contraction phase.

Hard-coded contraction/root-cause logic

Rejected because: The final version needed a reasoning agent to weigh evidence and tradeoffs instead of following fixed branches.

Patterns

multi-agent-orchestration (agent architecture)

The final system uses an orchestration agent to delegate supply-chain traversal to specialized agents for specific nodes and toolsets.

tool-use-orchestration (agent architecture)

Node agents use tools to query and retrieve supply-chain information while the orchestrator assigns the work.

llm-as-judge (reasoning)

The contraction phase uses a deep reasoning agent to weigh collected evidence and tradeoffs before issuing a root-cause analysis.

guardrails-io-filtering (safety)

The agents are instructed to prefer no answer over a wrong answer to reduce hallucinated root-cause analysis.

Tradeoffs

Retain deterministic supply-chain traversal but add agent reasoning.

Chose Classic graph root-causing enhanced by agentic reasoning over Purely deterministic root-cause logic.

Rationale: The team found deterministic graph traversal useful, but the final answer needed a reasoning step that could weigh evidence and tradeoffs.

Switch from one supply-chain agent to multi-agent specialization.

Chose Orchestration agent plus specialized agents over Single agent with expanding tool list.

Rationale: Specialization let the system add tools and node expertise while avoiding context loss or agent overload.

Show the supply-chain graph to users.

Chose Root-cause summary plus traversed-node graph over Text-only answer.

Rationale: Business analysts need to see whether the traversed supply-chain path makes sense before trusting the answer.

Gotchas (what bit them)

A single agent can become overwhelmed as tools grow.

Root cause: The first version put limited tools and growing tool scope into one supply-chain agent.

Resolution: Move to an orchestration agent with specialized agents, allowing new agents or tools to be added without overloading one context.

Hard-coded contraction limited the first root-cause design.

Root cause: The initial contraction phase followed deterministic if-this-then-that logic rather than weighing uncertain evidence.

Resolution: Replace it with a deep reasoning agent that weighs evidence and tradeoffs to produce a conclusive analysis.

The pilot still lacked full production integration scope.

Root cause: The second version proved the architecture but did not yet include all functional skills needed inside planning processes.

Resolution: Extend agent functional scope and enable productive integration into Continental's planning workflows.

Evaluation

Continental evaluated the pilot by comparing investigation time, accuracy, manual effort, explainability for business colleagues, and readiness for productive planning-process integration.

Metrics: up to 90% faster investigation time · one hour to five minutes for a specific use case · higher accuracy · fewer manual efforts · business-adequate explainability · full functional scope for productive integration

Outcomes

• The pilot reduced investigation time up to 90%, from one hour to five minutes in a specific use case.
• The system improved accuracy, reduced manual effort, and made complex supply-chain outcomes explainable to business users.
• The team identified remaining work to add functional skills and integrate productively into planning processes.

Continental's supply chain includes 90,000 items, 800 locations, a planning horizon over one year, more than one million intersections, and 19 production sites across 16 countries.