In early 2026, the phrase “context graph” went from niche architecture discussion to vendor marketing headline in the span of weeks. Every major metadata platform updated its positioning. New content hubs appeared. Event registrations opened. The trillion-dollar opportunity framing — drawn from a Foundation Capital thesis published in January — gave the category a number large enough to anchor a product narrative. What it did not give vendors was the architecture to back that narrative up.
The category capture is deliberate and sophisticated. Atlan’s co-founder published a direct response to the Foundation Capital thesis, conceding the importance of context graphs while arguing that heterogeneity — the fact that every enterprise runs a different combination of systems — makes metadata platforms the natural integrators. The argument is partially sound. The conclusion it leads to is not. Understanding why requires being precise about what metadata platforms actually do, what context graphs actually require, and why those are different problems that share some vocabulary but almost no architecture.
This is not an argument that metadata platforms have no value. They do — real, substantial, production-grade value. It is an argument about what that value is and where it stops. The enterprise that buys a metadata platform thinking it has acquired a context graph platform has purchased the wrong answer to a question it may not yet know how to ask.
What Metadata Platforms Actually Do
Metadata platforms — Atlan, Collibra, Alation, and the catalog category broadly — are built to solve a specific and genuine problem: enterprises accumulate enormous data estates across warehouses, BI tools, pipelines, and business applications, and without systematic cataloging, those assets become ungoverned, undiscoverable, and untrustworthy. The platforms that emerged to solve this problem do several things well.
They crawl data assets continuously and build lineage — tracking how data flows from source systems through transformations into the tables and dashboards that inform decisions. They propagate context bidirectionally, pushing descriptions, quality scores, and ownership signals into the tools where analysts actually work. They maintain business glossaries that give shared definitions to contested terms. The better platforms do this at scale, across dozens of connected systems, with enough automation to keep the catalog from going stale the moment someone stops manually curating it.
What Metadata Platforms Observe
Data asset context: schemas, lineage, column-level transformations, BI definitions, SQL query history, quality scores, usage patterns, ownership, and access policy. All of this is context about data — the technical and semantic fabric of the data estate.
This is valuable infrastructure. It is also one specific kind of context, solved by one specific architectural approach: observation and cataloging from outside the execution path.
That last phrase is the load-bearing one. Metadata platforms sit outside the write path. They observe what happens in data systems — they do not intercept, transform, or participate in execution. They crawl after the fact. They propagate context into other tools, but they do not sit between a user and the data engine reshaping what that user sees. This is a deliberate architectural choice, not a limitation to be roadmapped away. It is what allows a metadata platform to connect to dozens of systems without becoming responsible for the execution logic of any of them.
Being outside the write path is also precisely what prevents a metadata platform from becoming a context graph platform — because context graphs require something that only becomes possible from within the execution flow.
What Context Graphs Actually Require
The Foundation Capital thesis — and the substantial discussion that followed it — identified the core problem accurately. Enterprise AI agents fail not because models are weak but because they lack the decision context that makes organizational knowledge operational. The canonical example is instructive: an agent proposes a renewal discount that exceeds policy. A human would know that a VP exception was granted last quarter for a similar situation, that the policy was written before the current service-impact framework existed, and that Finance has a soft precedent for exactly this customer tier. The agent knows none of this. It has data. It does not have decision context.
Your data warehouse knows everything that happened. It has no idea why — and that gap is precisely where enterprise AI agents go wrong.
Context graphs are proposed as the architecture that closes this gap. A context graph is not a data catalog with a graph database underneath it. It is a queryable record of how decisions were actually made — who decided, under what constraints, invoking which precedents, producing which outcomes — stitched across entities and time so that the “why” behind organizational choices becomes as accessible as the “what.”
Building that requires solving what we call the dual-capture problem: context graphs must ingest two fundamentally different types of artifacts. The first is structured decision traces from agent systems — machine-generated, schema-consistent records of what the agent evaluated, what policy it applied, and what it produced. The second is unstructured human decision context — the exception logic that lives in a VP’s email, the precedent established in a Slack thread, the approval granted on a call that never produced a ticket.
Data Asset Context
Column lineage across warehouse and BI systems. SQL query history. Schema ownership. Quality scores. Business glossary definitions. Usage patterns from analysts and dashboards.
Connectors point at: Snowflake, BigQuery, Databricks, Looker, dbt, Tableau, Airflow.
Observation LayerDecision Context
Structured agent decision traces. Human exception logic from email, Slack, and approval workflows. Precedent from past choices. Cross-system synthesis at the moment decisions are made.
Sources include: agent orchestration layers, communication platforms, approval systems, meeting records.
Decision LayerMetadata platforms have no connectors into the channels where human decisions happen. Their 80-plus integrations point at data infrastructure — warehouses, pipelines, BI tools. The Slack thread where a VP approved a policy exception, the email chain that established a pricing precedent, the meeting where a compliance override was granted — none of these are in scope for a metadata platform’s crawler. They are not a gap to be closed with a product update. They are outside the problem the platform was designed to solve.
On Atlan’s Slack Integration
Atlan does have a documented Slack integration — the kind of thing that surfaces in a vendor conversation as evidence of communication channel connectivity. What it actually does: push catalog alerts into Slack channels and allow users to query the Atlan catalog via an @Atlan bot command. Atlan’s own CIO guide also describes using Slack as a manual logging prompt — a reaction emoji that triggers an MVDT form for a user to fill out. That is a human deliberately initiating a structured form from within Slack, not automated capture of Slack conversations as decision context. The integration does not read Slack conversations, monitor channels for decision-relevant content, or extract rationale or approval logic from any message not explicitly directed at the bot. Private channels — where most sensitive decisions happen — are explicitly unsupported. The direction of information flow remains the same in both use cases: Atlan reaching into Slack, not Slack feeding into the context graph.
The Heterogeneity Argument Is Real — and Insufficient
Atlan’s co-founder made the most substantive case for why metadata platforms should own context graphs: enterprises are heterogeneous. A single renewal decision may require context from a CRM, a support ticketing system, a usage analytics platform, a communication tool, and a semantic layer — and every enterprise runs a different combination of those systems. Vertical agent startups, the counterargument goes, see one workflow deeply but cannot stitch context across the full enterprise stack. The integrator wins.
This argument is correct about the heterogeneity problem. It is misdirected about which heterogeneity it solves.
Metadata platforms have built real breadth in data infrastructure connectors. That breadth addresses heterogeneity in the data estate — the varying combinations of warehouse, BI, and pipeline tools enterprises run. It does not address heterogeneity in decision channels — the varying combinations of communication platforms, approval workflows, and agent orchestration layers where organizational decisions are actually made and where the context graphs must capture them.
A metadata platform’s connector advantage lives entirely within the data infrastructure layer. The channels where human decisions happen — Slack, email, meeting platforms, approval workflows — are not adjacent to that infrastructure. They are a different problem space that requires a different connector strategy, a different extraction architecture, and a different persistence model. Breadth in one domain does not transfer to the other.
There is a second, sharper limit. Even if a metadata platform extended its connectors into communication channels and could pull from Slack and email, it would still face an extraction problem that no connector solves: most enterprise decisions do not produce clean artifacts. A verbal VP approval, a judgment call made between meetings, an exception granted as institutional tribal knowledge — these generate no residue in any system. Extraction from unstructured communication is possible where the communication exists. It cannot recover what was never recorded.
Where Metadata Platforms Legitimately Belong
None of this makes metadata platforms irrelevant to context graph infrastructure. It makes them a specific layer within an ecosystem that requires at minimum three distinct layers to function.
The first layer is the data asset reference layer — lineage, schema, semantic definitions, quality, and governance policy. This is the territory metadata platforms own and do well. A context graph needs to know what “revenue” means, which table is authoritative, and who owns the pipeline. Metadata platforms provide that reference foundation. They are not the graph. They feed it.
The second layer is the decision capture layer — the connectors, extraction pipelines, and graph persistence infrastructure that turns human decisions and agent traces into queryable nodes and edges. This layer does not exist as a commercial product today. Metadata platforms have no role here. Agent orchestration platforms have partial visibility into the machine-generated trace half. The human decision half — the connectors into communication channels, the LLM extraction of unstructured context, the schema for what a decision record contains — is genuinely unbuilt.
The third layer is the intelligence layer — the feedback loop that turns accumulated decision traces back into improved architecture, better recommendations, and compounding organizational learning. This is where the trillion-dollar opportunity actually lives. It requires the first two layers to be in place before it becomes achievable.
of enterprise AI pilots deliver zero measurable ROI, according to MIT’s 2025 State of AI in Business study. The root cause is consistently identified as insufficient context — not model capability. Metadata platforms address the data context half. The decision context half remains largely unsolved.
The market positioning emerging in early 2026 collapses these three layers into one claim. Vendors who have genuinely solved layer one — and solved it well — are presenting themselves as solutions for layers two and three. The enterprise buyer evaluating “context graph platforms” in 2026 is often comparing products that operate exclusively in layer one while speaking the vocabulary of all three.
What This Means Before You Buy Anything
The practical implication is a due diligence question that most vendor conversations will not surface on their own: which type of context does this platform actually capture, and through which mechanisms?
A metadata platform will show you column-level lineage, SQL query history, and BI definition propagation — all real, all valuable, all firmly in the data asset context category. Ask the same platform to show you how a VP’s approval exception in a Slack thread becomes a node in the graph with a queryable rationale and a link to the downstream decision it influenced. The answer will be a roadmap item, a partner integration, or a reframe of the question.
That gap matters operationally because the decisions where AI agents most need context — the pricing exception, the compliance override, the policy deviation that became a precedent — are exactly the decisions that lived in communication channels, not data systems. Buying layer one while believing you have purchased layers one through three does not close the gap. It adds a catalog to a problem that requires a different architecture.
Show me a decision that was made in a Slack approval thread six months ago. Show me how that decision became a structured node in your graph — who approved it, under what constraints, linked to the downstream outcomes it produced. Show me how an agent queries that precedent today. If the answer requires a human to have manually entered that information, you have a catalog. You do not have a context graph.
Metadata platforms are not failing to be context graph platforms. They are succeeding at being metadata platforms — a category with genuine, substantial value that enterprises need and that is poorly served by a market that has started calling it something else. The confusion is the problem. Clarity about what each layer does, and who currently builds it, is the starting point for enterprise AI architecture that will actually work.
The upstream question — what has to be true before a context graph has anything meaningful to capture — is where the conversation needs to go next. That is what Part 2 of this series examines.
