From Data to Insights: Building an Autonomous Analytics System with LangGraph

How I Built a Multi-Agent System That Automatically Transforms Raw Snowflake Data into Polished Business Reports.

Across the organization, stakeholders regularly need answers: KPI summaries, financial comparisons, and model performance insights. These questions often come up ahead of meetings, reviews, or decision points, and they usually need answers now, not days later.

In practice, getting those answers is slow. A single question typically triggers a long manual pipeline: writing SQL, validating results, generating charts, moving data between tools, and finally summarizing everything into a report. By the time the analysis is ready, the discussion it was meant to support may already be over.

What stakeholders needed was a faster and more reliable way to turn questions into insights without waiting on manual analysis cycles or dealing with technical complexity. The goal was an automated system that could take an analytics question, work through the data step by step, and deliver a clear, decision-ready report in minutes. By abstracting away query writing, visualization, and analytical interpretation, the system enables stakeholders of all technical backgrounds to access insights independently, without relying on data teams or manual workflows.

The result was LangGraph-Insights: a multi-agent system that plans analyses, writes (and fixes) its own SQL, generates charts, and delivers a polished PDF report directly to stakeholders. In this post, I'll walk through how I built it using LangGraph, Anthropic Claude, and Snowflake.

What This Project Is (and Isn't)

This isn't a chatbot that answers analytics questions in plain text.
It's an autonomous analytics system that:

• Breaks down complex business questions
• Iteratively queries real enterprise data
• Detects and fixes its own errors
• Produces artifacts humans actually use (charts, PDFs, summaries)
• Notifies users when results are ready

That difference guided how I designed the system from the ground up.

Prompts vs. Agents: Why We Chose Agents

To see why this architecture works, it helps to first understand the difference between a prompt and an agent.
A prompt is a single instruction sent to an LLM: "Here is some data, write a SQL query." It's linear and stateless. If the output is wrong, the process fails unless a human steps in.
An agent, on the other hand, is a system that uses an LLM as a reasoning engine to perform actions. It has:

• Tools: Capabilities to interact with the world (run SQL, search the web, write files).
• Looping: The ability to observe the output of its actions and decide what to do next.
• Memory: Context of what it has already tried and learned.

We chose an agentic approach because analytics is rarely a linear process. It requires exploration, error correction, and multi-step reasoning capabilities that a simple prompt-response cycle simply cannot provide.

The Problem: Why Single Prompts Fail at Analytics

Early on, I tried treating the problem as a simple prompt: give the model the schema, ask a question, get an answer. That worked for trivial cases, but it fell apart the moment the question required real analysis.
Real analytics problems break single-prompt approaches in three ways:

• Complexity: A question like "Compare operating expenses between Q2 and Q3 and explain the main drivers of change" involves multiple steps: querying raw transactions, aggregating by category, validating totals, and synthesizing insights.
• Reliability: LLMs will inevitably produce invalid SQL or make incorrect assumptions about the data. One mistake is enough to break the whole process.
• State & Structure: A single prompt can’t reliably track intermediate results, chart requests, report sections, or retry logic.

I needed a system that could reason iteratively, fail safely, and recover. This is where LangGraph shines.

The Architecture: A Hierarchical Multi-Agent System

Instead of one monolithic "AI brain", I designed a hierarchical agent graph, inspired by how real analytics teams operate.

• Supervisor Agent - Oversees the entire workflow and delegates tasks
• Lead Analyst Agent - Plans and executes the analysis
• Report Writer Agent - Turns analytical results into a structured report with visualizations
• Reviewer Agent - Evaluates correctness, clarity, and alignment with the business question

All agents communicate through a shared state object that acts as the system's memory.

class StateAgent(TypedDict):
    steps: list[dict]        # History of {goal, sql, output}
    report: str              # Evolving markdown report
    chart_requests: list
    analysis_feedback: str

This shared state is what allows the system to stay coherent across multiple reasoning steps.

Deep Dive: How the Agents Actually Work

1. Planner Node - The Brain

The Planner doesn't write SQL; it decides what to do next.
Based on the user request and the current state, it creates a step-by-step plan:

• "Query the production table"
• "Aggregate results by month"
• "Compare forecasted vs actual values"
• "The data is sufficient, write the report"

This transforms analytics from a one-shot prompt into a deliberate reasoning loop.

2. Executor Node - The Hands

The Executor takes the generated SQL and runs it against Snowflake.
And as expected, SQL sometimes fails - syntax errors, missing columns, or Snowflake-specific issues.

3. Query Fixer Node - The Self-Healing Mechanism

When a query fails, the system doesn't crash.
A conditional router detects the error and sends the failed SQL and error message to a Query Fixer Agent. This agent analyzes what went wrong, rewrites the query, and retries execution.
To prevent the system from getting stuck in an infinite retry loop, each query has a maximum retry limit. If the limit is reached, the failure is surfaced to the Reviewer Agent and reflected transparently in the final report.

Key insight: Reliability comes from bounded feedback loops - not perfect prompts.

Making the System Adaptable: Dynamic Configuration with YAML

To support multiple analytics use cases such as financial comparisons, KPI tracking, and model evaluations, I avoided hard-coding prompts or schemas.
Instead, the system is driven by dynamic YAML configuration files, stored in Azure Blob Storage. Each use case defines its own:

• Table schemas
• SQL templates
• System prompts for each agent
• Report structure and tone

use_case_name: financial_comparison
prompts:
  planner_sys_node: |
    You are an expert financial analyst. Your task is to plan ...
  report_writer_node: |
    Summarize the findings in a clear and professional tone ...

# ... other parameters

This design allows the system to support new use cases without changing the code or graph structure, only the configuration changes. As a result, the same multi-agent architecture can adapt to different business domains with minimal effort.

Deployment & Azure Infrastructure

The system is fully deployed on Azure using a cloud-native, scalable setup:

• Azure Container Registry (ACR): Stores versioned Docker images for the application.
• Azure Container Apps: Hosts the FastAPI service and LangGraph runtime, with automatic scaling and scale-to-zero for cost efficiency.
• Azure Queue Storage: Enables asynchronous, queue-based processing so multiple report requests can be handled in parallel.
• Azure Blob Storage: Store (YAML configuration files, Generated reports and summaries (PDFs), Logs)

Once a report is generated, the system automatically emails the user, providing a notification along with a summary of the findings and a link to the final PDF.

Results & Impact

The impact of the system was immediate:

• Speed: Reports that previously took hours of manual work now generate in minutes.
• Accessibility: Non-technical stakeholders can now get a comprehensive analysis without needing to write SQL queries, create visualizations, or interpret raw data. The system abstracts all technical complexity, democratizing access to data insights.
• Accuracy: SQL errors are auto-corrected, retries are bounded, and the Reviewer Agent ensures alignment between numbers and narrative.
• Scalability: Queue-based processing and container scaling allow the system to handle spikes in demand efficiently.
• Usability: Stakeholders receive clean, professional PDFs directly in their inbox, no dashboards or tools required.

Disclaimer

This project relies on AI models that can occasionally produce incomplete, inaccurate, or outdated information. All outputs (including SQL queries, metrics, and narrative explanations) should be treated as decision support, not as a single source of truth. For any critical, financial, regulatory, or high-impact decisions, results must be independently validated and reviewed by qualified humans before being acted upon.

Conclusion

Building LangGraph-Insights has demonstrated that the true potential of Generative AI lies not just in text generation, but in intelligent orchestration. By moving beyond simple prompts to a robust, multi-agent architecture; we can solve complex, multi-step business problems with a level of reliability, and autonomy that was previously unattainable.

This system proves that with the right design that combines specialized agents, shared state, and self-correction mechanisms, we can bridge the gap between raw data and actionable business intelligence. As these autonomous systems continue to evolve, the focus will shift from simply querying data to enabling deeper, more strategic decision-making across the enterprise.