Why Enterprise Data Intelligence Must Evolve from Text‑to‑SQL to Data Agents

Over the past two years, companies with sizable data have converged on a common goal: enable business users to obtain needed data without waiting for analysts. Early attempts varied—BI dashboards, SQL‑assist tools, and Text‑to‑SQL—but they all culminated in a more complete "Data Agent" architecture.

Four Generations of Enterprise Data Intelligence

First generation: BI dashboards – designers pre‑define visualizations; users can view but cannot ask new questions.

Second generation: SQL‑assist tools – provide syntax hints, templates, and autocomplete to speed analysts, yet data access remains limited to those who can write SQL.

Third generation: Text‑to‑SQL – LLMs make it appear that business users can ask questions directly, but real‑world accuracy drops dramatically (from >91% on the Spider 2.0 benchmark to ~21% in production) because of large schema, divergent definitions, and field‑level ambiguities.

Fourth generation: Data Agent – goes beyond generating a single SQL statement, offering a closed loop of understanding, retrieval, computation, verification, and explanation, and continuously improves through evaluation feedback.

Each generational leap solves the question of "who should own data‑access power" rather than merely improving model intelligence.

What a Data Agent Actually Does

A full Data Agent interaction performs six tasks: understand the request, understand the business context, understand the data schema, execute tools, verify results, and explain outcomes. These tasks map to five relatively independent engineering disciplines:

Context : structuring user utterances, dialogue history, and task goals into LLM‑friendly prompts.

Knowledge : turning table schemas, business definitions, and enumeration mappings into searchable, auditable assets.

Skill : exposing deterministic capabilities such as SQL execution, statistical computation, and sandboxed code via function calling or MCP protocols.

Memory : short‑term memory for multi‑turn clarification and long‑term memory for recurring questions and corrected SQL.

Evaluation Loop : converting each error into actionable updates to knowledge, rules, or test sets, driving continuous improvement.

Why "Finding the Right Table" Is Harder Than Writing SQL

Enterprise warehouses often contain the same metric across multiple layers (ADS, DWS, DWD) and across horizontal versus vertical tables. Selecting the wrong table yields seemingly correct numbers with incorrect business definitions. The author estimates that about 80% of engineering effort in a production Data Agent is spent on reliable table selection.

The proven approach is a "coarse‑to‑fine" retrieval pipeline: first recall candidate tables via lightweight indexes, then rank them by semantic match and field coverage, apply tie‑breaking rules (prefer higher‑level aggregation, prefer business‑specific tables), and finally verify each chosen field’s existence.

Uber’s internal QueryGPT follows a similar pattern—intent classification, table selection with user confirmation, and column pruning—reducing average SQL authoring time by 70% after more than 20 iterative versions. A 2026 Gaode case study reports blind‑test accuracy rising from ~40% to >90% after systematic knowledge completion.

In large‑scale schemas, no team can expect a model to understand every table instantly; a staged narrowing of candidates is essentially the only viable engineering path.

Enterprise Needs Knowledge More Than AI

Beyond table selection, divergent business definitions (e.g., differing “customer acquisition cost” calculations) create hidden challenges. The shift from "Prompt Engineering" to "Knowledge Engineering" reflects the realization that a well‑structured, versioned knowledge base (semantic layer) is the true performance driver.

Open benchmarks show that without a semantic layer, LLM‑generated SQL achieves ~40% accuracy; with a semantic layer, accuracy exceeds 80%. However, semantic layers only answer pre‑modeled questions; novel metrics still require manual knowledge addition.

Knowledge Engineering solves the problem of turning undocumented corporate tacit knowledge into verifiable, traceable text.

Think, Don’t Just Calculate

When users ask “Why did acquisition cost rise this month?”, the system must both compute precise numbers and understand intent. Relying solely on LLM‑generated calculations leads to hallucinated attributions. The recommended architecture separates thinking (LLM) from execution (deterministic tools), using protocols like Tool Calling or MCP to invoke trusted calculators.

For complex or long‑tail analyses, the system falls back to generating code executed in isolated sandboxes (e.g., Firecracker microVMs) with strict time‑outs and memory limits, feeding any errors back to the LLM for debugging.

Why Most Agents Stall After Launch

Context, Knowledge, Skill, and Memory determine first‑day accuracy; the Evaluation Loop determines long‑term improvement. Many deployments stop evolving because knowledge bases aren’t refreshed, rules aren’t updated, and feedback remains manual, leading to stagnant accuracy after six months.

A robust loop requires: (1) trustworthy evaluation sets, (2) semantic rather than string‑based result comparison, and (3) error attribution that maps failures to knowledge gaps, rule deficiencies, or test‑set issues. Early errors often stem from “model doesn’t know” rather than “model can’t compute,” so enriching the knowledge base yields larger gains than swapping for a stronger model.

Evaluation Loop is the growth engine; without it, an agent’s accuracy plateaus on day one.

Future Directions for Data Agents

The weakest discipline today is Memory. Strengthening it means building a continuous capability chain: remembering prior queries, recognizing trends, and proactively asking clarification questions.

When Memory, Planner, and Reflection mature, Data Agents will evolve from “ask‑answer” tools into proactive data colleagues—suggesting analysis angles, recalling past interactions, and double‑checking conclusions before presenting them.

In this vision, the agent is not merely a faster SQL robot but an tireless data employee that collaborates with teams, continuously learns, and bridges the gap between raw data and business insight.

Conclusion

Whether a Data Agent succeeds does not depend on the LLM model but on how well the five disciplines—Context, Knowledge, Skill, Memory, and Evaluation Loop—are implemented. Model capabilities will improve, but without solid engineering in these areas, enterprise data intelligence cannot reliably scale.