Configuring Agentic AI Analytics: From Free-Text-to-SQL to Model Context Protocol

What You'll Learn 

• Why letting an AI agent write its own SQL query sounds simple but breaks down in practice, even at companies with strong engineering teams 

• What a semantic layer is and why having one doesn't automatically fix inconsistent numbers 

• How much accuracy costs to maintain over time, using Anthropic's own published numbers 

• What changes, in both cost and reliability, when a system is built to answer only questions it can fully verify 

• Why the model isn't usually the reason AI analytics systems get things wrong 

Most warehouses and lakehouses aren't clean, and they don't get messy overnight. They grow the way a house does after twenty years of add-ons. Over a few years, that adds up to real sprawl, whether the data sits in a warehouse or a lakehouse. 

An informal survey run by a Forrester analyst found that 61% of organizations use four or more BI tools, and a quarter use ten or more [1]. Each tool usually keeps its own version of the same metrics, which is part of why revenue can mean five different numbers depending on the dashboard you check, warehouse or lakehouse alike. 

Every new AI-generated pipeline, every dashboard an agent spins up on request, is one more room added to a house nobody was fully inspecting in the first place. The mess compounds faster than most teams can architect or review it. 

This is the backdrop George Bezerra worked from, at Datalere's June Data Dialogues session, "Data Modeling in the Age of AI" [2]. He laid out two ways AI can query a warehouse or lakehouse and argued that one of them is a mistake most teams are already making.  

Denver Data Dialogues, the same event behind that talk, meets monthly in Denver. The next session, "Data Governance and Metadata Architecture for Agentic AI," covers the governance layer this piece keeps circling back to. Worth a look if you're in the area or planning a visit [3].  

Section 1: Three Approaches, Three Different Gates

Part 1: The Default Approach: Free-Text-to-SQL 

Free-text-to-SQL means an AI agent takes a plain-language question and writes the SQL query itself, from scratch, every time. There's no pre-approved set of queries for it to choose from instead. It's reasoning over the schema, deciding what tables and joins the question needs, and generating executable SQL as its answer. Nothing about the query exists until the agent writes it, and nothing stops it from writing a different query the next time the same question gets asked. 

This is the approach nearly everyone reaches for first, and the one George spends his talk picking apart. 

OpenAI's six layers of context  

OpenAI built its own internal data agent for a much larger problem: 600 petabytes across 70,000 datasets, used by 3,500 employees. Their approach stacks six layers of context, and each one requires its own upkeep: 

• Table usage history, built from historical query logs, needs constant re-ingestion as new queries get written 

• Human-written annotations on tables and columns, curated by domain experts, an ongoing curation burden with no single governed layer sitting on top of it to enforce consistency across all six 

• Code-level enrichment, pulled automatically from the pipelines that build each table, refreshed daily 

• Institutional knowledge, docs, Slack threads, decision logs, ingested and embedded, requiring permissions and caching to be maintained at runtime 

• A memory system that learns from corrections, meaning every mistake becomes something someone must actively confirm and save before it improves 

• Runtime checks against the live warehouse, run fresh whenever nothing else applies [4] 

The retrieval mechanism is retrieval-augmented generation (RAG): these six layers get converted into embeddings and retrieved through RAG at query time. RAG queries an indexed representation; embeddings built offline from schema metadata and docs, not the live warehouse itself. The query that finally runs, once written, executes against the live tables separately. This retrieval mechanism, generation as the fallback once a governed layer runs out of coverage, shows up again later in this piece. 

If you're planning to build RAG functionality in-house, Kevin Petrie, VP of Research at BARC, weighs the pros and cons of build-versus-buy [5]. His piece walks through four questions, covering in-house expertise, infrastructure, tooling, and governance readiness, to help decide which path fits. 

Maintaining all six layers, though, is a heavier load than it first appears. None of these six layers gates the others. There's no single governed checkpoint anywhere in the stack, no one definition that, once correct, stays the source of truth for every question that touches it. 

Four points against free-text-to-SQL 

1. Non-deterministic. Fresh SQL on every question means no guarantee the same question gets the same answer twice. 

2. Inaccurate, by the standard a board deck actually needs, not the standard a demo needs. 

3. Manual, since the context holding accuracy up doesn't maintain itself. 

4. Token inefficient, since a messy warehouse means resending large amounts of context, every single question. 

 Figure 1. The free-text-to-SQL path: Probabilistic

Maintenance happens either way 

Building and maintaining a governed model always takes human investment, regardless of the approach sitting on top of it. That upfront work to define metrics and dimensions correctly is unavoidable. Maintenance is required either way. The difference is how failure shows up when that upkeep lapses. Stale documentation in the free-text fallback path fails quietly. The agent keeps answering with full confidence while accuracy erodes underneath it, exactly how much is what Section 2 covers next. 

Part 2: Anthropic's Tiered Approach 

Anthropic's system checks four sources, in a fixed order of trust, before it ever writes SQL from scratch. 

A question that matches something in the chain gets answered through a governed function call, getting the same deterministic result every time. A question that doesn't match anything, after all four sources have been checked, still falls through to the same free-text generation covered in Part 1. 

The order of that chain, and what each tier actually checks, is what this section walks through. 

Tier 1: the semantic layer 

Humans write and own tier 1's metric and dimension definitions. Instead of dozens of near-duplicate tables each claiming to represent the same thing, a single definition becomes the governed answer. This is the required first check for every question, and common justifications for skipping it are explicitly rejected. Needing a join isn't valid, since the governed layer already handles joins internally. 

What happened when Anthropic tried to automate tier 1  

1. To cut down the ongoing curation effort, Anthropic tried having an LLM generate those metric definitions itself, straight from raw tables and query logs, instead of a human writing them. 

2. The result was worse than the human-curated version they already had. No specific before-and-after numbers are published for this experiment, only that it was "net-negative" against the human-curated layer. 

3. They pivoted back to human ownership of definitions, with Claude limited to writing documentation around them rather than deciding what the definitions are [4]. 

Tier 2: lineage and the transformation graph 

When the semantic layer doesn't cover a question, the agent reasons about lineage instead, tracing which upstream models feed a given concept. This turns "no governed metric exists" into "here's the correct model to aggregate from." 

Tier 3: the query corpus 

Historical SQL from dashboards and past analyses. Anthropic's own testing found that giving the agent raw retrieval access to this corpus moved accuracy by less than a point, so it gets distilled into structured reference docs ahead of time. The agent doesn't search for it live. 

Tier 4: business context 

This tier draws on a company knowledge graph, assembled from docs, roadmaps, and decision logs, and retrieved through RAG. It resolves ambiguous references that a metric definition alone cannot answer. 

How that resolution feeds back into the rest of the system is left unspecified, though the plausible reading is that it feeds the agent's interpretation directly. 

If that's right, business context can resolve an ambiguous question well enough to match a governed metric after all. A question that first looked outside tier 1's coverage does not always need to fall through to generation. 

This tier likely sits on the same kind of warehouse and model foundation covered in the semantic layer section and in the MCP diagram in Part 3. Though, the underlying infrastructure is not described in detail anywhere in the published account. 

Skills: procedural knowledge on top of the tiers 

Separately, Anthropic published offline evaluation results for its skills layer, the procedural documentation that tells the agent which sources to check, in what order, and how to interpret ambiguous data [6]: 

• Without skills, Claude answered business analytics questions with 21% accuracy on Anthropic's own evals. 

• Once Anthropic built out the skills layer, eval accuracy rose to 95% in aggregate. 

• After a month of that skill documentation going unmaintained, eval accuracy dropped to 65%. 

 The diagram below shows how a question moves through all four tiers, including the point where it still falls through to generation if nothing matches. 

 Figure 2. Anthropic's Tiered Path 

Part 3: The Model Context Protocol (MCP) Approach 

Model Context Protocol (MCP) takes a narrower view of what an agent should be allowed to do. Instead of reasoning over raw tables and writing its own SQL, the agent works from a fixed menu of pre-built functions. It picks one, fills in a few parameters, and the function does the rest. Who touches the data is what changes here. Under MCP, the agent never does. The function does, and the function was written and tested before the agent ever saw the question. 

MCP holds itself to a 100% accuracy standard. A wrong answer delivered with full confidence looks identical to a right one, and a board deck can't tell the difference between the two. If the system can't guarantee correctness, MCP routes the question to a person instead of guessing. 

A single governed layer 

Anthropic reaches its accuracy guarantee through four sources checked in descending trust. MCP reaches the same guarantee through one governed layer: 

• The catalog is fixed and small. Each governed metric in it is built once, tested once, and validated once. A metric name, a dimension, a date range, a filter make up the entire input surface. 

• Every call runs the same logic and returns the same result, no matter who's asking or how many times. 

• The agent still has to read the question and decide what it means. That step stays probabilistic, the same as any of the other approaches this piece covers. What's different is how narrow the decision is. The agent only ever decides which metric to call and what parameters to fill in. It never decides what the underlying query looks like. 

Because the agent's decision is narrow, the boundary has no gaps to fall through. Every uncovered question exits to a person instead of a guess, since there is no fallback path built in. 

MCP's catalog depends on external infrastructure to function: the same warehouse, transformation layer, and dimensional model that back Anthropic's tier 1. That infrastructure is maintained on its own schedule, outside MCP's own guarantees. 

What governed access buys 

The payoff for building this way shows how much ground a single-governed layer can cover. A semantic layer defines what "revenue" means, once. An MCP server enforces that every caller uses the same definition. A flexible, conversational front end can then sit on a backend that behaves the way traditional BI always has: fixed logic, tested once, reused every time. 

A warehouse with 10 metrics and 8 dimensions has 80 valid combinations before anyone even adds filters or date ranges. Here's what that means in practice: 

1. A traditional dashboard team ships maybe 15 or 20 pre-built views, the ones stakeholders asked for most often. 

2. Someone wants revenue broken out by acquisition channel and customer tier together, a combination nobody thought to chart. They file a ticket and wait. 

3. A governed tool call serves any of the 80 combinations on the spot instead, because the calculation logic already exists for every metric and dimension in the set. 

The gain is reach: combinations no dashboard was ever built to cover. 

Figure 3. Model Context Protocol Path 

How the tools are built and what they cost 

Serving that many combinations without the tool count exploding takes a specific structure. People often assume this setup needs one tool per metric. Building one tool per metric stops scaling: ten metrics means ten functions to write, test, and maintain on their own, a hundred metrics means a hundred. A small set of parameterized tools scales instead: 

• get_metric(metric_name, dimensions, filters, date_range), the main workhorse 

• list_metrics(), so the agent can see what's available before calling anything 

Metric and dimension names become parameter values drawn from a governed catalog, not separate functions the agent has to pick between. Two tools can cover a warehouse with 10 metrics the same way they cover one with 200. Only the catalog grows. The tool count stays flat, and the same function handles filtering and grouping without any new tools at all: get_metric("revenue", filters={"region": "West"}) narrows to one region, get_metric("revenue", dimensions=["region", "channel"]) breaks revenue out by both dimensions in one call. The join logic and the aggregation rule stay fixed across every call. The inputs are what change. 

A flat tool count still comes from a catalog someone had to build. Each metric and dimension has to be defined, tested, and validated once before get_metric can serve it. A warehouse with 200 metrics needs 200 of these validated before the tool can answer a single question about any of them, and this upfront cost is where the next caution starts. 

A caution about overbuilding 

Determinism guarantees a stable answer. Whether an architecture was worth building for a given question is a separate question, worth asking before assuming every use case justifies the investment above. 

Meagan Palmer, in a 2025 piece on semantic layers and MCP servers, makes the relevant caution directly: these tools guarantee the same question returns the same answer every time [7]. The guarantee doesn't automatically translate into value. A governed tool call answering, "what was revenue last quarter," a number already sitting on page one of an existing dashboard, mostly adds a conversational way to ask something that already had a fast answer.  

The value case sits somewhere more specific: combinations like revenue by channel and tier together, the kind no dashboard was pre-built to chart. A governed tool call earns its cost over a dashboard here. 

How often a question falls outside the catalog 

The value case described above, revenue by channel and tier, rests on an assumption this piece can't confirm. It only pays off if the catalog covers the combination someone asks for, and how often a question falls outside that catalog in practice is never established. George's talk doesn't give a number, or even a rough sense, of how often that happens. This gap in the framing shows up beyond George's talk too. 

dbt Labs' own guidance on production MCP patterns describes the same boundary. Governed metric queries work well. Complex multi-join questions still need a person involved [8]. dbt Labs doesn't attach a frequency to that boundary either. Without a coverage figure, from George's talk or anywhere else in the current discussion, there's no way to weigh the upfront cost this section just walked through against how much ground the catalog covers. 

Section 2: A Semantic Layer Does Not Fix an Unreconciled Number 

A semantic layer defines what a metric means. Whether the underlying number is correct depends on something built earlier: the transformation logic underneath it, written before the semantic layer ever gets involved. A transformation layer or dimensional model can exist without a semantic layer on top; most warehouses start exactly this way. The example below shows what happens when a semantic layer gets built on top of transformation logic that nobody reconciled first. 

Datalere's own May 2026 webinar makes a related sequencing argument at the methodology level: model business concepts before data structures, and keep meaning separate from implementation [9]. The same principle applies here at the metric level, a governed name means little if the calculation logic behind it was never reconciled first. The accompanying slide deck goes further, covering semantic layer architecture more broadly, including data modeling, implementation patterns, and best practices [10].  

Model first, then layer 

Marketing and product both report "revenue," but the two numbers don't match: 

1. Marketing sums gross order value, recognized the moment an order is placed. 

2. Product sums net revenue after refunds, recognized on the invoice date. 

3. A semantic layer can name a single governed "revenue" metric. 

4. Naming it doesn't make marketing and product agree on what it calculates, not while the logic behind each number was never reconciled. 

Marketing and product disagree because nobody centralized the calculation logic before naming the metric. Reversing that order fixes it: centralize the logic first, then build the semantic layer on top of it. Once the logic lives in one place, the semantic layer's job stays simple: expose one governed definition of "revenue" that can be used everywhere. 

Five BI tools connected straight to a well-modeled warehouse each still need their own calculated field for "revenue." Tableau's, Power BI's, Looker's, each written independently, each a fresh chance to define the formula slightly differently. A semantic layer sitting in front of all five removes the duplication, but only once the formula behind it gets settled first. 

The scale of the problem 

Recent survey data puts numbers on how often this happens: 

• 84% of data teams report encountering conflicting versions of the same metric [11]. 

• Gartner projects that 60% of agentic analytics projects relying on MCP alone, without a consistent semantic layer underneath, will fail by 2028 [12].  

Gartner's figure carries a specific warning for MCP catalogs built without a semantic layer underneath. A tool call stays only as trustworthy as the model and the semantic layer feeding it. Skip either one, and the deterministic execution from Part 3 still runs exactly as designed, against a definition nobody settled in advance. 

Figure 4. The Semantic Layer Inputs

Section 3: What Each Approach Costs Per Question  

Every token an agent processes costs money and adds latency. The three approaches this piece has covered spend very differently on the same question. 

What free-text-to-SQL sends, every time 

Say a warehouse has 40 tables, a business glossary of 60 terms, and a handful of known gotchas about joins and null handling. Answering one question means putting enough of that into the context window to write a correct query: 

1. Table and column names, plus their relationships 

2. Business definitions for whatever the question touches 

3. Known pitfalls, like which join produces duplicates 

None of that carries over to the next question. A second question about the same tables triggers the same retrieval, the same token cost, again. Ask ten questions in a session, and the schema and glossary material gets sent something close to ten times. 

What Anthropic's tier 1 sends when it matches 

A question that matches a governed metric skips retrieval entirely. The agent sends a metric name and a few parameters, nothing about schema, joins, or business definitions. Only when tier 1 doesn't cover the question does the cost from the free-text pattern above apply, through tiers 2 through 4 and the generation fallback. 

What an MCP tool call sends 

The same question through an MCP tool call sends a function name and a few parameter values: get_metric("revenue", dimensions=["region"], date_range="last_quarter") 

That's a few dozen tokens. The join logic, the table names, the metric formula, all of it lives inside the tool already, written once when the tool was built. The agent never sees any of it. The tool's own definition, its name, description, and parameter schema, loads into context once per session. Every call afterward draws on that same load without paying the cost again. Ask ten questions in a session, and the tool call payload stays roughly the same size each time, because there's no tier where the cost reappears. 

The tradeoff 

Governed access pays off once a question gets asked repeatedly against a model that already exists. Free-text stays the cheaper choice for a question asked once, against data nobody has modeled yet. This is the same build-cost logic Part 3 covers in its caution about overbuilding, under Section 1.

Section 4: The Build Order Proves the Thesis 

The previous sections described architecture on paper. Datalere's own client work shows what it looks like built. 

Founder and CEO Carlos Bossy recently walked through a live build on Snowflake Cortex [13]. He built an agent for a health insurance use case, modeled on active client engagements. Before the agent existed, the work was semantic views: five or six of them, each defining dimensions, facts, metrics, and relationships on top of an existing star schema. The agent only got configured once that groundwork existed, with a defined set of tools it was allowed to query. 

A trimmed excerpt of this build, covering the same sequence, is featured below.[14]. 

                               

The build order carries the convergence thesis. With no foundation in place, the data structures get built first, then the relationships between them, then the semantic layer, then the agent. Every additional domain the agent needs gets the same treatment before it can use it. 

Running the same demo on Claude Sonnet 4.5 and on GPT-5 produced identical numbers and different personalities, in this case the reverse of each model's usual reputation. The governed layer supplies the number either way. What changes is how each model phrases the sentence around it: 

1. Claude Sonnet 4.5 leaned enthusiastic and affirming, phrasing answers like "great, perfect, this is really good." 

2. GPT-5 came back drier and more business-oriented, and added charts and graphs to its answer. 

Neither model touched the underlying calculation. That's the governed layer doing its job regardless of which model sits on top of it. 

Wayne Eckerson, hosting the session, asked Carlos what happens when a question falls outside what the agent was configured to answer. Carlos's answer: he decides in advance what the agent should and shouldn't answer. 

The build also ran into the edge of what it had modeled. That edge is what the next section covers. 

Section 5: Determinism Does Not Mean Correct 

Determinism guarantees that an answer stays consistent. Whether that answer is correct is a separate question entirely. A tool call to a metric with a flawed formula returns that flawed number every time, with total confidence, whether a model generated the logic from scratch or a governed function is executing logic someone already wrote. This boundary shows up in two further ways that matter for anyone building on either governed architecture, Anthropic's tiered chain or MCP's single gate.  

A flawed formula still runs 

A tool call to a metric with a flawed formula returns that flawed number every time, with total confidence. The same failure mode exists whether a model is generating logic from scratch or a governed function is executing logic someone already wrote. A governed function only executes whatever logic got handed to it. Nothing about calling it deterministically catches an error baked upstream. 

A judgment call still sits at the front 

This surfaced directly during George's Q&A, in an exchange worth walking through, not for the answer he gave (routing uncertain cases to a person, the same mechanic already covered in Part 3), but for what the question itself exposes. An attendee asked what happens when someone asks for "Q3" while the calendar currently sits in Q2. Does the agent assume the current year's Q3, which hasn't happened yet, or last year's, which has? 

Picking the right metric and filling in the right parameters is a judgment call made by a language model. Execution downstream stays deterministic. Selecting what to execute is a separate, probabilistic step that happens before it. 

The judgment-call distinction maps onto mechanics this piece has already worked out: 

• In MCP, the metric-selection judgment happens once, at tool selection, before the single gate. 

• In Anthropic's chain, the same judgment happens at every tier: deciding whether tier 1 covers the question, then whether tier 2 or 3 narrows it, then whether tier 4's business context resolves it well enough to retry tier 1. 

More governed checkpoints create more places a wrong guess can happen. 

Figure 5. Escalation paths

A hard boundary 

A governed catalog only covers metrics someone already built. Part 3 already flagged how often a real question falls outside that catalog is never established. What's worth adding here is the boundary's actual shape: a clean cutoff. A metric nobody defined or a dimension nobody modeled doesn't get a degraded answer. There's no function to call at all. 

The three approaches meet this boundary in different places. Free-text never hits it at all; generation always produces something, whether the underlying question was answerable or not. Anthropic's chain hits it only after four tiers fail to resolve the question. MCP hits it immediately, the moment a question falls outside the catalog. 

One attendee described handling this even more strictly at a previous job: scoping a tool to answer questions about one specific table only. Anything outside that table got refused outright, with no attempt at an adjacent answer. 

The attendee's approach is a stricter version of MCP's own boundary, already running in production. 

Narrowing the tool's scope on purpose changes the failure mode in one direction, widening it changes the failure mode in the other: 

• Narrow the scope, and an uncovered question gets a clean handoff to a person. 

• Widen the scope with a generation fallback, and the system covers more questions, at the cost of some answers going unverified until someone checks them. 

The clean handoff only stays clean if uncovered questions stay rare enough for a person to keep up. Past that point, a safe fallback and an unscalable bottleneck look identical, and there's no coverage number available, from George's talk or anywhere else, to tell which one a given system is. 

Summary  

Three approaches, three different use cases. Choosing between them comes down to three questions: 

1. How often will this exact question get asked again? A one-off deserves free-text; a question the board asks every quarter deserves a governed tool call. 

2. What does a wrong answer cost? Free-text's flexibility is worth the risk for exploratory work. It's a poor tradeoff for a number that drives a decision. 

3. Does the underlying model already exist? None of the three approaches skip the modeling work. A governed catalog built on an unmodeled warehouse fails the same way a free-text agent does, just with more confidence in the failure. 

The answers change from one question to the next, not once for the whole organization. A single team can run all three approaches at once: MCP-style governed calls for board-facing metrics, free-text for exploratory analyst work, and a tiered approach for everything in between. Anthropic's own architecture already combines two of the three at a smaller scale: a governed tool call attempt first, free-text generation as the fallback. 

Building any of these three approaches correctly spans more than one team: 

• Data engineering owns the transformation logic. 

• Analytics owns the metric definitions. 

• The people who already reconcile marketing's and finance's numbers by hand, usually analysts, need to agree on a single definition before any of this gets built. 

Whichever approach a team picks, the system inherits whatever definition marketing, finance, and analytics have not yet settled between themselves. Settling that definition is a build step, and it has to happen before the rest. 

Adoption can start small. Model the metrics leadership asks about most first, the ones already discussed enough across teams that everyone agrees what they should mean. Build the catalog around those, then keep expanding it, metric by metric, until it covers what gets asked most often. What isn't modeled yet runs on free-text or a spreadsheet in the meantime, the next item in line to be built. 

This is the work Datalere does for clients directly: building the dimensional model, the semantic layer, and the governed tooling that makes deterministic AI analytics possible in the first place. If your team is weighing these approaches and running into the same modeling gap this piece describes, you can start the conversation by booking a complimentary call.

Key Takeaways 

• An AI agent that writes its own database query, instead of using a pre-approved one, can give a different answer to the same question asked twice, with no guarantee either one is right. 

• Anthropic's own offline evaluations dropped from 95% accuracy to 65% in a single month once the underlying documentation went unmaintained. High accuracy on day one doesn't mean it stays that way. 

• A semantic layer is a single, agreed-upon definition of a business term, like "revenue," meant to stop different teams from calculating the same number differently. It only works if that definition gets settled before the layer is built. 

• One approach removes the agent's ability to write its own query. It still must judge which governed tool fits the question, and that narrower job means it answers fewer questions overall. Every answer it gives is fully verified, and anything outside its defined scope gets routed to a person. 

• None of the three approaches eliminates the modeling work. They change how fast it happens. 

AI Disclaimer 

This piece was developed with AI assistance for research, drafting, and editing. All claims are sourced from primary materials, Datalere's own events and webinar sessions, and the companies' and analysts' own published materials, with citations included throughout. Content has been reviewed and edited by the Datalere team. 

References:  

[1] Forrester, "The BI Fabric Baby Is Slowly But Surely Growing Up," 2023. [Online]. Available: https://go.forrester.com/blogs/the-bi-fabric-baby-is-slowly-but-surely-growing-up/

[2] G. Bezerra, "Data Modeling in the Age of AI," presented at Datalere Data Dialogues, Denver, CO, Jun. 2026. [Online]. Available: https://www.meetup.com/data-dialogues/events/313715028

[3] "Data Governance and Metadata Architecture for Agentic AI," Datalere Data Dialogues, Denver, CO, Sep. 2026. [Online]. Available: https://www.meetup.com/data-dialogues/events/316085499/

[4] OpenAI, "Inside OpenAI's in-house data agent," 2026. [Online]. Available: https://openai.com/index/inside-our-in-house-data-agent/

[5] K. Petrie, "Build or Buy RAG? Four Questions to Guide Your Approach to Retrieval Augmented Generation for GenAI," Datalere (guest contribution, BARC), Jan. 6, 2025. [Online]. Available: https://datalere.com/articles/build-or-buy-rag-four-questions-to-guide-your-approach-to-retrieval-augmented-generation-for-genai

[6] Anthropic, "How Anthropic enables self-service data analytics with Claude," 2026. [Online]. Available: https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude

[7] M. Palmer, "Semantic layers, MCP servers, and the fear of non-determinism," Medium, 2025. [Online]. Available: https://medium.com/@meagsp/semantic-layers-mcp-servers-and-the-fear-of-non-determinism-332bea84f67d

[8] dbt Labs, "5 dbt MCP server patterns that work in production," 2026. [Online]. Available: https://www.getdbt.com/blog/5-dbt-mcp-server-patterns-that-work-in-production 

[9] D. Wells (presenter), C. Bossy, and M. Gaedke, "Semantic Data Layers: The Case for a Semantic Data Layer as an Architectural Component" [Video], Datalere, May 2026. [Online]. Available: https://www.youtube.com/watch?v=XFMsGFHS6cI

[10] D. Wells (presenter), C. Bossy, and M. Gaedke, "Semantic Data Layers: The Case for a Semantic Data Layer as an Architectural Component" [Slides], Datalere, May 2026. [Online]. Available: https://datalere.com/articles/slides-semantic-data-layers-the-case-for-a-semantic-data-layer-as-an-architectural-component

[11] The Modern Data Company, "New report finds the data activation gap is holding back enterprise AI and decision-making," The Globe and Mail, 2026. [Online]. Available: https://www.theglobeandmail.com/investing/markets/markets-news/ACCESS/21947/new-report-from-the-modern-data-company-finds-the-data-activation-gap-is-holding-back-enterprise-ai-and-decision-making/

[12] Gartner, "Gartner says lack of semantics causes inaccurate artificial intelligence agents and wasted spending," press release, May 2026. [Online]. Available: https://www.gartner.com/en/newsroom/press-releases/2026-05-11-gartner-says-lack-of-semantics-causes-inaccurate-artificial-intelligence-agents-and-wasted-spending

[13] C. Bossy and W. Eckerson, "Live Snowflake Cortex build: health insurance use case," Datalere, 2025. [Online]. Available: https://www.youtube.com/watch?v=wPlo_um5p_o

[14] C. Bossy, "Building a Governed AI Agent on Snowflake Cortex: Semantic Views First, Then the Agent" [Video excerpt], Datalere, 2026. [Online]. Available: https://www.youtube.com/watch?v=S61S_YY9MYw