The problem
Industrial operators receive thousands of raw anomaly logs every week — most are noise, but a few threaten safety, availability, or equipment integrity. Engineers waste hours triaging by hand and still miss critical issues.
What I built
A full-stack platform that ingests anomaly reports from multiple data sources and uses a multi-agent AI system to triage, classify, and resolve them.
Multi-agent classification pipeline
A LangGraph state machine chains specialized agents:
gather_context → classify → suggest_actions → generate_plans → finalize
- Classifier Agent — scores each anomaly across three industrial-safety dimensions (integrity, availability, process safety, 0-5 each), computes a criticality score (0-15), maps to urgency tiers. Uses few-shot examples drawn dynamically from past validated classifications + a secondary LLM critique loop.
- Context Gatherer Agent — builds a four-layer dossier per anomaly: general precedents, similar-equipment precedents, equipment maintenance history, and technical manual excerpts — all retrieved via semantic search.
- Action Suggester Agent — recommends maintenance actions and matches anomalies to upcoming maintenance windows by proximity, location, and equipment.
RAG over the company knowledge base
PDFs, URLs, and technical manuals are chunked (recursive, semantic, fixed-size strategies), embedded with Nomic Embed Text (768-dim) via Ollama, and stored in PostgreSQL with pgvector + HNSW indexes for cosine-similarity search.
Streaming chat agent
A FastAPI service exposes 11 tools to the LLM via OpenAI function calling — equipment search, KB retrieval, statistics, anomaly creation. Real-time progress events ("Searching knowledge base…") stream to the UI.
Architecture decisions
- LangGraph over plain LangChain agents — triage is a fixed multi-step pipeline (gather → classify → suggest → generate → finalize) with branching, not a free-form ReAct loop. A state graph lets me control exactly which agent runs when, checkpoint state between steps, and retry a single node without re-running the whole chain.
- Closed-loop learning — every classification an engineer validates or corrects is stored and pulled back in as a few-shot example for the next Classifier Agent run, so accuracy compounds over time without needing to fine-tune a model.
- Provider-agnostic LLM layer —
llm_factorywraps OpenAI, OpenRouter, and Ollama behind one interface, so the deployment can swap between cloud models (accuracy) and local Ollama models (data residency, cost) per environment without touching agent code. - Three independent FastAPI services — the classification pipeline, the RAG/knowledge-base service, and the streaming chat agent have very different scaling and latency profiles: classification runs in batches, ingestion is I/O-heavy and can lag, and chat needs to stay responsive. Splitting them lets each scale and deploy independently.
What I'd do differently
- Add a structured evaluation set (held-out labeled anomalies) earlier instead of relying on hackathon-time spot checks, to catch classifier drift as few-shot examples accumulate.
- Cache embeddings more aggressively — recomputing them for unchanged manual sections on every ingestion re-run was the slowest part of the pipeline.
Tech stack
LangGraph · LangChain · FastAPI · OpenAI · Ollama · pgvector · PostgreSQL · Next.js