Agentic AI Manufacturing Reasoner for Automated Root Cause Analysis

apollo_tyres · Automotive · 2025 · source Agentic: yes · promotional bias: high · source-backed · extracted with prompt 0.5.2 (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: Manufacturing root-cause analysis

Apollo Tyres needed faster root-cause analysis for tire curing processes across many automated presses.

Constraints:

• Real-time IoT data
• 250+ curing presses
• Multistep reasoning
• Plant engineer corrective action

Architecture

Apollo Tyres' Manufacturing Reasoner is a Bedrock Agents system over industrial IoT curing data. A Chainlit UI on EC2 accepts natural-language questions; a primary AI agent classifies question complexity and routes to specialized agents; Bedrock Knowledge Bases and OpenSearch retrieve context; a complex transformation engine handles question-specific context transformations; an RCA agent runs a multi-step, multi-LLM diagnostic workflow; a visualization agent generates Plotly chart code with Claude Sonnet; the primary agent combines records, explanation, and charts and streams the result back to plant engineers.

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

flowchart LR
  curing-machine-iot-data[Curing machine IoT data] --> aws-data-platform[AWS data platform]
  aws-data-platform --> bedrock-knowledge-bases[Bedrock Knowledge Bases]
  chainlit-ui[Chainlit UI] --> primary-ai-agent[Primary AI agent]
  primary-ai-agent --> bedrock-knowledge-bases
  primary-ai-agent --> complex-transformation-engine-agent[Complex transformation engine agent]
  primary-ai-agent --> rca-agent[RCA agent]
  primary-ai-agent --> visualization-agent[Visualization agent]
  plant-engineer[Plant engineer] --> chainlit-ui

Components

Data flow

Curing-machine IoT data streams into AWS and Redshift. A plant engineer asks a natural-language question in Chainlit, the primary agent routes the question to Bedrock-powered retrieval and specialist agents, context and Redshift records are analyzed, the RCA and visualization agents produce explanations and chart code, and the combined answer streams back for corrective action.

Why this architecture

Apollo needed multi-agent retrieval and reasoning because manual RCA across millions of manufacturing parameters was slow and subelement analysis was not possible with traditional tools. The architecture separates routing, retrieval, transformation, RCA, and visualization so each task can be optimized, while model/workflow pruning keeps response latency usable for plant troubleshooting.

Models used: LLMs through Bedrock · Anthropic Claude Sonnet · small language models

Scale

• The reasoner covers more than 250 automated curing presses and more than 25 automated subelements.
  “over 25 automated subelements or activities should be focused on across more than 250 automated curing presses”article, stated
• RCA effort dropped by about 88%, from up to 7 hours to less than 10 minutes per issue.
  “They realized an approximate 88% reduction in effort in assisting RCA for DCT through self-diagnosis of bottleneck areas on streaming and real-time data.”article, stated
• Apollo targets about INR 15 million annual savings in the PCR division.
  “Overall, the targeted benefit is expected to save approximately 15 million Indian rupees (INR) per year just in the passenger car radial (PCR) division across their three manufacturing plants.”article, stated

Alternatives considered (roads not taken)

Manual dashboard-driven RCA

Rejected because: Manual analysis consumed hours and did not support subelement-level bottleneck diagnosis.

Always run all agents and workflows

Rejected because: Multiple agents created response delays, so Apollo selected smaller models and disabled unused workflows.

Patterns

multi-agent-orchestration (manufacturing)

The primary agent classifies questions and delegates to specialized agents for multistep reasoning.

rag-retrieval (manufacturing-data)

Bedrock Knowledge Bases and OpenSearch retrieve context for machine-data questions.

Tradeoffs

Reduce latency by pruning and routing the agent workflow.

Chose Appropriate LLM/SLM selection plus disabling unused workflows over Always invoking the full multi-agent process.

Rationale: The factory troubleshooting experience needed faster response even if that meant narrowing the active workflow path.

How to keep RCA response time useful.

Chose model selection and unused-workflow pruning over running all Bedrock agents on every request.

Rationale: The initial multi-agent path exceeded one minute, so Apollo narrowed active workflows and selected appropriate LLM/SLM paths.

Gotchas (what bit them)

The initial multi-agent Manufacturing Reasoner was too slow for operational troubleshooting.

Root cause: Multiple Bedrock agents made the first data retrieval and processing path exceed one minute.

Resolution: Apollo optimized model selection and disabled unused workflows to reduce response time to roughly 30-40 seconds.

LLM-generated visualization code failed on extensive manufacturing datasets.

Root cause: Initial code often contained inaccuracies or did not handle large record volumes correctly.

Resolution: Apollo iteratively refined chart-code generation to handle arbitrary data-frame sizes more reliably.

Evaluation

Apollo measured RCA time, manual effort reduction, and targeted savings.

Metrics: analysis time · manual effort · savings

Outcomes

• Manual analysis dropped from 7 hours to under 10 minutes, according to the summary.

The solution targets savings in the passenger car radial division.