The model was never the bottleneck

The expectation was that better models would solve enterprise data. More parameters, more training, and agents would eventually work out what your tables mean.

That isn't what happened. The teams who got AI working reliably against real enterprise sprawl, serving thousands of internal users, keep reporting the same thing: the model was rarely the limiting factor. What surrounded the model was.

That changes what you should be building.

Access is not understanding

The intuitive fix is volume. Give the agent everything. Every query anyone has ever written, every transformation, every notebook. Let it infer the rest.

It doesn't work, and the reason is instructive. The constraint was never how much the agent could see. It was that none of what it saw carried explicit meaning. A thousand historical queries against a table tell an agent how people have used it. They don't tell it what the table is.

Layer structured context over the same model, with defined semantics, governed metrics and validated skills, and reliability changes materially. Same weights. Different grounding.

Three things the model can't supply

Teams describe this differently, but the architecture keeps converging on the same three pieces.

Context is a unified view across every source and connector, so the agent reasons over the actual shape of your enterprise rather than a sample or a stale snapshot. It answers: what exists, how is it connected, what does it look like right now. Without it, agents work on fragments. They see tables but not relationships, columns but not lineage.

Semantics is an ontology that gives data business meaning rather than just structure. A column called rev_amt isn't revenue until someone defines what revenue means here, and that definition has to be explicit, governed and queryable. It answers: what does this mean, according to the people who own it. Without it, agents infer meaning from column names and produce answers that look plausible and are wrong in ways nobody catches.

Memory is an auditable record of every correction, classification and decision, captured once and inherited everywhere. It answers: what have we already learned, and does it apply here. Without it, every interaction starts from zero and the same mistakes repeat, because nothing recorded that they were mistakes.

None of this is a product. It's an architecture, and it's the part that determines whether AI on your data is dependable or merely impressive in a demo.

We have watched this happen before

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 pattern 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 can learn from it rather than rediscover it.

Build it or adopt it

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 to ask a question about their own revenue.

The alternative is to start where the frontier teams ended up. This is 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.

What it looks like day to day

For data and platform teams, it's ingestion connectors that keep metadata current, column-level lineage so the agent understands how data flows, automated profiling that surfaces structure without anyone writing documentation, and a metadata graph the agent can query directly.

For governance teams, it's metric definitions that encode business meaning once and enforce it everywhere, plus glossary relationships and classifications that make semantics queryable rather than tribal.

For everyone else, it's asking a question in plain language and getting an answer computed against approved definitions, along with the receipts: which tables, which definitions, which filters.

The goal is that people need to be business-literate rather than data-literate to get a reliable answer. That only holds if the layer underneath is doing its job.

The bet

Context, semantics and memory beat tokens and parameters on enterprise data.

AI for code inherited a context layer that engineers had spent a decade building without calling it that: the IDE, the type system, the dependency graph, the commit history. Coding assistants work as well as they do because all of that was already there.

AI for data never had an equivalent. That's the gap, and it's the reason a larger model keeps not being the answer. The model isn't the product. What surrounds it is.