Why AI works on your code and stalls on your data

People keep asking when AI for data will have its breakthrough moment, the way coding assistants went from novelty to indispensable in about three years.

The question assumes the breakthrough was the model. It wasn't. AI walked into a world that engineers had spent twenty years designing, for their own reasons, before any model arrived.

Understanding what code had is the fastest way to see what data is missing.

The world AI for code inherited

Code is a designed system, and the design predates large language models by a generation.

A function has a signature. A dependency is declared. A commit has an author, a timestamp and a diff. A type states what is allowed and what isn't. Every one of those is a contract a machine can read without guessing.

When an assistant opens a repository, it isn't inferring structure. It's reading structure: version control, typed interfaces, package managers, dependency graphs, code review, CI. Engineers built all of it for themselves, long before there was a model to feed.

AI inherited that surface. The inheritance is what made the productivity gains real.

The world AI for data actually walks into

Now consider what an agent meets when it reasons over enterprise data.

The same metric is often defined three ways. Finance calculates it one way for reporting. Sales calculates it another for targets. The warehouse has a third version baked into a table. Nobody flagged the conflict, because each team was right inside its own context.

This isn't hypothetical. It's the normal condition of most organisations.

The data team's context system is usually hand-stitched: one tool for metrics, another for governance, a wiki for documentation, a custom bridge for AI access, and a chat channel holding the decisions nobody wrote down. No shared data model. No shared ontology. No shared audit trail.

An agent dropped into that returns whichever answer it reaches first. Confident, fast, and often wrong.

The accuracy gap that should settle the model debate

Text-to-SQL benchmarks tell this story cleanly, and the gap between two kinds of benchmark is the whole argument.

On clean academic benchmarks, with well-documented schemas and tidy tables, frontier models perform very well. On benchmarks built from real enterprise schemas, carrying the ambiguity and overlapping definitions and implicit business logic that production data always has, the same models fall off a cliff.

Same model, same intelligence, radically different result on what looks like the same task. Ground those queries in a structured semantic layer that encodes governed definitions and the relationships between concepts, and accuracy recovers.

The lift comes from the layer underneath the model. Intelligence without grounding is guessing at scale, and no future model release fixes that.

We have been here three times

The uncomfortable part is that the industry has hit this same wall three times in a row.

Yesterday, it was context for people. Metadata scattered across catalogs, lineage tools, quality tools and governance silos, with every team stitching its own view. The industry spent a decade building metadata platforms and made real progress toward a unified graph.

Today, it is the same fragmentation in semantics. Every major tool ships a semantic layer. Every AI tool ships its own. The same word means different things in different places, business meaning drifts, and nobody can predict which definition the next agent will pick up. This is the metadata problem rebuilt one level higher, and it costs more this time, because an agent doesn't pause to ask a colleague what a field means.

Tomorrow, it will be memory. Every agent a team builds keeps its own preferences, history and feedback. Nothing is shared. A correction an analyst makes on Tuesday doesn't reach the agent deployed on Friday. Six agents in, no two agree on a core metric, and one definition change forces six rebuilds.

The lesson from yesterday applies to both: solve it once, at a shared layer, not separately inside every tool.

Why every vendor suddenly sounds the same

Attend any data conference now and you'll hear one word replacing all the others. The word is context.

That shift is healthy. The conversation has moved from whose model is bigger to what surrounds the model. But "context," as most vendors use it, means what data already says about itself: schema, lineage, quality signals, freshness, ownership. That describes what data is. It says nothing about what it means, or what your organisation has already learned about it.

Context is one of three things, not all three.

Context is a unified, machine-readable view across every source, the actual shape of your enterprise rather than a sample.

Semantics is the formal modelling of business meaning, so an agent reasoning about a metric lands on the governed definition instead of the closest matching column name.

Memory is the auditable record of corrections and decisions, so the next agent inherits what the last one learned.

They only work together. Context without semantics is a well-described inventory the agent still doesn't understand. Semantics without context is an abstraction with nothing to bind to. Memory without either is a log of corrections nobody can apply.

A platform that ships context alone is a third of the problem solved under a new name. It holds up until the third or fourth agent starts reasoning over conflicting definitions.

How this kind of infrastructure always arrives

There's a reassuring pattern here, and it's worth naming because it tells you what to do next.

Most transformative enterprise infrastructure arrived the same way. A company with unusual scale hits a problem nothing on the market solves. They build something custom and largely undocumented. It proves out under real load. The industry recognises the shape and standardises around it.

Hadoop came out of Google's file system and MapReduce papers by way of Yahoo. Kubernetes came out of Borg. Kafka came out of LinkedIn, Cassandra out of Facebook. In each case the frontier proved the architecture and the ecosystem made it available to everyone else.

The context layer is at that second stage now. The expensive architectural work has been done, which means the rest of us get to learn from it rather than rediscover it.

Foundation first, then the experience

The architecture that works has two halves, and the order is the whole point.

The foundation is an open context layer: every source connected into one machine-readable graph, business meaning formalised across metrics and entities and hierarchies, and every decision about that meaning captured as a permanent, reusable object. Three primitives designed together rather than bolted to each other later.

It should sit on open standards, so any model and any tool can read it without a proprietary adapter. The substrate underneath enterprise AI shouldn't belong to one vendor. Models and clouds are choices you remake every year on cost and capability. The context layer is the constant underneath them, and built right it survives every model release and every migration.

The experience layer sits on top: conversation instead of navigation, agents that classify and document and govern at scale, questions answered in plain language against governed definitions, and memory that carries a Tuesday correction into a Friday deployment.

Code built its substrate first, painstakingly, over two decades. The AI workflow arrived in the last three years and stood on it. Reverse that order, point a model at raw ungoverned data, and you get the accuracy collapse described above.

The part worth pausing on

The organisations building the world's most capable models have every incentive to believe a better model solves everything. They still had to build a context layer around the model to make it work on their own internal data.

One frontier lab runs an internal data agent serving thousands of employees at enormous scale, on the same models its customers use. What makes it work isn't the model. It's the layers around it: schema metadata and lineage, curated descriptions from domain experts, definitions extracted from pipeline code, institutional knowledge pulled out of chat, a memory layer that applies past corrections to future answers, and live runtime validation.

Another team published its own internal analytics results, along with a diagnosis that matches exactly: entity ambiguity, stale data, retrieval failure. Their fix was governed datasets, a semantic layer of compiled metrics, and structured procedural knowledge on top. Without that layer, accuracy on their own data was poor enough to be unusable. With it, reliable.

They also tried the obvious shortcut, handing the agent raw access to every query and dashboard and transformation ever written. It barely helped. The bottleneck was never access to prior work. It was the structure that lets an agent map a question to the right governed answer.

If the companies that built the best models in the world couldn't skip this step, nobody else gets to either.

Build it, or start where they finished

Building your own is viable if you have the bench for it: a team that can maintain a multi-layer agentic stack, run adversarial review on its own outputs, and keep a skills inventory under continuous integration. Most organisations don't have that, and shouldn't need it in order to ask a question about their own revenue.

The alternative is to start where the frontier teams ended up. That's the bet behind DQHQ. The context layer is the product, not a thing every company rebuilds from scratch.

Whether the layer is necessary is settled. The only open question is who builds it.

The order is the lesson

Every enterprise AI deployment that works follows the same sequence: open context layer first, AI for data on top of it.

The stalled ones tried to build both at once on a foundation that wasn't ready, or skipped the substrate and pointed a model at raw schema.

Code took twenty years to build its foundation. Data doesn't have twenty years. But the shape of what has to be built is clear now, and so is the order.