In March, Jason Cui and Jennifer Li published Your Data Agents Need Context on the Andreessen Horowitz website, a16z. It is the clearest account I have read of why “chat with your data” kept failing, and its central argument is right: an agent that cannot resolve what a number means will confidently produce the wrong one.
Their example is a good one. Ask an agent about revenue growth last quarter and it has to know whether revenue means run rate or ARR, when your fiscal quarter starts, and which of several revenue tables is the one the business actually trusts. Their answer is a context layer — canonical definitions, identity resolution, business logic — built above the warehouse and exposed to agents over an API or MCP.
I think that layer is necessary and I think it is coming. But reading the piece a second time, two of the questions it raises are not data questions at all, and no semantic layer will answer them.
The first question: who knows the thing that was never written down
The a16z piece describes the human refinement step — domain experts adding the implicit knowledge that automated extraction cannot infer. Their example is conditional and specific: use one CRM for one region and period, an older one for everything before that.
That is exactly right, and it is the step every context project dies on.
The knowledge is real, and it is unwritten for a reason: the person holding it has no particular incentive to write it down. Documentation projects ask practitioners to spend their time producing an artifact whose benefit accrues to somebody else — a governance team, a platform team, an agent that does not exist yet. So it does not get written, or it gets written once during a migration and is never touched again.
You cannot solve that with better extraction. It is not an extraction problem. It is a question of whether the person who knows has any reason to record it.
The second question: what happens when they leave
The same piece notes that semantic layers go stale — abandoned by departed team members, missing new product lines.
That sentence is doing more work than it looks. A semantic layer does not decay because the SQL rots. It decays because one person maintained it, that person left, and nobody knew they owned it. By the time anyone notices, the definitions are describing a business that no longer exists.
And it will happen again to the context layer that replaces the semantic layer, for the same reason, unless something records who owns what and what depends on it.
Both questions are about the work, not the data
There are two kinds of context here, and the industry is only building one.
Data context is what a16z describes: what the numbers mean. Canonical definitions, entity resolution, business logic. It lives close to the warehouse, and it is what a semantic or context layer is for.
Work context is the other half: which analytical work actually serves a decision, who owns it, what it depends on, what breaks when it changes, and what value is attached to it. It lives across dashboards, notebooks, spreadsheets, queries and models — and mostly in the heads of the people who made them.
An agent needs both. Ask it what drove revenue growth and data context tells it which table is authoritative. Work context tells it that three of the four revenue assets in the estate are one analyst’s exploratory work, the fourth is the one the executive dashboard actually reads, and the person who built it left in April.
Two and a half minutes: the same revenue question, walked through a real workspace. Representative sample data; metadata only.
Doing it once, or doing it so the next project is cheaper
Most teams that get an agent into production do capture work context. They just do it manually, as a one-off, inside the project. This is neither hypothetical nor quick, even for the best teams.
When OpenAI built its own internal data agent — now used by several thousand of its employees — two engineers shipped it in about three months, with Codex generating more than 70% of the code. The interesting part is not the speed. It is what they had to build alongside the model. Their context layers reach past schema metadata into institutional knowledge pulled out of Slack, Google Docs and Notion, and they run a daily automated pass over important tables that works out upstream and downstream dependencies, ownership, granularity and join keys.
That is work context. They did not call it that, and they had to make it themselves. If that is the cost with OpenAI’s engineers and OpenAI’s models, it is not lower for a mid-size analytics team assembling the same picture by hand.
And it rarely transfers. The interviews were conversations, the findings live in a document that is already going stale, and the ownership map was never written down anywhere durable. So when the second project starts in another function, much of the work happens again.
MIT’s Project NANDA put numbers on where that leads. Its 2025 study of enterprise GenAI found that around 95% of pilots produced no measurable P&L impact, that the shortfall was not model quality, and that approaches built on purpose-built or partnered tooling outperformed internal do-it-yourself builds. The cause it identifies is the absence of learning and memory in deployed systems — which is another way of saying that the context was assembled once, for one project, and never became anything the organization could reuse.
This is the part I would push furthest on the a16z argument. Their step two proposes using LLMs to extract context from query histories, dbt models and documentation. Extraction is the cheap part; deciding what to point it at is not. In a mid-size estate, most models and most query history describe work that no longer matters, and feeding all of it to a model produces an expensive, confident, subtly wrong corpus.
Knowing which two hundred assets serve real decisions — before extraction runs — is what makes the automated half work. And that knowledge is worth capturing once, durably, rather than rediscovering per project.
What this looks like in practice
This is the layer MyDataWork builds, and it is deliberately not the layer a16z describes. We do not resolve metric definitions, and we never read data values, file contents or query results. What we catalog is the work: assets across every tool, the use cases they serve, the stakeholders who depend on them, inferred lineage with a confidence tier and a plain-language reason, and the value attached to each outcome.
The reason this gets maintained where documentation projects do not is that the practitioner gets the benefit first. Finding your own work, tracing what breaks before you change it, showing what your work is worth at review time — those pay off immediately, for the person doing the recording. The portfolio view and the agent-ready context accumulate as a byproduct.
And when an agent is finally ready to consume it, it goes over MCP: scoped per use case, opt-in, revocable, audited, and metadata-only — asset names, tool types, structural schema, lineage and outcomes. Never values, never contents, never stakeholder names.
Where to start
If you are scoping an agentic project, the useful question is not whether you have a context layer. It is whether the work the agent will reason about is written down anywhere but in someone’s head.
What would an AI agent find in your estate today?
A two-minute check. No email, no score to argue with — it tells you what an agent would run into, and what is worth fixing first.
Assess your agentic AI trust gap now →If you would rather see it on your own estate, Explorer is free for ninety days with no credit card.
Cui and Li are right that data agents need context. The half they describe is being built by serious companies and will arrive. The other half — who owns this, what does it serve, what breaks if it changes — is the half that decays fastest, because it lives in people. It is worth capturing before the agent needs it, not during.
