Walk any data conference floor right now and count the booths that mention context. Context-aware AI. Context layer. Context graph. Context-driven observability. You’ll lose count before you reach the coffee station.
I’ve seen this movie before. Three years ago, the word was observability. Every tool suddenly “did observability.” Most meant alerts. A few meant dashboards. Almost none meant genuinely understanding the end-to-end health of your data in a way that mapped to business reality. The word became so diluted it stopped meaning anything useful — yet the underlying problem it pointed at was real and urgent.
Context is following the exact same arc. Except this time the stakes are higher. We are not building dashboards for humans to sanity-check. We are building agents that act. Agents that act on bad context don’t just mislead you — they mislead you at scale, continuously, and confidently.
So before we hand the keys over, let’s agree on what context actually is, who’s responsible for it, and — most importantly — who is responsible when it goes wrong.
The Vocabulary Problem
There is a serious conflation happening in the industry right now, and it is going to cost people. When vendors say “context,” they typically mean one of three very different things.
Technical context: Schema, lineage, freshness, volume, format, upstream and downstream dependencies. What the data is. This is the floor. It’s also what most tools mean when they say context.
Business context: What the data means. Which KPI it feeds, who owns it, which process it enables, what SLA it carries, what the business consequence of a failure looks like. A pipeline breaking at 2am is noise. A pipeline breaking at 2am that feeds your CEO’s board report is a crisis. Same technical event. Completely different meaning.
Decision context: Why we did what we did. We priced that deal at a 40% discount — not because of company size, but because of a specific competitor at a specific moment in our fundraise, with executive relationship logic that isn’t in any schema. We approved that underwriting exception because the broker had 15 years of comparable risks that all performed. This is institutional reasoning. It lives in people’s heads. And it can only be captured prospectively, as exhaust of real work.
Most “context layers” being built today solve the first problem. A few solve the second. Almost none touch the third. And agents need all three.
A Recent Benchmark: What OpenAI Actually Built
In January 2026, OpenAI published a detailed write-up of their internal data agent — a system that reasons over 600+ petabytes and roughly 70,000 datasets, used by 4,000 employees daily. It is genuinely impressive engineering and worth reading carefully. But it is also the clearest illustration I’ve seen of exactly where the industry’s thinking currently stops.
OpenAI’s agent draws on six context layers: basic schema metadata, Codex-enriched lineage inferred from pipeline code, curated expert descriptions, institutional knowledge mined from Slack and Docs, human annotations and corrections, and learned memory from past queries.
Read those six layers carefully. Every single one is about collecting context — ingesting metadata, crawling pipelines, mining Slack, storing corrections. They are all inputs. What OpenAI does not describe — and what the industry broadly is not solving — is a layer that asks: how do we know any of this is still true?
OpenAI notes that table discovery across 70,000 candidates is “the biggest problem” with the agent. They solve it with vector embeddings and Codex enrichment. But enrichment is a point-in-time operation. Pipelines change. Ownership changes. Definitions evolve. The enriched context from last quarter may be confidently wrong today.
There is no mention of staleness detection on metadata. No trust scoring on curated descriptions. No alert when an owner leaves the company. The agent assumes its context is good. At 70,000 tables and 600 petabytes, that assumption will break.
Data Context vs. Decision Context: The Distinction That Will Define the Next Five Years
Beyond the reliability gap, there is a more fundamental distinction the industry is conflating. People building “context layers” are largely solving for semantic accuracy — making sure agents know what words mean, where data lives, how metrics are defined. That’s valuable. But it is not the same as making agents institutional.
The four dimensions where they differ fundamentally:
Capture mechanism. Data context can be built retroactively — crawl your dbt models, fill the gaps. Decision context can only be captured prospectively, as exhaust of real work. The rep’s annotation on a modified proposal. The underwriter’s override reason. Miss the moment, lose the trace forever.
Decay rate. Data context is slow-moving — a metric definition may be stable for years. Decision context is fast-decaying — last Tuesday’s exception is the precedent for next Tuesday’s decision. These operate on completely different clocks.
Ownership. Data context lives with data teams and platform engineering — centralised, governable. Decision context lives at every workflow surface where agents and humans interact: sales escalations, underwriting queues, legal review, support triage.
Moat. A better semantic layer is a project — completable, transferable, eventually commoditised. Decision traces are a compounding asset. Every decision makes the next one more accurate. Impossible to replicate retroactively.
Walk any data conference floor right now and count the booths that mention context. Context-aware AI. Context layer. Context graph. Context-driven observability. You’ll lose count before you reach the coffee station.
I’ve seen this movie before. Three years ago, the word was observability. Every tool suddenly “did observability.” Most meant alerts. A few meant dashboards. Almost none meant genuinely understanding the end-to-end health of your data in a way that mapped to business reality. The word became so diluted it stopped meaning anything useful — yet the underlying problem it pointed at was real and urgent.
Context is following the exact same arc. Except this time the stakes are higher. We are not building dashboards for humans to sanity-check. We are building agents that act. Agents that act on bad context don’t just mislead you — they mislead you at scale, continuously, and confidently.
So before we hand the keys over, let’s agree on what context actually is, who’s responsible for it, and — most importantly — who is responsible when it goes wrong.
The Vocabulary Problem
There is a serious conflation happening in the industry right now, and it is going to cost people. When vendors say “context,” they typically mean one of three very different things.
Technical context: Schema, lineage, freshness, volume, format, upstream and downstream dependencies. What the data is. This is the floor. It’s also what most tools mean when they say context.
Business context: What the data means. Which KPI it feeds, who owns it, which process it enables, what SLA it carries, what the business consequence of a failure looks like. A pipeline breaking at 2am is noise. A pipeline breaking at 2am that feeds your CEO’s board report is a crisis. Same technical event. Completely different meaning.
Decision context: Why we did what we did. We priced that deal at a 40% discount — not because of company size, but because of a specific competitor at a specific moment in our fundraise, with executive relationship logic that isn’t in any schema. We approved that underwriting exception because the broker had 15 years of comparable risks that all performed. This is institutional reasoning. It lives in people’s heads. And it can only be captured prospectively, as exhaust of real work.
Most “context layers” being built today solve the first problem. A few solve the second. Almost none touch the third. And agents need all three.
A Recent Benchmark: What OpenAI Actually Built
In January 2026, OpenAI published a detailed write-up of their internal data agent — a system that reasons over 600+ petabytes and roughly 70,000 datasets, used by 4,000 employees daily. It is genuinely impressive engineering and worth reading carefully. But it is also the clearest illustration I’ve seen of exactly where the industry’s thinking currently stops.
OpenAI’s agent draws on six context layers: basic schema metadata, Codex-enriched lineage inferred from pipeline code, curated expert descriptions, institutional knowledge mined from Slack and Docs, human annotations and corrections, and learned memory from past queries.
Read those six layers carefully. Every single one is about collecting context — ingesting metadata, crawling pipelines, mining Slack, storing corrections. They are all inputs. What OpenAI does not describe — and what the industry broadly is not solving — is a layer that asks: how do we know any of this is still true?
OpenAI notes that table discovery across 70,000 candidates is “the biggest problem” with the agent. They solve it with vector embeddings and Codex enrichment. But enrichment is a point-in-time operation. Pipelines change. Ownership changes. Definitions evolve. The enriched context from last quarter may be confidently wrong today.
There is no mention of staleness detection on metadata. No trust scoring on curated descriptions. No alert when an owner leaves the company. The agent assumes its context is good. At 70,000 tables and 600 petabytes, that assumption will break.
Data Context vs. Decision Context: The Distinction That Will Define the Next Five Years
Beyond the reliability gap, there is a more fundamental distinction the industry is conflating. People building “context layers” are largely solving for semantic accuracy — making sure agents know what words mean, where data lives, how metrics are defined. That’s valuable. But it is not the same as making agents institutional.
The four dimensions where they differ fundamentally:
Capture mechanism. Data context can be built retroactively — crawl your dbt models, fill the gaps. Decision context can only be captured prospectively, as exhaust of real work. The rep’s annotation on a modified proposal. The underwriter’s override reason. Miss the moment, lose the trace forever.
Decay rate. Data context is slow-moving — a metric definition may be stable for years. Decision context is fast-decaying — last Tuesday’s exception is the precedent for next Tuesday’s decision. These operate on completely different clocks.
Ownership. Data context lives with data teams and platform engineering — centralised, governable. Decision context lives at every workflow surface where agents and humans interact: sales escalations, underwriting queues, legal review, support triage.
Moat. A better semantic layer is a project — completable, transferable, eventually commoditised. Decision traces are a compounding asset. Every decision makes the next one more accurate. Impossible to replicate retroactively.
.jpg)
-p-500.png)
