Building an Agentic Data Analytics Platform:
QA, Root Cause Analysis, and Trend Detection Using LangGraph

This article is a complete technical walkthrough of an agentic data analytics platform we built at Rainbow Intelligence. The system lets users ask three types of questions about their business data — QA queries, root cause analysis, and trend/pattern detection — using a multi-agent pipeline built on LangGraph and LangChain.

This is not a tutorial on basic text-to-SQL. This covers the full production architecture — including how we handle schema discovery, semantic table retrieval, multi-database support, parallel hypothesis generation, and dynamic Python code execution for trend analysis.

---

The problem we set out to solve

A retail company with 50 stores has all its sales data in PostgreSQL. Their management team wants answers to questions like:

• Which store had the highest sales in April?
• Why were sales down 18% in the North region last week?
• What is the trend in average basket size over the last 6 months?
• Which product categories are growing fastest?
• What is the correlation between weather and footfall across stores?

Getting answers to these questions today requires a data analyst to write SQL, run the query, export data, build a chart, and send it. That takes hours or days. Most questions never get asked because the effort is too high.

Our platform lets a manager type any of these questions into a chat interface and get the correct answer in under 30 seconds — with the right chart, the right data, and the right explanation.

The goal is not to replace analysts. It is to make analysis available to everyone, instantly.

---

Three types of queries — three different agent pipelines

Before building anything, we classified the types of questions users ask about business data into three categories. Each requires a completely different approach:

The first thing the system does when a user submits a query is classify it into one of these three types. This classification is done by the Managerial Agent, which then routes the query to the correct specialised pipeline.

---

Phase 0 — One-time schema ingestion

Before any query can be answered, the system needs to understand the database structure. This is a one-time setup step — not done per query. We call it the Schema Ingestion Agent.

What the Schema Ingestion Agent does

It connects to the client's database and performs the following steps:

1. Fetches all CREATE TABLE statements — including column names, data types, constraints, and any column-level comments defined in the schema.
2. Reads table and column comments — these are the most valuable signals for understanding what data actually means. A column named amt becomes meaningful when its comment says "Total invoice amount in INR excluding GST".
3. Generates natural language descriptions for each table by combining the schema definition with the comments using an LLM call.
4. Chunks the schema intelligently — one chunk per table, containing the table name, columns, types, and the generated description.
5. Embeds and stores in a vector database (ChromaDB or Pinecone), keyed by table name.

Without schema ingestion, every query would need to send the entire database schema to the LLM. A database with 80 tables would overflow the context window and cost a fortune per query. Semantic retrieval reduces context size — and cost — by 90%.

---

The Managerial Agent — intent detection and routing

Every user query enters the system through the Managerial Agent. This agent has two jobs:

• Classify the intent — is this a QA query, a root cause question, or a trend request?
• Route it to the correct specialised pipeline.

We use a structured LLM call with a Pydantic output model to classify every query. The model returns the intent type, confidence score, reasoning, time range, and any entities mentioned — such as store, product, or region. With 10 few-shot examples per category in the prompt, classification accuracy reaches above 94% across diverse business domains.

LangGraph's conditional edges then handle the routing — clean, explicit, and fully traceable.

---

Pipeline 1 — The QA Agent

For queries like: "Which store had the highest sales in April?"

The QA pipeline answers factual questions about the database through four steps:

Multi-database support

The SQL execution layer is database-type-aware. The same pipeline works across PostgreSQL, MySQL, MSSQL, and Google BigQuery — the client simply specifies their database type during onboarding and the correct driver is used automatically throughout.

---

Pipeline 2 — The Root Cause Analysis Agent

For queries like: "Why were sales down last week?"

Root cause analysis is fundamentally different from a QA query. There is no single SQL query that answers why. You need to form hypotheses, gather evidence from multiple sources, and validate them against real data. This is where multi-agent architecture genuinely earns its complexity.

The RCA pipeline runs five agents — some in parallel — to build a complete, validated explanation:

Why run agents in parallel?

Running the Web Context Agent and Hypothesis Validation Agent simultaneously — using LangGraph's fan-out pattern — cuts the total RCA response time from roughly 45 seconds to 25 seconds. Both agents need the hypotheses as input, neither needs to wait for the other, so there is no reason to run them sequentially.

Example RCA output

For the query "Why were North region sales down 18% last week?", the system returns:

---

Pipeline 3 — The Trends & Patterns Agent

For queries like: "Show me the 6-month sales trend by region"

Trend analysis requires more than a SQL query and a text answer. It needs data transformation, time-series analysis, and visualisation. We solve this with a dynamic Python code generation and execution approach.

Why generate code dynamically?

Different trend queries need completely different analysis. A question about 6-month revenue trends needs a line chart with a moving average. A question about return rate patterns needs a heatmap by category and week. A correlation query needs a scatter plot with regression. No static template handles all of these — but an LLM generating fresh Pandas code for each query does.

Sandboxing is non-negotiable

During testing, we discovered that GPT-4o occasionally generates code that tries to import requests, access environment variables, or read files outside the temp directory. The sandbox blocks all of this from the start. Never run LLM-generated code in production without strict isolation.

---

The complete system — how it all connects

The full system is a single LangGraph state machine with three sub-graphs — one per pipeline. Every query flows through the same entry point (the Managerial Agent) and the same schema retrieval step before being routed to the correct pipeline.

The shared state carries everything the agents need: the user query, the retrieved schema context, the classified intent, intermediate results from each pipeline, and an error log. LangGraph's PostgreSQL checkpointing means the state survives server restarts — critical for long-running RCA queries.

---

Key lessons from production

1. Schema comments are worth more than anything else

The single biggest factor in SQL generation accuracy is the quality of column comments in the database schema. A column named qty with no comment generates wrong SQL 40% of the time. The same column with the comment "Number of units sold, always positive integer" generates correct SQL over 94% of the time. Before deploying for any client, we now spend time adding meaningful comments to their schema. It is the highest-ROI improvement possible.

2. Validate SQL before executing — always

Never execute LLM-generated SQL directly against a production database without validation. We check for: correct table names (must exist in the retrieved schema), no destructive operations (no DROP, DELETE, UPDATE, or INSERT), valid syntax, and reasonable query complexity. A badly generated query on a 50-million-row table without a LIMIT clause can bring down the database.

3. The RCA pipeline needs a confidence threshold

Early versions of the system would return a root cause explanation even when evidence was weak. We added a minimum confidence threshold — if no hypothesis reaches 0.6 confidence after validation, the system returns "Insufficient data to determine root cause" instead of speculating. In production, a confident wrong answer is far more damaging than an honest "I don't know".

4. Dynamic code execution requires strict sandboxing

Running LLM-generated Python code requires heavy isolation from day one — not as an afterthought. No network access, no access to environment variables, limited memory, and a hard timeout. These constraints must be enforced at the subprocess level, not just in the prompt instructions to the LLM.

5. Stream responses to the user

QA queries complete in 3–5 seconds. RCA queries take 20–30 seconds. Without streaming, users assume the system has broken. We stream partial results — intent classification first, then retrieved tables, then the SQL, then the answer — so users see progress immediately and trust the system is working.

---

Who is this platform for?

---

Conclusion

An agentic data analytics platform does not replace your data analysts — it removes the queue that forms in front of them and gives every manager direct, instant access to their own business data. No more waiting hours for a report. No more questions that never get asked because the effort is too high.

The architecture described here — intent classification, vector-based schema retrieval, multi-agent RCA with parallel hypothesis validation, and dynamic trend code generation — is production-tested and works across PostgreSQL, MySQL, MSSQL, and BigQuery. The full system can be built and deployed in 6–10 weeks depending on the complexity of the client's schema and the number of query types required.

If your team is spending hours waiting for SQL queries to be written and run — this is solvable. Right now. With technology that exists today.