From Warehouse to Knowledge Base

Every company I've worked with keeps its data in two piles that don't quite meet.

On one side, the warehouse: modelled, tested, reconciled, the place where "revenue last quarter" has a defined answer and someone gets paged when it breaks. On the other, everything else: Confluence pages, PDFs in a shared drive, a glossary half-finished in a spreadsheet, decisions buried in Slack threads, and the part nobody writes down at all, which lives in the head of the analyst who's been there nine years.

A person bridges those two piles without noticing they're doing it. Asked for "active customers in the Nordics," a good analyst pulls the number from the warehouse and silently applies four things that aren't in the warehouse: that "active" excludes the trial accounts, that the Nordics include Iceland this year but didn't last year, that the figure finance trusts comes from the reconciled mart and not the raw table, and that the definition changed in March so anything before then needs a caveat. The query returns one column. The answer is built from five sources, four of them outside the database.

Agents can't do that yet, and pretending otherwise is the cause of most disappointing enterprise-AI demos I've sat through.

The warehouse was never the whole picture. It was the part we modelled, the part worth the cost of modelling, back when a human always stood between the data and the decision. Take the human out of that gap and the unmodelled part stops being tribal knowledge and becomes a hole the agent falls into. The warehouse stops being the destination and becomes one input to something larger: a knowledge base that holds the facts and the context together, because the question needs both. I'm using "knowledge base" in a specific sense here, away from its help-desk connotation: the joined surface of structured facts and unstructured context an agent can move across in a single question.

When the agent can query but can't read

Give a capable model read access to the warehouse and a natural-language interface, and it will answer "how many active customers do we have" without hesitation. It writes valid SQL, runs it, returns a clean integer to no decimal places. The number is wrong, and nothing about it looks wrong.

It's wrong because "active" was a decision, not a column. Someone made that decision and recorded it in a definitions doc the agent never read. The model saw a field called status, saw values it could count, and counted them. It had no way to know that status = 4 means "cancelled but still billable," or that the company stopped counting trial accounts as active in March. So it guessed, plausibly.

A plausible guess delivered with confidence is the most expensive kind of wrong, because it survives the meeting.

This isn't an edge case I'm inventing for effect. It's what the benchmarks show the moment they stop using toy databases. Spider 2.0 tests text-to-SQL against real enterprise schemas (the kind with more than a thousand columns and several SQL dialects in play), and the cliff is steep: at publication the best agent solved 21.3% of its tasks, against 91.2% on the original Spider and 73.0% on the earlier BIRD benchmark; GPT-4 on its own managed 6% ^[R1]. Scores have since climbed into the low 80s on some task settings ^[R1], and that climb is worth dwelling on. The systems didn't get good at the warehouse by getting bigger. They got good when the framework around the model was allowed to search the database's metadata, the dialect's documentation, and sometimes the project codebase first, which the paper itself names as what these tasks require ^[R1].

This is the failure I keep returning to: the pipeline is fine, the SQL is fine, the data understanding wasn't. A structured store answers "what is the number." It's mute on "what does this number mean, who owns it, and what changed last quarter," the questions that decide whether the number is safe to act on.

When the agent can read but can't count

Flip it. Point retrieval at the wiki, the policy PDFs, the runbooks, and the agent gets good at a different class of question. "What's our refund policy for enterprise contracts?" It finds the page, reads it, summarises it, cites it. For anything that lives in prose, that's the right tool.

Ask it "how many enterprise refunds did we process last month, and were any outside policy" and it has nothing to count. RAG over documents retrieves text. It can tell you what the policy says; it can't tell you whether you followed it, because following it is a fact in a table the retriever never touches. A wiki has no COUNT(*).

Each half fails in the shape of its own strength. The warehouse is precise about facts and silent about meaning. The document store is rich on meaning and can't add up. The questions a business asks out loud (the ones worth pointing an agent at) sit across the seam.

The shape that works

A usable knowledge base is several stores working together, each doing the job it's good at, with retrieval that can move between them inside one question:

• the warehouse for facts: the numbers, at a stated grain;
• the semantic layer for definitions: what "active customer" means, once, where the agent reads it;
• a catalog for ownership and freshness: who owns this table, when it last loaded, whether it's the authoritative copy;
• a glossary for vocabulary: so "turnover," "revenue," and "top line" resolve to one thing;
• the documents for everything that only exists as prose: policy, context, the reason behind a decision.

The diagram people reach for puts the warehouse in the middle, with everything else arranged around it. I'd draw it differently.

_{The warehouse is one box among several, the same size as the rest. The answer is grounded only if retrieval can reach all of them. Author's illustration.}

The warehouse is one input, not the centre

The moment an agent is the consumer, the database stops being the destination. It's where the facts live, joined at query time to the definitions, ownership, vocabulary, and prose that make a fact safe to use.

The modelling discipline that the warehouse end of this assumes (stable keys, one definition per metric, grain stated in words) is its own argument, and I've made it.

Two builds that taught me the same lesson from opposite ends

I learned this from two side projects that look unrelated and aren't.

The first is a small MCP server that packages Qlik Cloud's documentation (API references, embedding guides, endpoint definitions, product terminology) into tools an assistant can search and retrieve ^[R2]. I built it for a blunt reason: the model could call Qlik but didn't know Qlik. It could hit the right endpoint if you told it which one, but it didn't know the conventions, the gotchas, or which call answered which question, because that knowledge lived in docs the model had either never seen or seen in a stale snapshot. The fix wasn't a better model. It was giving the model the context the structured API couldn't carry on its own: the unstructured half, made retrievable.

The second runs the other way. Obesian Oats is a notes workspace I built around plain Markdown files. What matters here sits under the editor: the same notes are reachable through a CLI and an MCP server, around eighty operations an agent can call against the same store a human edits ^[R3]. Building it drove home that unstructured notes still want structure to be useful. Plain prose is portable, human-readable, and close to impossible for software to reason over reliably until you add the scaffolding: a type in the frontmatter, a wikilink, a due date in a format the parser recognises. The note stays readable. The structure is what lets an agent do anything with it.

One project bolts context onto a structured system. The other bolts structure onto unstructured context. The knowledge base I'm describing is both moves at once, at company scale.

The platforms are racing to the same shape

At company scale, the argument isn't only mine to make anymore. While I was writing it, the major platforms started shipping it.

Databricks made a semantic layer generally available inside its catalog in April 2026: a metric like "active customer" is defined once and read the same way by a dashboard, a SQL query, and an agent reaching it over MCP, with a glossary of authoritative business concepts layered on top for the agents to consult ^[R5]. Snowflake went further with the name. Its June summit led with Horizon Context, described in as many words as "the governed context layer for AI, BI and Apps": catalog metadata enriched into governed semantics and served to agents at query time ^[R6]. And on the day that summit opened, Fivetran and dbt Labs closed a merger pitched at "the data infrastructure for trusted AI agents" and published an open Agents Schema, a convention that hands one schema in your warehouse to the agents as their shared context layer, holding metric definitions, lineage, and business prose as plain tables ^[R7]. That last one is close enough to the argument of this piece that I had to check I hadn't written their announcement.

It isn't only the big three. A metadata-driven shop like TimeXtender now calls itself "the control layer for AI-ready data" ^[R8]; Exasol ships a governed MCP server and bills its latest release as an analytics database for the agentic era ^[R9]. They have even agreed a cross-vendor semantic standard, the Open Semantic Interchange, signed by Snowflake, Databricks, dbt, Qlik, and Salesforce, competitors who agree on almost nothing else ^[R10].

So the direction is settled. But look hard at what every one of these ships: a place to put the definitions, the ownership, the glossary, the context. Not the definitions themselves. The platform hands you a governed, agent-readable schema; deciding that status = 4 means "cancelled but still billable" is still a sentence somebody has to write. Gartner is blunt about the gap, expecting most agentic-analytics projects that lean on MCP alone, with no consistent semantic layer underneath, to fail by 2028 ^[R11]. The wiring is arriving faster than anyone expected. What goes through it is the part that was always the work.

The unglamorous middle

Here's the part nobody demos. Most of the effort in building one of these is not the model and not the vector store. It's getting the structured and unstructured sides to agree on what a thing is called and which version is current.

That sounds trivial until you try it. The warehouse calls it cust_id. The data-sharing agreement calls it "the client reference." The onboarding wiki calls it "account number." A 2019 migration doc calls it by the old system's name for it, which nobody under forty recognises. A human reconciles those in a second. Retrieval doesn't, unless someone has told it they're the same thing. Multiply that by every entity, metric, and status code a business runs on, and the work in front of you is mostly mapping and disambiguation: the least glamorous data work there is, and the part that decides whether the whole thing answers correctly.

Version currency is the other half, and it's worse, because nothing flags it. A table has a load timestamp; you can check freshness. A Confluence page edited in 2021 and never touched since looks exactly as authoritative as one edited yesterday. The retriever can't tell that the 2021 refund policy was superseded. It finds it, ranks it on relevance, and serves it next to a current table with the same quiet confidence. Knowing which document is still true is metadata work, and it's the metadata almost no one maintains.

Retrieval that moves between these sources needs standard wiring to reach each one, which is the job the Model Context Protocol has taken on since Anthropic published it in late 2024 ^[R4]. The pieces that carry this further (wiring an agent to all these sources, tracing where an answer came from, and storing the definitions somewhere durable enough to outlive a tool migration) each deserve their own treatment.

"Just point the LLM at all the data"

The pitch that worries me is the one that sounds most reasonable: index everything, embed it all, let the model sort it out at retrieval time, and coverage will stand in for curation.

It demos beautifully, because a demo runs on a corpus where there's one version of everything and nothing contradicts anything else. Point the same setup at the real thing (three drafts of the same policy, a deprecated runbook, two glossaries that disagree, a warehouse table and a spreadsheet that export the "same" number differently) and coverage becomes the problem. The system surfaces the outdated document next to the current table and has no basis for preferring one, because nobody encoded which one wins. More data made it less trustworthy.

Coverage is not curation

An agent pointed at everything finds the stale policy as readily as the current one and presents them with equal confidence. Retrieval ranks on relevance, not on truth or recency. Deciding which source wins is a governance call a human has to have made first.

The counterargument is that retrieval keeps improving (bigger context windows, re-rankers, models that reason over what they pull back) and that some of today's curation cost is a transitional tax better tooling will absorb. There's something to that, and I won't pretend the tooling is standing still. But the things I've been describing aren't retrieval problems. That status = 4 means "cancelled but still billable," that the reconciled mart wins over the raw table, that the March definition supersedes the January one. None of it is inferable from the documents. It's a set of decisions someone made, and no retriever can recover a decision that was never written down. Better retrieval makes a well-curated knowledge base sharper; it doesn't rescue an uncurated one.

What we still have to model

The warehouse was the part of the business we decided was worth modelling. Everything else (the definitions, the ownership, the vocabulary, the reasons) we left in prose and in people, because a person was always there to supply it. That arrangement held for thirty years. It's the arrangement agents break.

So the work enterprise AI demands turns out to be old work, renamed. Deciding what "active customer" means and writing it where software can read it. Recording which system wins when two disagree. Marking which document is current. Mapping the four names a business has for one thing down to one. Metadata, ownership, and vocabulary: the discipline data teams have always known they should do and mostly got away with skipping, because a person stood in the gap and did it by hand every time a question came up.

---

_{From Warehouse to Knowledge Base · July 2026 · An opinion piece. Benchmark figures are from the cited research and its live leaderboard and were current at the accessed date; the two projects referenced are my own; the read on where enterprise-AI effort goes is my own argument. Full source records are in the References section above.}

References11

1. 1Fangyu Lei et al., "Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows", arXiv:2411.07763, November 2024 (ICLR 2025). Original results and the finding that enterprise tasks require searching metadata, dialect documentation, and project codebases are from the paper; current leaderboard scores are from the project site. arxiv.org ↗ · spider2-sql.github.io ↗ Accessed 2026-06-16
2. 2Henning Naarlien-Tolpinrud, "Qlik Documentation MCP", project page. henning.tolpinrud.no ↗ Accessed 2026-06-16
3. 3Henning Naarlien-Tolpinrud, "Obesian Oats", project page and live site. henning.tolpinrud.no ↗ · obesian.com ↗ Accessed 2026-06-16
4. 4Anthropic, "Introducing the Model Context Protocol", November 25, 2024, and the protocol specification. anthropic.com ↗ · modelcontextprotocol.io ↗ Accessed 2026-06-16
5. 5Databricks, "Announcing General Availability and Open Sourcing of Unity Catalog Business Semantics", April 2, 2026, and "What's new with Unity Catalog at Data + AI Summit 2026", June 16, 2026. databricks.com ↗ · databricks.com ↗
6. 6Snowflake, "Snowflake Horizon Context: The Governed Context Layer for AI, BI and Apps", June 2, 2026. snowflake.com ↗
7. 7Fivetran, "Fivetran + dbt Labs Complete Merger to Create the Data Infrastructure for Trusted AI Agents", June 1, 2026. fivetran.com ↗
8. 8TimeXtender, "AI You Can Trust: TimeXtender's Biggest Release Yet", June 2, 2026, with the current "Control Layer for AI-Ready Data" positioning. timextender.com ↗ · timextender.com ↗
9. 9Exasol, "Integrating Exasol's MCP Server" and "Exasol launches Exasol Personal" (tagged "The Analytics Database for Agentic AI"), December 9, 2025. exasol.com ↗ · exasol.com ↗ Accessed 2026-06-28
10. 10Snowflake, "Open Semantic Interchange's Specs Finalized", January 27, 2026, and the OSI specification repository. snowflake.com ↗ · github.com ↗
11. 11Gartner, "Gartner Announces Top Predictions for Data and Analytics in 2026", March 11, 2026 (prediction that agentic-analytics efforts relying on MCP alone will largely fail by 2028 absent a consistent semantic layer). Corroborated by Maria Korolov, "Data lakehouses are becoming foundations for enterprise AI", CIO, June 24, 2026. gartner.com ↗ · cio.com ↗ Accessed 2026-06-28