On Knowledge Graphs and Context Graphs
Enterprises racing to build out knowledge graphs and context graphs are only capturing one-third of the agentic relationship. Real value co-creation will emerge once the complete picture is in sight.
The conversation about knowledge graphs and context graphs in enterprise AI has matured quickly over the last several months. With industry analysts projecting that roughly one-third of enterprise applications will embed agent-based intelligence by 2028, the underlying data architecture required to power these systems is shifting. It is no longer a niche discussion; the market for enterprise knowledge graphs is actively accelerating, projected to expand from roughly $1.9 billion today to nearly $10 billion over the next several years.
Major hyperscalers are moving decisively into the space. A prime example is Amazon’s entry with AWS Context, a new knowledge graph service designed to dynamically surface organizational intelligence that continuously learns and sharpens through agent usage over time. As platform companies like Atlan, Glean, Neo4j, and a growing roster of data infrastructure providers converge on the same idea, a fundamental truth has emerged: AI agents cannot operate reliably without structured, governed context about how enterprises actually work.
The distinction between the two types of graph is also emerging across enterprise architecture conversations:
The Knowledge Graph: Maps entities and their relationships at design time. It answers what things are, where data resides, and how corporate assets connect.
The Context Graph: Extends that exact same structure at runtime, capturing decision traces, data shelf life, and behavioral policies. It answers why decisions were made, how the enterprise actually operates, and what tribal knowledge sits between traditional systems of record.
Both are emerging as critical infrastructure for the agentic era, and both are being built with real urgency inside enterprises right now.
But, in the conversations happening today, these graphs are largely built as internal, enterprise-only artifacts. That is a natural starting point, because the immediate, burning problem is helping corporate agents understand internal workflows. It is also, from a holistic perspective, structurally incomplete. If the three-body model of customer experience holds, then each of the three bodies will have its own unique knowledge and its own runtime context to contribute to the relationship. The graphs being engineered today are capturing only one-third of what the model will ultimately require.
Let’s quickly review how I’ve been thinking about the three bodies that produce durable customer value as the organization, the customer, and the product or service that binds the relationship. Each has knowledge and context native to its domain:
1. The Organization
The organization has structural knowledge about its products, its policies, its pricing, and its capabilities. It maintains runtime context about why an account executive made a specific concession, how escalations flow through support tiers, and where human expertise lives. This is what the current context graph conversation is about, and enterprises are right to build for it. But it remains an isolated silo.
2. The Customer
The customer possesses knowledge and context of a radically different kind. The customer knows what they were trying to accomplish when they used the product or service. They know what worked and what failed. They know what alternative solution they would have chosen if they had been better informed, how the product actually fits into their daily life or workflow, and which of the enterprise’s brand promises landed versus which ones fell short. Their context is the living decision trace of their own life as they navigate the vendor relationship.
Under a trust protocol like the developing IEEE 7012 MyTerms standard, this rich customer knowledge and context will become portable, structured, and available to the enterprise on machine-readable terms the customer has explicitly set rather than harvested silently and inaccurately through third-party cookies and fragmented telemetry.
3. The Product or Service
The product body is the one the current enterprise conversation is largely overlooking. As AI gets embedded into products themselves, the product will no longer be a passive instrument observed from the outside. It will feature its own localized AI model tuned to the product’s explicit purpose with an architecture capable of generating intrinsic product insights.
This is a fundamentally different kind of signal from the telemetry the industry has spent the last thirty years collecting. Telemetry is a lagging indicator; it is what a monitoring system observes from the outside (e.g., the user clicked a button three times). Product-side AI feedback is what the product itself has to say about its own life in the wild (e.g., the user is experiencing acute friction executing this specific data transformation workflow). This real-time edge context is structured so that both the customer and the enterprise can act on it immediately.
A Fully Enabled Graph
When all three bodies emit both design-time knowledge and runtime context, and when a trust protocol like MyTerms makes that emission collaborative rather than extractive, something entirely new becomes possible.
With a collaborative approach, the knowledge graph is no longer just what the enterprise knows about its own backend operations. It also incorporates what the customer, the product, and the organization together know about the relationship they share. The context graph is no longer just the internal decision traces of corporate software. It becomes the holistic decision trace of the entire three-body system, dynamically blending the customer’s evolving priorities, the product’s actual edge behavior, and the enterprise’s operational constraints.
The value that emerges from this synthesis is not incremental; it is a category shift. It represents a layer of shared understanding that could never exist inside a single organization’s silo. The customer’s agent will know what the user intended to do. The product’s internal model will know what actually happened at the execution layer. The organization’s graph will know what the enterprise committed to deliver and why. When all three are in a structured, multi-agent conversation with one another, they co-create value based on absolute ground truth.
This will fundamentally rewrite what enterprises build and buy over the next several years. The context layer cannot remain an internal-only asset. It must evolve into a collaborative surface where enterprise, customer, and product all contribute what they know under a robust governance framework.
The organizations that recognize this shift early will design for the three-body pattern from day one. The ones that treat the context graph as a glorified corporate database will find themselves completely rebuilding their data layer once user-side trust protocols mature and customers arrive at the relationship with structured representation of their own.
The knowledge and context graphs being deployed right now are the beginning of the infrastructure shift, and not the end of it. What comes next is an ecosystem that treats all three bodies as equal contributors to the shared understanding that the agentic era demands. When that arrives, the value created between customer and enterprise will be fundamentally different from anything the old cost-deflection era could produce, because for the first time, both sides will be building on the exact same graph of what the relationship actually is.