--- title: "What Is SQL Intelligence?" url: "https://atlan.com/know/ai-agent/data-for-ai/what-is-sql-intelligence/" description: "SQL intelligence turns SQL query history into governed business-question context for AI agents, distinct from and upstream of text-to-SQL generation." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-08-11" updated: "2026-08-11T00:00:00.000Z" --- --- SQL Intelligence is Atlan's name for a Context Agent that reads your SQL query history and lineage graph, then reverse-engineers the business questions, joins, and filters your team has actually been asking for years, turning that history into governed, reusable context. It already runs at production scale: Atlan has logged [more than 35,500 SQL intelligence enrichments across 50-plus enterprises](https://atlan.com/know/context-layer-roi/). It goes the opposite direction of text-to-SQL, which turns a question into a query; this turns query history into context other agents can trust. --- Most conversations about "AI and SQL" focus on getting a model to write a correct query from a question. SQL Intelligence works the other way. It treats years of queries a team has already run as a record of institutional knowledge nobody wrote down, and turns that record into something an agent can be evaluated against before it ships. - **Reads what's already there.** Warehouse query logs and the lineage graph, not user session data or manual documentation someone has to maintain. - **Names the pattern, not just the query.** Recurring joins, frequent filters, and the business question behind them get registered as one structured entry. - **Feeds evaluation, not just discovery.** The resulting library becomes the material an agent gets simulated against before anyone trusts its answers. - **Complements text-to-SQL, doesn't replace it.** One supplies context; the other generates the query. Conflating the two is a common reason teams misdiagnose why an agent keeps guessing wrong. Below: what SQL Intelligence actually is, whether query history is really an underused source of agent context, how the mechanism works step by step, how it differs from text-to-SQL, when a team is ready for it, and how Atlan built it. | Field | Detail | |---|---| | What it is | A Context Agent that reverse-engineers business questions, joins, and filters from SQL query history | | Key benefit | Turns undocumented "how this table actually gets queried" knowledge into governed, reusable context | | Best for | Teams with query history and lineage already in place whose agents still answer business questions incorrectly | | Setup | No new tooling to stand up; runs on [existing connected warehouse query history](https://docs.atlan.com/apps/connectors/data-warehouses/snowflake/how-tos/mine-snowflake), provided retention and lineage are already in place | | Core components | Query history, lineage graph, business-question library, agent evaluation set | --- ## What is SQL Intelligence? A [Context Agent](https://docs.atlan.com/product/capabilities/governance/context-agents-studio/concepts/agents) workflow reads an asset's query history and lineage graph to reverse-engineer the business questions actually asked of it. Atlan calls this SQL Intelligence. It surfaces which tables get joined most often, which filters recur, which business questions the asset keeps answering, and which foreign-key relationships actually get used rather than just declared in a schema. It requires tables and views to have associated query history from connected data warehouse sources, so it works on usage, not just schema design. One disambiguation matters early. Searches for "SQL intelligence in SQL Server" or "in DBMS" usually land on a related but different concept: [Intelligent Query Processing](https://learn.microsoft.com/en-us/sql/relational-databases/performance/intelligent-query-processing-details?view=sql-server-ver17), Microsoft's own term for a database-performance feature that speeds up how SQL Server executes a query, nothing to do with reverse-engineering business context. A reader here for SQL Server or DBMS performance tuning wants that Microsoft Learn page, not this one. What SQL Intelligence outputs isn't a report someone reads once. Each pattern gets registered as a governed, linked asset, discoverable the same way [types of metadata for AI agents](https://atlan.com/know/ai-agent/data-for-ai/types-of-metadata-for-ai-agents/) already are, and reusable across [enterprise search](https://atlan.com/know/ai-agent/data-for-ai/enterprise-search-with-ai/), data quality checks, and agent evaluation. For a team already invested in [metadata management for AI](https://atlan.com/know/ai-agent/data-for-ai/metadata-management-for-ai/), the gap this closes isn't more documentation. It's the tribal knowledge documentation never captured. ### How SQL Intelligence differs from a data catalog's existing lineage A catalog's lineage graph shows which tables are structurally connected. SQL Intelligence adds a behavioral layer on top: which of those connections people and agents actually use, and for what business question. A join can exist in the schema and never appear in a real query; SQL Intelligence surfaces that difference. ### What "query history" means as an input The input is warehouse query logs, the SQL statements a connected Snowflake, BigQuery, or Databricks source has actually executed, not user click-stream or session data. Query logs capture how data gets used at the SQL layer, closer to how an [agent context graph](https://atlan.com/know/ai-agent/agent-context-graph/) needs to reason about a table than a product-analytics event stream would be. --- ## Is query history actually an underused source of AI context? Before query history had a name for this use, teams were already hand-rolling crude versions of it, and the broader industry is now converging on the same idea. On developer forums and internal wikis, a recognizable pattern shows up before any vendor named it: teams hand-building a join registry and anti-pattern list from warehouse logs, specifically to stop AI agents from hallucinating column names and join paths. Nobody called it "SQL Intelligence." That gap between what a system stores and what people actually know is the same one [systems of record versus data knowledge](https://atlan.com/know/ai-agent/data-for-ai/systems-of-record-data-knowledge/) draws out more generally. Third-party evidence says the mechanism is real, not just a framing exercise. When a data-platform vendor layered query-history context onto Snowflake metadata for a May 2026 release, Miro ran the benchmark itself: an analytics agent went from [answering about half its benchmark questions correctly to roughly 90 percent](https://venturebeat.com/data/sql-query-logs-hold-the-context-ai-agents-need-to-stop-hallucinating-joins), according to Ronald Angel, Product Manager, Data Platform, at Miro, as VentureBeat reported. That's Miro's benchmark result, not the vendor's marketing copy, and it's a large accuracy jump to trace to a single input. Academic research backs the same direction independently of any product launch. [One 2026 paper on retrieval-based memory for text-to-SQL agents](https://arxiv.org/pdf/2606.00547) treats historical query patterns explicitly as an active research direction for agent memory, not an idea invented to sell software. Separately, the [Spider 2.0 enterprise text-to-SQL benchmark](https://arxiv.org/pdf/2411.07763) found that real-world text-to-SQL success depends on searching through exactly this kind of contextual material, metadata, dialect documentation, and prior usage, not just parsing the natural-language question. Query logs sitting unused in a warehouse aren't a documentation gap. They're institutional memory nobody has read back out yet. ### The failure mode this fixes, agents hallucinating joins Without validated query history, an agent guesses at which tables join and on what key, and a plausible-looking guess is worse than an obvious error because nobody catches it before the wrong number ships in an answer. That's the specific failure [RAG accuracy problems](https://atlan.com/know/rag-accuracy-problems/) trace back to just as often for structured data as for retrieved documents. --- ## How does SQL Intelligence work? SQL Intelligence runs as a four-step pipeline inside Context Engineering Studio, from raw query logs to a governed business-question library agents can be evaluated against. ### Step 1: Reading query history and the lineage graph **Query pattern extraction** starts here. SQL Intelligence pulls warehouse query logs for a connected asset and cross-references them against the existing [lineage graph](https://atlan.com/know/ai-agent/data-for-ai/data-lineage-for-ai/), so a join pattern gets checked against a relationship already known to be real, the same mechanism a [semantic search versus keyword search](https://atlan.com/know/semantic-search-vs-keyword-search/) comparison already points to as an example of business questions getting reverse-engineered from query history. ### Step 2: Reverse-engineering business questions, joins, and filters **Join validation** and **business-question tagging** happen together. Recurring filter conditions and join pairs get grouped, then labeled with the natural-language business question they were actually answering, not just the SQL statement that answered it. ### Step 3: Structuring the output into a governed, linked library Each labeled pattern becomes a linked asset, part of the same [systems of semantics](https://atlan.com/know/ai-agent/data-for-ai/systems-of-semantics/) an organization is already building and the same kind of corpus a [RAG architecture](https://atlan.com/know/rag-architecture/) retrieves from at runtime, rather than a one-off spreadsheet export that goes stale the day it's downloaded. ### Step 4: Feeding the library into agent evaluation The finished library becomes eval material inside Context Engineering Studio. When a team simulates an agent before shipping it, the SQL Intelligence library is what that simulation checks the agent's answers against, the same principle behind [AI agent memory mechanics](https://atlan.com/know/ai-agent/ai-agent-memory-mechanics/) more broadly. How SQL Intelligence moves from query logs to a tested agent Query history + lineage graph warehouse logs Pattern extraction joins, filters, business questions Governed library linked, structured reusable assets Agent eval simulate before ship Text-to-SQL runs the opposite direction: a natural-language question goes in, a generated query comes out. SQL Intelligence is the upstream context supply; text-to-SQL is the downstream query-generation step. SQL Intelligence's four-step pipeline: from raw query logs to a business-question library an agent gets tested against. | Aspect | SQL Intelligence | Text-to-SQL | |---|---|---| | Direction | Query history to structured context | Natural language to generated SQL | | Input | Historical query logs, lineage graph | A user's natural-language question | | Output | Governed business-question library | A single executable query | | Role | Upstream context supply | Downstream query generation | | Failure mode it fixes | Hallucinated joins and filters from missing context | Wrong SQL from ambiguous natural-language intent | For the query-generation side of this same problem, turning a natural-language question into working SQL, see [text-to-SQL for enterprise](https://atlan.com/know/ai-agent/data-for-ai/text-to-sql-for-enterprise/). By definition, a pipeline that only reads history and never feeds evaluation is a one-off audit, not a compounding asset. Step four is what turns SQL Intelligence into the latter: the library has to get used against a live agent, not just filed away. --- The 5x accuracy factor, explained See how Atlan's AI Labs measured the accuracy gap between agents with and without governed context. Get the 5x Accuracy Ebook --- ## How is SQL Intelligence different from text-to-SQL? SQL Intelligence and text-to-SQL solve opposite-direction problems that are easy to conflate because both involve SQL and AI. The distinction that matters in practice: SQL Intelligence is upstream infrastructure that makes [text-to-SQL for enterprise](https://atlan.com/know/ai-agent/data-for-ai/text-to-sql-for-enterprise/) more accurate. It's the context supply, not the query-generation step. A team can build excellent text-to-SQL generation, grounded against a [talk-to-data agent blueprint](https://atlan.com/know/ai-agent/talk-to-data-agent-blueprint/), and still get wrong answers if the underlying context, which joins are valid, which filters are standard practice, was never captured anywhere. That's the specific gap SQL Intelligence closes. Governed joins and filters function like an implicit [data contract for AI](https://atlan.com/know/ai-agent/data-for-ai/data-contracts-for-ai/) on how an asset should be queried. SQL Intelligence doesn't write SQL. It supplies the context that keeps whatever writes the SQL from guessing. Atlan's SQL Intelligence Agent output is one of the inputs a [Cortex Analyst-style text-to-SQL setup](https://atlan.com/know/snowflake/cortex-analyst-vs-text-to-sql/) or a talk-to-data agent's evaluation set draws from, not a competing feature racing it for the same job. --- ## When does a team need SQL Intelligence? Teams that have descriptions and lineage in place but still watch agents answer business questions incorrectly are the clearest signal that query-history context is the missing layer. The tell is specific: [types of metadata for AI agents](https://atlan.com/know/ai-agent/data-for-ai/types-of-metadata-for-ai-agents/) are filled in, glossary terms exist, and agents still hallucinate a join or miss the question someone meant to ask. That profile looks like what Atlan's context-maturity framing calls an L2 (AI-Ready Data) gap: descriptions and lineage exist, but the layer that explains how an asset is actually used does not. The prerequisite is equally specific: associated query history from connected data warehouse sources. A team with no query-log retention isn't a fit yet, no matter how mature its glossary or its approach to [structured versus unstructured data for AI](https://atlan.com/know/ai-agent/data-for-ai/structured-vs-unstructured-data-for-ai/) already is. | Criterion | Why it matters | What to look for | |---|---|---| | Query history retention | No history means no signal to mine | Enough retained warehouse query logs to surface recurring patterns | | Lineage graph maturity | Joins get validated against real relationships | Lineage already mapped for target assets | | Agent evaluation workflow | The library needs a consumer | A simulate-before-ship or eval process in place | | Business-question volume | Enrichment value scales with query diversity | High-traffic assets with varied query patterns | | Governance ownership | Output needs a steward, not just a generator | Clear owner for reviewing surfaced context | A team missing even one row above isn't disqualified, but it's tackling SQL Intelligence a step early. The [how to implement an enterprise context layer](https://atlan.com/know/how-to/implement-enterprise-context-layer-for-ai/) guide covers what to build first if query history retention itself is the gap, the same starting point covered in [how to build a knowledge base for AI agents](https://atlan.com/know/ai-agent/data-for-ai/how-to-build-knowledge-base-for-ai-agents/). --- Not sure how big your context gap is? Run the calculator that scores the distance between cataloged metadata and context an agent can actually act on. Run the Context Gap Calculator --- ## How Atlan approaches SQL Intelligence Historical business questions sit in query logs, undocumented, and get lost every time the person who wrote them changes teams or leaves. An agent built on clean-looking [data lineage](https://atlan.com/know/ai-agent/data-for-ai/data-lineage-for-ai/) and a well-maintained glossary can still fail in production, because the tribal knowledge of how a table actually gets queried was never written down anywhere a system could read back. Atlan's SQL Intelligence Agent runs inside Context Engineering Studio, reading query history and the lineage graph to reverse-engineer a structured library of business questions, joins, and filters, then registering it as governed, linked context and feeding it into agent evaluation, the same capability [what are enterprise skills](https://atlan.com/know/what-are-enterprise-skills/) documents directly. Varun Banka, Atlan's co-founder, framed the stakes at Activate 2026: "Your historical business questions are the biggest IP of companies right now." The mechanism isn't theoretical: Atlan's [context-layer ROI benchmark](https://atlan.com/know/context-layer-roi/) already counts more than 35,500 SQL intelligence enrichments across 50-plus enterprises, part of a broader body of work Atlan reports [improved AI query accuracy by 38 percent](https://atlan.com/know/enhanced-metadata-improves-query-accuracy/) and [lifted talk-to-data SQL accuracy 3x](https://atlan.com/know/snowflake-intelligence-atlan-partner-talk-to-data/) in a Snowflake Intelligence benchmark. Engine, an Activate 2026 launch customer, is one example. Adrianna Clark, Senior Data Governance Analyst at Engine: "It was already pulling out our most used assets, very efficient. The ability to take some of our most popular business questions and turn them into context — that enabled trust." Context Agents bootstrapped Engine's most-used assets in days, not months, a result the [MCP layer](https://atlan.com/know/mcp-delivers-business-context/) carries forward to every agent querying those assets afterward, not just the one that ran the enrichment. --- See Context Agents in action Watch how SQL Intelligence and other Context Agents turn raw metadata into governed, agent-ready context. Watch the Demo Series --- ## Query history is a compounding asset, not a cleanup project Turning query history into governed business-question context is a real, contested capability, and SQL Intelligence is Atlan's name for it, the same idea the broader industry is converging on under different labels. Atlan's version has a real number behind it, 35,500-plus enrichments across 50-plus enterprises, and a complementary relationship to text-to-SQL, not a competing one. The same failure recurs anywhere retrieval feeds an agent without validated context behind it: a [RAG architecture](https://atlan.com/know/rag-architecture/), a [hybrid RAG](https://atlan.com/know/hybrid-rag/) setup, [conversational search for enterprise data](https://atlan.com/know/conversational-search-enterprise-data/), or [semantic search](https://atlan.com/know/ai-agent/data-for-ai/semantic-search-implementation/) built on [top vector databases](https://atlan.com/know/top-vector-databases-enterprise-ai/) all run into it. Functionally, the SQL Intelligence library is a form of [agent memory](https://atlan.com/know/what-is-agent-memory/), the role a broader [agent memory layer built on a data catalog](https://atlan.com/know/agent-memory-layer-data-catalog/) plays for other workloads, and a downstream [internal knowledge assistant](https://atlan.com/know/ai-agent/data-for-ai/what-is-an-internal-knowledge-assistant/) can be built directly on top of it. Delivery is a separate question Atlan's [MCP layer](https://atlan.com/know/mcp-delivers-business-context/) answers, [why MCP matters for AI agents](https://atlan.com/know/mcp/why-mcp-matters-for-ai-agents/), an [MCP-connected data catalog](https://atlan.com/know/mcp-connected-data-catalog/), and [MCP for data lineage](https://atlan.com/know/mcp/mcp-for-data-lineage/), all part of the broader [enterprise context layer](https://atlan.com/know/what-is-the-enterprise-context-layer/) a team is building toward. As agent evaluation becomes standard practice, the context a team mines from its own query history becomes a compounding asset, not a one-time cleanup project. Start with [how to build an AI agent harness](https://atlan.com/know/how-to-build-ai-agent-harness/) to see where SQL Intelligence's output actually gets tested. See what governed context is worth Run the calculator that turns enrichments like SQL Intelligence's into a dollar figure for your own warehouse. Run the ROI Calculator --- ## FAQs about SQL intelligence ### 1. What is SQL intelligence, in one sentence? SQL intelligence is the practice of mining SQL query history to reverse-engineer the business questions, joins, and filters a data asset has actually been used to answer, then turning that into governed, reusable context. Atlan runs this as a Context Agent called SQL Intelligence, with more than 35,500 enrichments logged across 50-plus enterprises. ### 2. What is SQL intelligence and how does it work? SQL intelligence works by reading an asset's query history alongside its lineage graph, surfacing recurring joins, filter conditions, and business questions, then structuring that pattern into a linked, governed asset. The resulting library becomes material an AI agent gets evaluated against before it ships, not a one-time report. ### 3. Is SQL intelligence the same as SQL intelligence in SQL Server or DBMS? No. A search for "SQL intelligence in SQL Server" usually surfaces Intelligent Query Processing, Microsoft's own term for a database-performance feature that speeds up query execution, not a documented Microsoft use of the phrase "SQL intelligence" itself. The sense covered on this page is unrelated either way: it's about mining query history for business context, not tuning how fast a database runs a query. ### 4. How is SQL Intelligence different from text-to-SQL? SQL Intelligence and text-to-SQL solve opposite-direction problems. SQL Intelligence turns historical query patterns into structured business context, upstream infrastructure. Text-to-SQL turns a natural-language question into a generated query, downstream generation. The first makes the second more accurate; neither replaces the other. ### 5. Does SQL Intelligence require query history to work? Yes. SQL Intelligence requires tables and views to have associated query history from connected data warehouse sources, since it works by mining patterns from queries that have actually run. A team with no query-log retention on a given asset doesn't have the input this capability needs yet. ### 6. What is a SQL intelligence example? A frequently-joined-tables pattern is a typical example. SQL Intelligence notices a revenue table gets joined with a regions table in nearly every query that touches it, tags the business question behind that pattern as "revenue by region," and registers the validated join as governed context other agents can reuse. ### 7. Is SQL still relevant if AI can write it? SQL is still relevant, and arguably more load-bearing than before. An AI writing a query still needs the query history behind that table to know which joins are valid and which business question is actually being asked, the layer SQL intelligence supplies. AI generating SQL faster just raises the cost of getting that context wrong. --- ## Sources 1. Intelligent Query Processing. Microsoft Learn, 2026. https://learn.microsoft.com/en-us/sql/relational-databases/performance/intelligent-query-processing-details?view=sql-server-ver17 2. SQL Query Logs Hold the Context AI Agents Need to Stop Hallucinating Joins. VentureBeat, 2026. https://venturebeat.com/data/sql-query-logs-hold-the-context-ai-agents-need-to-stop-hallucinating-joins 3. Learning to Retrieve: Dual-Level Long-Term Memory for Text-to-SQL Agents. arXiv, 2026. https://arxiv.org/pdf/2606.00547 4. Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows. arXiv, 2024. https://arxiv.org/pdf/2411.07763 5. Mine Snowflake. Atlan Documentation, 2026. https://docs.atlan.com/apps/connectors/data-warehouses/snowflake/how-tos/mine-snowflake