Industrial reliability agent

Context

Reliability engineers work across several systems at once: an alert console, a sensor historian, maintenance and delay logs, and failure-mode (FMEA) records. A single question, such as why an alert fired and whether it has happened before, touches all of them.

Problem

To learn the root cause of a simple issue, and the fix that worked last time, engineers had to read through incident reports and root-cause analyses (RCAs). The answer existed, but it was spread across documents and systems nobody had time to search.

Role

I conceived the system and designed its architecture: the knowledge base it draws on, the plan library, the roster of specialist agents and how they hand work to each other. A team of engineers implemented it.

Architecture

1. Question and context. Each question arrives with the asset and organisation it concerns, so every agent works from the same context.
2. Knowledge base. A separate ingestion pipeline turns equipment manuals, reports and RCAs into a knowledge base per asset: documents are categorised, converted to text, summarised and embedded, with failure-mode (FMEA) data extracted alongside.
3. Plan selection. A plan picker matches the question against a library of reference plans written for common investigations. Only when nothing fits does a planner draft a new plan.
4. Specialist agents. The plan runs focused agents, each with narrow tools: the knowledge base, live ML alerts and their diagnosis, real-time sensor time series, maintenance and delay logs, charts and calculations.
5. Supervisor. A supervisor reads the specialists' findings and composes one answer.
6. Delivery. Answers stream back over server-sent events. Conversation state is checkpointed per session, and each agent caches responses keyed on the normalised question and its context.

Key decisions

Reference plans before free-form planning. Common investigations, such as diagnosing an alert, follow a known sequence of steps. Encoding those as reviewed plans makes answers repeatable and keeps the model from improvising on routine questions; the planner is reserved for genuinely new ones.

Many narrow agents instead of one agent with every tool. Each specialist sees only the tools and context for its domain, which keeps prompts short and failures easy to locate.

Caching keyed on context, not just the question. The same question about two different assets needs two different answers, so cache keys include a hash of the context alongside the normalised question.

Results

• A root-cause question that meant reading through incident reports and RCAs is answered in one conversation, drawing on the knowledge base, live ML alerts and sensor history together.
• Common investigations follow reviewed reference plans, so the same question runs the same steps every time.
• Answers carry the documents they drew on, so an engineer can check the source before acting.

What I'd change

The agents search documents, alerts and sensor data separately and relate them at question time, and they depend on a single LLM. I would add a graph database underneath that links assets, components, failure modes, alerts and past fixes, so relating an alert to its history becomes a fast traversal instead of several searches. The agents now run on a reusable agent platform behind an LLM gateway, so each step can use the model best suited to it.