--- title: "Text-to-SQL for Enterprise: Why It Fails Without a Context Layer" url: "https://atlan.com/know/ai-agent/data-for-ai/text-to-sql-for-enterprise/" description: "Text-to-SQL for enterprise returns a confident wrong answer. See dbt Labs' 2026 benchmark on semantic grounding and why a context layer closes what's left." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-07-28" updated: "2026-07-28T00:00:00.000Z" --- --- Enterprise text-to-SQL tools, dbt's Semantic Layer, [Snowflake Cortex Analyst](https://atlan.com/know/snowflake/snowflake-cortex-explained/), Databricks Genie, Looker, and Atlan's governed context layer, all promise natural-language data access. The catch: frontier models writing raw SQL against bare schema still top out at 84-90% accuracy on the questions that carry the most weight, correct syntax, wrong meaning. [dbt Labs (2026)](https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026) measured semantic-layer grounding closing that gap, Claude Sonnet 4.6 from 90.0% to 98.2%, GPT-5.3-Codex from 84.1% to 100%, while raw text-to-SQL keeps a real role for one-off, unmodeled questions. This guide covers why that gap exists and what a governed context layer adds once the semantic layer has closed its share of it. --- Atlan does not generate SQL. It sits upstream as the governed context layer these text-to-SQL engines, and [AI agents for data analytics](https://atlan.com/know/ai-agents-for-data-analytics/) more broadly, read from: certified join paths through the Enterprise Data Graph, one glossary definition per metric, column-level lineage back to source, and access policy delivered through MCP before a query is ever written. That is a different job than dbt's Semantic Layer or Snowflake Cortex Analyst, and a complementary one, not a competing one. - Metric definitions live in one governed business glossary, not scattered across dashboards and tribal knowledge - Join paths are certified through the Enterprise Data Graph instead of guessed at query time - Freshness and trust signals flag deprecated or low-confidence tables before an agent reasons over them - Schema and row access are scoped per user through MCP, before SQL generation, not validated after | Aspect | Detail | |---|---| | What it is | Natural-language input converted to SQL by an LLM, either directly against a schema or through a semantic layer | | Why it fails at enterprise scale | Frontier models guess at business meaning, not syntax; the same question can return different numbers across runs | | Key benchmark | dbt Labs (2026): semantic-layer grounding lifts accuracy from 90.0% to 98.2% (Claude Sonnet 4.6) and 84.1% to 100% (GPT-5.3-Codex) | | Best for | Board, auditor, and KPI-grade questions once governed; raw text-to-SQL still suits ad hoc, exploratory queries | | What a governed context layer adds | Certified joins, one metric definition, freshness signals, and pre-scoped access, on top of the semantic layer | The AI Context Stack See where semantic layers, knowledge graphs, and governed context each sit in the stack your text-to-SQL agent depends on. Get the Brief --- ## What is text-to-SQL, and why does it break down at enterprise scale? Text-to-SQL converts a natural-language question into a SQL query an LLM generates directly against a database schema, without a business-meaning layer translating what the question means. The failure mode is not that the SQL fails to run. According to a Spider 2.0 benchmark study (ICLR, 2025), an o1-preview agent scored 91.2% on [Spider 1.0](https://arxiv.org/abs/2411.07763), the original academic benchmark, but only 21.3% on Spider 2.0, built from real enterprise workflows. Ambiguous table names, undocumented joins, and near-duplicate columns break a skill academic benchmarks never test, the same [AI agent hallucination](https://atlan.com/know/ai-agent-hallucination/) pattern that shows up whenever a model guesses at a relationship it was never told about. Frontier models write syntactically excellent SQL; they parse the schema correctly and produce a query that executes without error. What they cannot do alone is know that "active customer" means something specific to this business, that two tables share an inconsistently named join key, or that a column marked "revenue" was deprecated last quarter. A [knowledge graph](https://atlan.com/know/what-is-a-knowledge-graph/) encoding those relationships is one way enterprises have tried to close this gap; Atlan's own [talk-to-data agent architecture](https://atlan.com/know/ai-agent/talk-to-data-agent-blueprint/) documents the fuller build sequence. ### Why "the SQL runs" isn't the same as "the SQL is right" A query that executes without error can still return a wrong number with total confidence, because syntax validation and business-logic correctness are separate problems. The model checks only whether the query is well-formed, not whether its assumptions are true. That distinction, wrong answer versus error message, is exactly the one dbt Labs uses to describe why a semantic layer changes the failure mode itself, not just the accuracy number. What separates a pilot that ships from one that stalls is not which model generates the query; it is whether anything in the system already knows what the business terms mean. --- ## How does a semantic layer change text-to-SQL accuracy? Grounding the same natural-language question in a semantic layer, rather than letting the model write raw SQL against bare tables, is the single largest accuracy lever measured to date. According to [dbt Labs (April 2026)](https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026), semantic-layer grounding lifted Claude Sonnet 4.6's accuracy from 90.0% to 98.2%, and GPT-5.3-Codex from 84.1% to 100%, in a "modeled project" configuration the researchers call the most realistic comparison for dbt users. Atlan's own [MCP server for dbt](https://atlan.com/know/mcp/mcp-server-for-dbt/) connects directly to that Semantic Layer, while the broader [semantic layer](https://atlan.com/know/semantic-layer/) category, including [semantic layers built for AI agents](https://atlan.com/know/ai-agent/semantic-layer-for-ai-agents/) specifically, encodes the same modeling discipline behind [ontology in AI](https://atlan.com/know/what-is-ontology-in-ai/): metric definitions modeled once, then reused. | Model | Text-to-SQL only | + Semantic layer grounding | Accuracy gap closed | |---|---|---|---| | Claude Sonnet 4.6 | 90.0% | 98.2% | 8.2 points | | GPT-5.3-Codex | 84.1% | 100.0% | 15.9 points | *Source: "Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update," dbt Labs, April 7, 2026. Methodology: ACME Insurance dataset, 11 business questions, 20 runs per model, open-sourced at [dbt-labs/dbt-llm-sl-bench](https://github.com/dbt-labs/dbt-llm-sl-bench).* As Jason Ganz, Director of Community, Developer Experience & AI at dbt Labs, and co-author Benoit Perigaud put it: "With text-to-SQL, failure looks like a plausible but incorrect answer. With the Semantic Layer, failure looks like an error message." For anything headed to a board deck, an auditor, or a company KPI dashboard, that difference in failure mode, wrong number versus visible error, matters more than the raw accuracy percentage. ### The 2023-to-2026 trendline: raw text-to-SQL is improving too Model quality is not irrelevant, just insufficient alone. dbt's own data, from the [same 2026 benchmark post](https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026), shows unmodeled text-to-SQL accuracy climbing from 32.7% in 2023 to 64.5% in 2026 as frontier models improved, nearly doubling in three years on the same benchmark harness. That trendline matters for the honest version of this argument: a semantic layer does not win because raw models are frozen in place. It wins because even a model that keeps improving still cannot invent a metric definition, certified join, or access policy nobody told it about, exactly the ceiling a semantic layer's deterministic query generation is built to remove. The benchmark's real message is not "semantic layer good, model bad." It is that better models raise the floor while governed definitions raise the ceiling, and enterprise production needs both moving together, not one substituting for the other. --- ## What is metric drift, and why does it happen? Metric drift is what Omni, a BI vendor, named the pattern where "queries return different numbers for the same metric, such as 'revenue' or 'churn'" depending on who asks or which agent answers, according to [Omni's own analysis](https://omni.co/blog/why-text-to-sql-fails) ("Why text-to-SQL fails," April 2026). It is a third-party term, not an Atlan coinage, and it names precisely the failure this article is built around: the SQL runs, the syntax is fine, and the number is still wrong, because nothing in the system decided what the metric means, once, for everyone. According to that same [Omni analysis](https://omni.co/blog/why-text-to-sql-fails), 81.2% of text-to-SQL failures happen at the schema or semantic level, not the syntax level. That statistic reframes the whole debate: most of the industry's attention on prompt engineering and query correction is aimed at the smaller 18.8% of the problem. The larger share is a governance gap, exactly where a business glossary earns its place, one governed definition of "active customer" or "revenue," connected to the technical assets that implement it, so the same question returns the same number regardless of who asks. This is the exact conflict [context layer for data analytics teams](https://atlan.com/know/ai-agent/context-layer-for-data-analytics-teams/) is built to end. Metric drift matters most for the questions asked the same way, over and over, by different people and different agents, revenue, churn, active customer, not for a one-off exploratory query nobody will ask twice. For those repeatable, high-stakes questions, metric drift is not a model problem dressed up as a business one; it is what happens when "looks right" and "is right" are allowed to diverge, and it closes when one governed definition, not one better model, sits behind every surface asking the question. --- ## Text-to-SQL vs. semantic layer vs. governed context layer: what's the difference? These three are not competing options ranked best to worst. They answer different questions: dbt Labs' own conclusion is that a semantic layer is best for board, auditor, and KPI-grade questions, while raw text-to-SQL still has a place for ad hoc exploration nobody has modeled yet. Flattening that into "semantic layer always wins" misrepresents the primary research this article leans on. | Dimension | Raw text-to-SQL | Semantic layer | Governed context layer | |---|---|---|---| | Metric definitions | Guessed per query | Modeled once, reused | Modeled once, plus ownership and certification | | Join accuracy | Guessed from schema | Certified within modeled scope | Certified across the full Enterprise Data Graph | | Coverage of ad hoc questions | Full, but unreliable | Bounded to what's modeled | Full, extended from lineage and query history | | Access control | Not built in | Depends on implementation | Scoped per user before SQL generation | | Auditability | Low | High, within modeled scope | High, end to end | | Best for | Ad hoc exploration | Board, auditor, KPI-grade questions | Both, at enterprise scale | Independent research backs the pattern beyond dbt's own numbers: one study found [knowledge-graph](https://arxiv.org/abs/2311.07509) context lifted GPT-4's accuracy on enterprise SQL question-answering from 16% to 54%, evidence the lift comes from governed structure generally, not one vendor's benchmark design. Whether that structure is framed as a [context graph versus a knowledge graph](https://atlan.com/know/context-graph-vs-knowledge-graph/) is a naming detail; the accuracy lift comes from the same underlying discipline either way. A semantic layer's coverage bound is real, not a footnote. It only answers what has already been modeled, and every enterprise has questions nobody modeled yet. That gap is itself a context problem, not an argument against semantic layers. Atlan's Context Agents draft glossary terms and certified joins directly from existing SQL history and lineage, with a human certifying each before it goes live, extending coverage without requiring every question pre-modeled by hand. As Atlan's own breakdown of [context layer vs. semantic layer](https://atlan.com/know/context-layer-vs-semantic-layer/) argues, a governed context layer is broader than a semantic layer rather than a replacement for one: it wraps dbt's Semantic Layer, Looker, or any existing semantic model with lineage, ownership, and policy, instead of competing with them. ### When a semantic layer is enough, and when it isn't A semantic layer is enough when the question is one the business has already agreed to define: revenue, churn, active customer, anything headed to a board deck. It is not enough alone when the question is genuinely new, the join needed hasn't been certified yet, or the person asking shouldn't see part of the data. Whether that missing structure is an [ontology-versus-semantic-layer](https://atlan.com/know/ontology-vs-semantic-layer/) distinction, a [materialized context for AI analysts](https://atlan.com/know/semantic-views-human-meaning-to-materialized-context/), or the harder claim that [semantic layers alone aren't the finish line](https://atlan.com/know/semantic-layers-failed-context-graphs/), the requirement is the same: someone certifies meaning before an agent can trust it. Coverage, joins, and access are context problems a semantic layer was never built to solve, exactly what a governed context layer adds on top. The honest answer is both, for different things, not a winner and a loser; what decides whether either is trustworthy at scale is the same governed context layer underneath both. Context Gap Calculator Estimate how much of your text-to-SQL agent's schema is actually certified, current, and safe to query. Check Your Gap --- ## Why do enterprises need a governed context layer for text-to-SQL? The clearest evidence for a governed context layer isn't benchmark math, it's what happens when a text-to-SQL pilot leaves its curated dataset. One enterprise customer's proof of concept was trustworthy across a handful of hand-picked tables; extending it across the hundreds of tables actually in production use required disproportionate expert review to keep that trust level, because nothing in the system yet encoded which joins were correct or which definitions were current. That scaling wall, not a benchmark number, is where "looks right" quietly becomes "is wrong," echoing the same wall behind [why AI agents get stuck in POC testing hell](https://atlan.com/know/ai-agents-poc-testing-hell/) and one of the [root causes AI agents fail in production](https://atlan.com/know/why-ai-agents-fail-in-production/). LinkedIn's own internal deployment documents a version of the same wall moving [text-to-SQL past a curated slice](https://arxiv.org/abs/2507.14372) of its warehouse, and self-service BI teams asking the same questions through [conversational analytics](https://atlan.com/know/conversational-analytics/) hit it once dashboards move past a handful of certified metrics. Not every workload needs to make this leap. A one-off exploratory question a single analyst asks once doesn't need the same certification a metric reused across the business does; the wall shows up specifically when a pilot's scope has to grow into a repeatable, shared surface, exactly where ad hoc questions give way to board- and audit-grade ones. ### Use case 1: scaling text-to-SQL past a curated pilot A pilot scoped to a handful of tables an expert vetted by hand looks production-ready because the expert already did the governance work invisibly. Scaling to the hundreds of tables a real warehouse contains, without a governed layer, means redoing that review manually for every table added, a cost that grows faster than the pilot's apparent success suggests. ### Use case 2: eliminating hallucinated joins When a question spans tables the model hasn't seen joined before, it guesses at the relationship instead of looking one up. Atlan's [Enterprise Data Graph](https://atlan.com/know/enterprise-data-graph/) resolves certified join paths so the agent traverses a known relationship instead of inferring one. ### Use case 3: surfacing stale or deprecated data before the agent trusts it A table deprecated last quarter still returns a syntactically valid answer if nobody tells the agent otherwise, the same root cause behind [data quality problems in LLM applications](https://atlan.com/know/data-quality-in-llms/) generally. Certification and trust signals flag low-confidence or stale assets before the agent reasons over them, so a freshness failure surfaces as a visible uncertainty flag instead of a confident wrong number, the same distinction dbt Labs draws between an error message and a plausible mistake. Each failure shares the same shape: the system had no governed answer to a question it should have already known, the gap a context layer, not a bigger model, is built to close. --- ## How to evaluate a text-to-SQL or governed context layer solution Evaluating a text-to-SQL or context-layer vendor on accuracy alone misses the questions that actually determine whether it survives contact with production. The better lens treats governed context as a buying criterion in its own right, not an afterthought to a demo that only shows the easy questions. | Criterion | Why it matters | What to look for | |---|---|---| | Metric governance | Prevents the same question from returning different numbers | One glossary definition per metric, owned and versioned | | Join and lineage certification | Stops the model from guessing at table relationships | Certified join paths traceable through column-level lineage | | Access-policy scoping | Prevents the agent from seeing data the user should not | Schema and rows scoped to the user before SQL generation | | Coverage of unmodeled questions | Determines what happens outside the semantic layer's scope | A path to certify new joins and definitions without months of manual modeling | | Auditability | Determines whether a number can be defended to an auditor | A number traceable back to its source column, not just its query | Ask vendors directly: who owns the metric definition when the model and warehouse disagree? How are joins certified, and by whom? Is schema scoped to the user before or after SQL generation? What happens outside the modeled semantic layer? Can you trace a number back to its source column? A vendor that answers all five without hedging has thought about governed context as infrastructure, not a feature request. [Google Cloud's own framing of the six recurring failures of text-to-SQL](https://medium.com/google-cloud/the-six-failures-of-text-to-sql-and-how-to-fix-them-with-agents-ef5fd2b74b68) names dynamic schema retrieval as its fix; the criteria above ask who certifies that retrieved schema before the agent trusts it, part of the broader discipline of [evaluating an AI agent beyond accuracy](https://atlan.com/know/ai-agent-evaluation-benchmarks-and-metrics/). None of these five criteria show up on an accuracy leaderboard, and all five separate a demo that impresses from a deployment that survives an audit. --- ## What are the security risks of enterprise text-to-SQL? Metric drift is not the only failure mode. Access control is a second, distinct risk: a text-to-SQL agent that can technically query any table in the warehouse will, if asked the right way, generate a query against data the requester should never see. Anthropic shipped a Securing text-to-SQL cookbook to its widely-starred anthropic-cookbook repository in 2026, mainstream acknowledgment that this risk is now common enough to warrant official framework-level guidance, not an edge case. Anthropic's guidance is valuable, and it operates at query time: validating or sanitizing the SQL after the model has already generated it. A more durable fix scopes what the agent can see before generation happens at all, the same principle behind [AI agent access control](https://atlan.com/know/ai-agent-access-control/) generally, and the reason [MCP alone does not deliver business context](https://atlan.com/know/mcp-delivers-business-context/) without a policy layer wrapping it. Atlan delivers that scoping through MCP: the agent receives only the schema and rows a given user is permitted to see, pre-scoped by policy context, rather than a query checked after the fact and rejected once it reaches too far. Catching a bad query after it's written is still catching it late. The more durable fix is context that already knows what this user is allowed to ask before the model writes a single line of SQL. --- ## How Atlan approaches text-to-SQL and governed context Enterprise text-to-SQL pilots hit a predictable scaling wall: trustworthy on a handful of hand-vetted tables, expensive and slow to trust once scope grows to the hundreds of tables a real warehouse contains, and closing that wall is the problem Atlan is built to remove. An agent that is accurate on a handful of tables an expert reviewed by hand should not require that same manual review, repeated indefinitely, to stay accurate across hundreds more. Atlan's Enterprise Data Graph resolves certified join paths so an agent stops guessing at how tables relate. A single business glossary gives every team, and every agent, one definition of "active customer" or "revenue," the direct fix for the metric drift Omni named. Column-level lineage makes every result traceable back to its source, not just trusted on faith. Certification and trust signals flag deprecated or low-confidence assets before an agent reasons over them. Policy context delivered through [MCP](https://atlan.com/know/what-is-atlan-mcp/) scopes schema and rows to what a given user is allowed to see, before SQL generation, not after. Context Agents draft glossary terms and certified joins directly from existing SQL history and lineage, with a human certifying each before it goes live, so building this layer does not require modeling every question by hand. Atlan's own benchmarks measure a different baseline than dbt's, schema-only prompts, not a semantic-layer-grounded one, so the two aren't additive; they're two independent tests of the same underlying mechanism. In a joint benchmark with [Snowflake Intelligence](https://atlan.com/know/snowflake-intelligence-atlan-partner-talk-to-data/), context-enriched metadata, column descriptions, glossary terms, lineage, improved talk-to-data SQL-generation accuracy 3x over schema-only prompts. A separate, earlier [522-query benchmark](https://atlan.com/know/enhanced-metadata-improves-query-accuracy/) found enhanced metadata delivered a 38% relative improvement in AI-generated SQL accuracy. Neither number competes with dbt's third-party research; both confirm the same mechanism from inside a different architecture: context, not a bigger model, is what closes the gap. The model was never the bottleneck. What was missing is the same thing on every enterprise AI surface: one governed context layer every surface, including this one, can read from. --- ## Real stories from real customers: governed context behind talk-to-data agents "We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server…as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products." Joe DosSantos, VP of Enterprise Data & Analytics, Workday Watch Now "Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models." Sridher Arumugham, Chief Data & Analytics Officer, DigiKey Watch Now Neither quote is specifically about text-to-SQL. Both point at the same shared-language and MCP-delivered context this article argues every text-to-SQL agent needs underneath it. What's an unresolved metric gap costing you? Run the Context Layer ROI Calculator to size what metric drift and uncertified joins are already costing your AI initiatives. Calculate the ROI --- ## Why governed context, not a bigger model, closes the text-to-SQL gap The model was never the real bottleneck, at least not for the board-, auditor-, and KPI-grade questions this article is about. Claude Sonnet 4.6 and GPT-5.3-Codex both write syntactically excellent SQL in 2026, and both still land short of full accuracy on those questions because nothing tells them, once, what a metric means, which join is certified, or which table went stale last quarter. Raw text-to-SQL keeps its place for the ad hoc exploration nobody has modeled yet, dbt Labs' own "both, for different things" conclusion, not a verdict against it. dbt Labs' benchmark closes most of the gap for the questions that need governing; Omni's "metric drift" names what's left. A governed context layer closes the rest of that specific gap: coverage of the questions nobody modeled yet, certified joins, freshness signals, and access scoped before a query is written, extended from Context Agents rather than requiring every question modeled by hand. The pattern is the same one behind [what a context layer is and why AI systems need it](https://atlan.com/know/what-is-context-layer/), and the same reason [AI agent accuracy](https://atlan.com/know/ai-agent/ai-agent-accuracy/) is a context problem before it is ever a model problem. For teams building this out step by step, [how to implement an enterprise context layer for AI](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/) walks through the sequence, and the [enterprise context layer](https://atlan.com/know/context-layer-enterprise-ai/) hub covers the data behind why it matters beyond this one surface. Book a Demo --- ## FAQs about text-to-SQL for enterprise ### 1. What is Text2SQL? Text2SQL, also called text-to-SQL, is the automated conversion of a natural-language question into a SQL query, typically generated by a large language model reading a database schema. It lets non-technical users ask data questions in plain English instead of writing SQL by hand. Accuracy depends heavily on whether the model has access to governed business context beyond the raw schema. ### 2. Why is text-to-SQL so hard for enterprises? Enterprise schemas carry ambiguous table names, undocumented joins, and dozens of near-duplicate columns that academic benchmarks never test. A 2025 study found an agent scoring 91.2% on an academic benchmark drop to 21.3% on an enterprise-realistic one. The gap is business meaning, not SQL syntax; frontier models already write syntactically correct queries. ### 3. What is metric drift in text-to-SQL? Metric drift is when the same question, such as what was our revenue last quarter, returns different numbers depending on who asks or which agent answers. Omni coined the term to describe schema and semantic-level failures, which account for roughly 81% of text-to-SQL errors, more common than syntax errors. A governed business glossary is the direct fix. ### 4. Do you need a semantic layer for accurate text-to-SQL? For board, auditor, or KPI-grade questions, yes: a 2026 dbt Labs benchmark measured semantic-layer grounding lifting accuracy from 90.0% to 98.2% and 84.1% to 100% across two frontier models. For ad hoc exploration outside what has been modeled, raw text-to-SQL still has a role. Most enterprises need both, governed by one context layer. ### 5. What is the best practice for text-to-SQL in production? Ground queries in a governed semantic layer with certified metric definitions and joins rather than letting the model generate SQL against raw schema. Scope schema and row access to the requesting user before the query is generated, not after. Flag stale or deprecated assets so the agent treats them as uncertain rather than authoritative. ### 6. What causes SQL errors in AI-generated queries? Most errors are not syntax mistakes; roughly 81% trace back to schema or semantic-level misunderstanding, guessing at what a column or join means, not how to write valid SQL. The remainder come from ambiguous table structures and undocumented relationships common in production warehouses but absent from training data and academic benchmarks. ### 7. How does Atlan improve text-to-SQL accuracy? Atlan delivers certified join paths, one governed metric definition, column-level lineage, and pre-scoped access policy to any text-to-SQL agent through its MCP server. In a joint benchmark with Snowflake Intelligence, that context-enriched metadata improved SQL-generation accuracy 3x over schema-only prompts, and a separate 522-query benchmark measured a 38% relative improvement. --- ## Sources 1. Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, dbt Labs. https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026 2. Why text-to-SQL fails, Omni. https://omni.co/blog/why-text-to-sql-fails 3. Spider 2.0: Evaluating LLMs on Real-World Enterprise Text-to-SQL Workflows, arXiv. https://arxiv.org/abs/2411.07763 4. A Benchmark to Understand the Role of Knowledge Graphs on LLM Accuracy for Enterprise SQL QA, arXiv. https://arxiv.org/abs/2311.07509 5. Text-to-SQL for Enterprise Data Analytics, arXiv (LinkedIn). https://arxiv.org/abs/2507.14372 6. The Six Failures of Text-to-SQL (And How to Fix Them With Agents), Google Cloud. https://medium.com/google-cloud/the-six-failures-of-text-to-sql-and-how-to-fix-them-with-agents-ef5fd2b74b68 7. dbt-labs/dbt-llm-sl-bench, GitHub. https://github.com/dbt-labs/dbt-llm-sl-bench 8. Securing text-to-SQL, Anthropic Cookbook (GitHub). https://github.com/anthropics/anthropic-cookbook 9. Making Talk to Data 3x More Accurate, Atlan. https://atlan.com/know/snowflake-intelligence-atlan-partner-talk-to-data/ 10. How We Proved Metadata Delivers 38% Better AI Accuracy, Atlan. https://atlan.com/know/enhanced-metadata-improves-query-accuracy/