The context layer is now a vendor product
As vendors ship their own context graphs, agents can act on conflicting versions of the same customer, and reconciling them falls to the enterprise.
Context is now where major enterprise vendors compete. A context graph is the map an agent consults before it acts: which customer is which, which records belong together, what happened last, and who owns it. At Atlassian's Team '26 Europe event in October, CEO Mike Cannon-Brookes said he expects "three to five large-scale context graphs in most organizations," and made clear Atlassian intends to be one of them. SAP made a parallel case at SAP Connect, arguing that contextual AI with embedded governance outperforms generic models. UiPath is building its own continuously updated map of how work flows. Each pitch is reasonable on its own terms. Phil Wainewright, covering the Atlassian event for diginomica, asked the question those pitches leave open: how do these graphs get reconciled?
When two graphs disagree
Consider a routine case. A CRM agent working from one vendor's graph treats a commercial client as a single relationship in good standing. An operations agent working from another graph sees the same client as three entities, one of them under review. Both agents are behaving correctly. Each is acting on the context it was sold with. The disagreement never shows up as an error. It shows up as two inconsistent actions, and someone has to explain them.
What the examiner will ask
In a regulated institution, that someone is usually the CIO. The examiner will ask what the agent knew and where that came from. If the answer runs through a vendor graph the institution cannot inspect, the decision trace stops at the vendor's boundary. The institution can show the action. It cannot fully show the inputs. The incomplete record belongs to the institution, not the vendor.
This is the entity resolution problem enterprises have fought for decades across CRM, core systems, and warehouses. Agents raise the stakes because they act on the disagreement immediately instead of leaving it in a report someone might catch.
Why ownership decides the renewal
There is a commercial cost as well. Constellation Research's [Esteban Kolsky has argued](https://www.constellationr.com/research/blog/strategic-optionality-resilient-and-innovative-architectures) that the real test of an architecture is whether the enterprise can keep choosing as infrastructure changes. A context graph only one vendor can read fails that test. If an agent's understanding of a customer lives only inside the vendor's graph, leaving the vendor means rebuilding that understanding from scratch. An enterprise-owned reconciliation layer, one model of which entities exist and which source wins, is what keeps the next renewal a negotiation instead of a formality.
The timeline is short. Most of these graphs are arriving bundled into platforms the enterprise already licenses, not as separate purchasing decisions. The architecture is being set at renewal whether or not anyone decides it.
The question to bring to the table
The question to bring to the next renewal meeting is simple. Whose graph is the system of record when two agents disagree?
