Skip to content

Data Story AI: From Static Reports to Dynamic Conversations

Charts can show what changed without explaining why the change matters or what to investigate next. I have seen that gap slow conversations between data teams and business teams.

I built Data Story AI to test one workflow: turn a plain-language question into a DuckDB query, a chart, and a written summary. This post explains the architecture and its safeguards. The generated story is a starting point for analysis, not an automatic business decision.

Navigate this post

The Problem: Data Without Context

A chart can report that revenue dropped. It cannot establish the cause or choose the right response without more evidence. That interpretation still requires domain context and review.

---
title: "Traditional Data-to-Decision Bottleneck"
---
flowchart TB
    accTitle: Traditional data-to-decision bottleneck
    accDescr: Raw data becomes charts without enough context, leaving people to analyze it manually and delaying a decision.
    A["Raw Data"] --> B["Charts & Tables"]
    B --> C["Unclear Context"]
    C --> D["Manual Analysis"]
    D --> E["Delayed Decisions"]

When every follow-up question needs a new report, analysis queues can slow an investigation. Automation can shorten the first query-and-chart cycle while keeping a person responsible for interpretation.

The Solution: Automated Data Stories

A data story combines measured facts, relevant context, and a visual explanation. It should make the evidence and uncertainty easier to review, not hide them behind a recommendation.

---
title: "Anatomy of a Complete Data Story"
---
flowchart TB
    accTitle: Anatomy of a complete data story
    accDescr: A useful data story combines quantitative facts, narrative context, and clear visuals to produce an actionable insight.
    A["Data Story"] --> B["Facts: Quantitative Data"]
    A --> C["Context: Narrative Synthesis"]
    A --> D["Clarity: Visual Breakdowns"]
    B --> E["Revenue = $2M"]
    C --> E
    D --> E
    E --> F["Actionable Insight:<br/>Prioritize Mobile Experience"]

Data Story AI automates parts of this workflow: it accepts a plain-language question, generates SQL, runs the query, and drafts a chart and summary. A reviewer still needs to validate the query, the data, and any causal claim.

How Data Story AI Works

The user enters a business question in the chat interface. Data Story AI generates a SQL query, runs it against a local data store, and produces a draft narrative and chart. “Generated” does not mean optimal or safe, so the database connection is read-only and the result should be checked.

---
title: "Workflow Comparison"
---
flowchart TB
    accTitle: Traditional and Data Story AI workflows
    accDescr: The traditional path queues manual analysis and exports, while Data Story AI generates a query, runs it, and creates a chart and narrative.
    subgraph S1["Traditional BI Workflow"]
        A1["Business Question"] --> B1["Queue Analyst Request"]
        B1 --> C1["Manual SQL Creation"]
        C1 --> D1["Static CSV Export"]
        D1 --> E1["Delayed Insight"]
    end

    subgraph S2["Data Story AI Workflow"]
        A2["Business Question"] --> B2["LangChain SQL Agent"]
        B2 --> C2["Automated SQL Generation"]
        C2 --> D2["DuckDB Execution"]
        D2 --> E2["Interactive Narrative & Visuals"]
    end

What the automation changes

The tool can return an initial query and visualization without waiting for a manually formatted report. End-to-end time still depends on the model provider, query complexity, data size, and human review.

Try Data Story AI Yourself

Access the live environment directly: Try the live Data Story AI demo without requiring account setup or software installation.

Sample Prompts to Test
  • "What are our top-selling product categories?"
  • "Show me monthly sales trends for 2023."
  • "Which states generate the highest total revenue?"

Under the Hood: Modern AI Stack

Technical Architecture

The core architecture uses a modular design to separate interface rendering, query formulation, execution, and narrative synthesis:

---
title: "Data Story AI System Architecture"
---
flowchart TB
    accTitle: Data Story AI system architecture
    accDescr: A Streamlit interface sends a question through an agent to DuckDB, then language and chart components turn the results into a data story.
    A["User Query"] --> B["Streamlit Frontend"]
    B --> C["LangChain Agent"]
    C --> D["LLM SQL Generator"]
    D --> E["DuckDB Analytics Engine"]
    E --> F["Dataset Results"]
    F --> G["LLM Narrative Generator"]
    F --> H["Plotly Chart Engine"]
    G --> I["Executive Summary"]
    H --> J["Interactive Visuals"]
    I --> K["Rendered Data Story"]
    J --> K

Core Technology

The architecture relies on five specialized components:

  • Streamlit for real-time web UI rendering
  • LangChain for schema retrieval and SQL generation
  • DuckDB for fast in-process analytical query processing
  • Plotly for responsive client-side chart generation
  • Large Language Models for text-based executive summaries
Python
import duckdb

def execute_analytical_query(db_path: str, query_sql: str):
    """Execute generated SQL query safely against DuckDB database."""
    connection = duckdb.connect(database=db_path, read_only=True)
    results = connection.execute(query_sql).df()
    connection.close()
    return results

The read-only connection prevents generated SQL from changing the database. It does not prevent an expensive query, a logically wrong join, or disclosure through a result sent to another component. Add query timeouts, row limits, schema allowlists, and output review before using the pattern with sensitive or production data.

Privacy-First by Design

Data security boundary

DuckDB executes the SQL locally, but the configured language-model service may receive the question, schema details, generated SQL, and selected query results for narrative generation. Review that provider's retention terms and minimize the data sent. Do not upload sensitive data to the public demo.

  • Local query execution: DuckDB runs the generated SQL in the application session.
  • External model boundary: Prompt and result data may cross that boundary, depending on configuration.
  • Session cleanup: Application cleanup does not control logs or retention at an external provider.
---
title: "Data Story Request Sequence"
---
sequenceDiagram
    accTitle: Data Story request sequence
    accDescr: A user question moves from Streamlit through an agent and DuckDB, then returns as a generated narrative and chart.
    autonumber
    participant U as User
    participant S as Streamlit Frontend
    participant L as LangChain Agent
    participant D as DuckDB Engine
    participant G as Story Generator

    U->>S: Submit business prompt
    S->>L: Pass schema & question
    L->>L: Generate validated SQL
    L->>D: Execute SQL query
    D-->>L: Return data frame
    L->>G: Synthesize narrative & charts
    G-->>S: Return formatted story
    S-->>U: Display interactive response

What Makes Data Story AI Different?

  • Natural Language
    Ask questions in plain English without writing SQL queries or navigating complex data parameters.

  • Complete Data Stories
    Receive context-rich executive summaries, recommendations, and clear visual narratives alongside data points.

  • Draft Analysis
    Generate an initial query, chart, and summary that a person can inspect and refine.

  • Conversational Exploration
    Build on prior questions dynamically to drill down into deeper business metrics and follow-up trends.

Open Source & Extensible

The codebase is open source under the MIT License on GitHub: kanad13/Data-Story-AI.

  • Modular Architecture: Extend functionality by adding new database connectors, custom chart types, or specialized LLM providers.
  • Production work remains: Add authentication, authorization, query budgets, audit logging, provider review, and tests for the target data before deployment.

Conclusion

Data Story AI demonstrates a reviewable path from a plain-language question to SQL, a chart, and a written summary. DuckDB provides a useful read-only execution boundary, while the generated query and narrative remain fallible.

For real organizational data, add access control, query limits, model-provider governance, and human validation. The tool can shorten exploration; it should not bypass the people responsible for data meaning and decisions.

References and further reading

Open the complete reference catalog

Primary Sources