Data Governance & AI – 6 min read
Imagine asking an AI agent, “What was our revenue last quarter?” The agent reaches the data easily and answers confidently within seconds. But the finance system defines revenue as the invoiced amount, the sales system as the signed contract value, and reporting as annual recurring revenue. The agent picks one of these and is most likely wrong.
This error isn’t caused by a weak model. The agent sees what the data is, but it doesn’t know what it means, which rule it was calculated by, or what decisions have been made about it in the past. In recent months, a name has started to take hold for the layer that fills this gap: context graph.
In this post, we explain what a context graph is, why it’s getting so much attention, and how organizations can extract real value from this opportunity.
In short
What is a context graph?
Jaya Gupta and Ashu Garg of Foundation Capital introduced the concept to a wide audience in December 2025. Their thesis is actually quite simple: systems of record such as CRM, ERP, and accounting systems capture what the data is, but not why a decision was made (Foundation Capital).
Think about why a customer was given an extra discount, who approved an exception, or under what circumstances a rule was bent. This information usually lives in an email thread, a meeting note, or the memory of an experienced employee. Gupta and Garg call these decision traces. When decision traces are linked together, the resulting structure forms a context graph.
According to the authors, this structure will enable AI agents to truly understand how an organization works, and it will be the software world’s next trillion-dollar opportunity. This claim sparked the real debate in the industry: Who will capture the value from this opportunity?
Fragmentation is moving from data to agents
According to Foundation Capital’s thesis, this value will be captured by vertical AI agents that operate within a specific workflow, because they sit where decisions are made. Prukalpa Sankar, co-founder and CEO of Atlan, agrees about the opportunity but disagrees with this conclusion (Atlan). At the heart of Sankar’s objection is the fragmented nature of organizations.
In recent years, tool sprawl in the data world has started to shrink thanks to open table formats. But the same fragmentation is now reappearing one layer up, in AI agents. Organizations are deploying hundreds of agents, and each one sees only a piece of the context.
Consider a simple example. Even a contract renewal decision depends on support tickets, customer history in the CRM, product usage data, internal communications, and metric definitions. An agent working within a single workflow sees only its own corner of this picture. Sankar sums it up in one sentence: Decisions are made locally, but the context they require spans the entire organization.
That’s why building context into each agent separately isn’t sustainable. The smarter approach is to gather context across systems once and have every agent read from the same source.
The two halves of context
Context isn’t a single piece. Building on Tomasz Tunguz’s distinction, Sankar describes context as two interconnected halves.
Operational context describes how the organization gets work done. Procedures, policies, approval rules, exceptions, and the reasoning behind past decisions all belong to this half. A rule such as “Discounts above a certain rate for customers in this segment can only be granted with the finance director’s approval” is operational context.
Analytical context, on the other hand, describes what the data means. Metric definitions, the business glossary, and calculation logic are part of this half. Analytical context is what teaches the agent the difference between revenue, bookings, and annual recurring revenue.
The two halves aren’t independent of each other. To evaluate a discount decision correctly, you need to know both the approval rule and the customer’s actual revenue contribution. When AI agents can’t access both halves together, they can read the data but can’t interpret it.
Context gains value over time
The most powerful thing about context is that it grows the more it’s used. When an agent works with the right context, it gives the right answer. Right answers build user trust, and users who trust the agent use it more often. More usage brings more feedback, and that feedback enriches the context even further.
This cycle has one condition: context must be kept in a single place with clear ownership. If context is built by hand for each project, it goes stale once the project ends and has to be rebuilt for the next agent. When it’s kept in a shared layer, however, context is largely collected automatically from systems, every agent reads from the same source, and maintenance remains the organization’s own responsibility. In Sankar’s words, this is the shift from “context engineering” to a “context platform.”
What should a good context layer be able to do?
Sankar lists six core requirements for a layer that can carry context across the organization. They can also be read as a checklist an organization can use to assess its own readiness:
One thing stands out when you look at this list. At least four of the six items are topics organizations have been working on for years under the name of data governance. The context graph is a new concept, but its ingredients are familiar: metadata, business glossary, data ownership, lineage, and access rules.
For us, the most important point in the context graph debate is this: the building blocks of the context layer, namely metadata, business glossary, data ownership, lineage, and access rules, are the domain of data governance. When these foundations aren’t solid, AI agents built on top of them can’t be expected to give consistent answers.
At Nexa, we approach data governance end to end. We first work with organizations to design a governance framework made up of roles, ownership, processes, and policies. We then select the technology that fits this framework, without being tied to any particular product. On the chosen platform, we implement metadata management, the business glossary, data lineage, and personal data classification. When needed, we also take over operating the platform after implementation.
As AI agents become more widespread, the scope of governance is expanding too. Our approach is to carry the experience built up in data governance over to AI agents. In this approach, agents are inventoried just like data assets; which data can be shared with which agent and for what business purpose is defined; and these rules are enforced at runtime as well. This way, data governance and AI governance don’t remain two disconnected domains.
The first step is to see how big your context gap is. To do that, you can ask yourself three questions.
If you answer “no” to any of these questions, even the best model will be forced to guess. Your answers to these questions show where your context gap begins and which areas need improvement.
Let’s evaluate your current governance structure and AI goals together with our experts in a short call and identify the first steps to take. [Schedule a call →]
Sources
