Generating SQL with an LLM is easy. Building a system that knows when the SQL is wrong is the real engineering problem.
Most teams do not have a data-access problem.
They have a translation problem.
A stakeholder has a question:
“Which customer segment had the highest revenue growth last quarter?”
The answer exists somewhere in the warehouse. But getting it often means opening a ticket, messaging an analyst, waiting for context, clarifying metric definitions, and then waiting again for the query.
Meanwhile, data teams spend a surprising amount of time answering variations of the same questions.
That is the problem I have been thinking about — and the reason I started building DataTalk.
DataTalk is an AI-powered data agent that lets people ask questions about their data in plain English. It retrieves the relevant schema context, generates SQL, validates and executes it, and returns an answer.
But this is not a story about replacing SQL with a chatbot.
It is a story about what it takes to make natural-language data access more reliable, observable, and safe.
Over the next seven days, I will build DataTalk in public and share the engineering decisions behind it: the data foundation, agent workflow, schema retrieval, safety controls, evaluation framework, and production considerations.
The deceptively simple idea
At first glance, text-to-SQL seems straightforward:
A user asks a question in natural language.
An LLM converts that question into SQL.
The database runs the SQL.
The user gets an answer in natural language.
In a demo, that can work impressively well.
But real data systems are not demo environments.
A real warehouse has ambiguous table names, undocumented columns, inconsistent metrics, historical models, sensitive data, permission boundaries, and business definitions that are rarely obvious from a schema alone.
Consider a question like:
“Show me our best-performing customers.”
What does best-performing mean?
- Highest total revenue?
- Highest revenue growth?
- Highest retention?
- Highest margin?
- Highest activity in the last 30 days?
- Highest lifetime value?
The SQL may run successfully and still produce the wrong answer.
That is the central challenge behind DataTalk: SQL execution is not the same as data correctness.
What DataTalk is
DataTalk is an AI agent designed to help users query a database in plain English while keeping the data workflow structured and controlled.
At a high level, the system needs to do more than produce a SQL string. It needs to:
- Understand what the user is trying to ask
- Retrieve the relevant tables, columns, metric definitions, and schema context
- Generate SQL appropriate for the target warehouse
- Validate the query before execution
- Run the query within defined permissions and limits
- Interpret execution errors
- Retry or repair SQL when a safe correction is possible
- Ask for human approval when an operation is risky or ambiguous
- Return a result with enough context for the user to trust it
The architecture combines data engineering, AI engineering, and application evaluation — not just prompt engineering. The project roadmap covers the data foundation, dbt and warehouse design, a LangGraph agent workflow, self-healing SQL, schema RAG, evaluations, and production monitoring.
The seven-day build
This is the structure of the series:
- Day 1: Problem and data foundation. What has to be true about the data before an AI agent can query it reliably?
- Day 2: Pipelines and schema design. How do dbt models, naming, documentation, and semantic design affect text-to-SQL?
- Day 3: LangGraph agent architecture. Why use a graph-based workflow instead of a single LLM call?
- Day 4: Self-healing SQL and approval gates. How can an agent repair safe failures while knowing when to stop?
- Day 5: RAG for schema retrieval. How does the agent find the right tables and columns without receiving the entire warehouse schema?
- Day 6: Evaluation framework. How do we evaluate SQL correctness, execution success, safety, and semantic accuracy?
- Day 7: Production and retrospective. What does continuous evaluation, monitoring, and iteration look like after the prototype?
Follow the build
DataTalk is an experiment in connecting data engineering discipline with agentic AI workflows.
If you are building AI agents, working on data platforms, experimenting with LangGraph, or trying to make LLM applications more reliable, I hope this series gives you useful ideas — and useful warnings.
The first post starts with the least glamorous and most important layer: the data foundation.
Because before an AI agent can talk to your database, your database has to be ready to talk back.
Day 1: Why I Built an AI That Talks to My Database — and What It Needed Before Any LLM Could Help.
I’ll add the GitHub repository and individual post links here as the series goes live.
Top comments (1)
you need to think about guard rails and prompt injection , one of the critical risks is misusing this to delete some thing in database , may be entire data and this has happened for many big names in production