Your Context Graph Has a Customer-Shaped Hole In It

The context graph conversation is the right conversation. It also stops at the moment the customer enters the picture, and customer-side agents are about to make that gap impossible to ignore.

There’s been a real and useful conversation building over the last several months about context graphs and their role in enterprise AI. Gartner and Forrester have identified context graphs as foundational infrastructure for agentic AI, with a projection that by 2029, 80% of AI agent platforms using reasoning models will have aligned context layers in place, compared to fewer than 10% today. Microsoft just launched IQ at Build 2026 as an enterprise intelligence layer that grounds AI agents in workplace data and business systems. Glean, Atlan, Publicis Sapient, and a half dozen others are all converging on the same idea: AI agents need a structured understanding of how the enterprise actually decides, escalates, and resolves things, not just a flat snapshot of what’s in the systems of record.

I think the conversation is correct on the substance and structurally incomplete on the scope. Every framing I’ve seen treats the context graph as an enterprise-internal artifact. The decision threads in Slack, the escalation patterns in the ticketing system, the tribal knowledge that lives between employees. All of that matters, and the enterprise is right to be building infrastructure to make it queryable. But the graph stops at the moment the customer enters the picture, and that is where the most valuable context in the entire system actually lives.

The richest context about your product or service is not held inside your company. It is held by the people who actually use what you sell.

That sentence sounds obvious when you read it, and the obviousness is exactly the problem. CX has organized itself for decades around customer journey maps that treat the customer as a stage-completion function. Did they convert. Did they activate. Did they expand. Did they renew. In the previous piece I argued that the journey map was always a fiction the enterprise told itself. The deeper fiction underneath is that the customer is a callable function in your process rather than the most valuable node in your graph.

The customer holds the why. They know what they were trying to accomplish when they bought your product. They know which features they actually use and which ones they ignore. They know which workarounds they invented when your product didn’t do what they needed. They know how your service interaction made them feel about renewing. They know how your pricing landed against the value they actually derived. None of that lives in your CRM. Some of it lives in your support tickets, albeit captured in opaque ways. Most of it lives in the customer’s head, and it has been functionally invisible to the enterprise for the entire history of CRM/CX as a discipline.

Customer-side agents are about to change that, and I think the implication for the context graph conversation is bigger than the current focus is treating it. When a customer deploys an agent that represents them across the vendors they buy from, that agent accumulates exactly the kind of structured, queryable context that enterprises have been trying to manufacture internally. It knows what the customer wanted, what they got, what worked, what didn’t, and what they would have preferred. It carries that context in a form that can be shared, in whole or in part, with the vendors who have earned the right to receive it. That is the customer’s missing node, finally legible.

The hard part is what comes next, and it is not technical. Companies have to fundamentally reposition where the customer sits in their operating model. As long as the customer is a callable function inside a journey map, there is no place in the architecture to receive what their agent is offering. The customer has to move from being a target of the enterprise’s process to being a peer node in the enterprise’s graph. I think that is an organizational redesign question more than a data engineering question, and it is going to be the harder lift for most CX leaders to make.

It also requires a trust framework, because customer context only flows when both sides have a durable framework, like contract, that governs it. Consent banners are unilateral, brittle, and largely performative. What is required is a bilateral agreement, machine-readable, persistent, and auditable, that defines what the enterprise can do with the customer’s context, how long it can hold it, and what the customer gets back in return. That work is underway in standards bodies and in adjacent communities (MyTerms being one of them), and I think it becomes essential infrastructure for everything the agentic CX conversation is currently hand-waving past.

When both sides bring context into a relationship that has a contract underneath it, value co-creation stops being a strategy deck and starts being an operational reality. The enterprise’s context graph gets the missing node. The customer’s agent gets a counterpart that can actually respond to what it knows. Both sides end up holding a richer, more useful, and more honest view of the relationship they are actually in.

The context graph conversation is the right conversation. It just needs to include the customer. The technology is finally good enough to make that possible, and the leaders who do the work to receive what their customers’ agents are about to offer will end up running businesses that compound value in ways their deflection-era predecessors never could.