A claims manager at a Hong Kong insurer asks the company's new AI agent a simple question: should this water-damage claim from a Tai Koo Shing flat be paid in full?
The agent reads the policy wording perfectly. It finds the claim file. It even locates the relevant clause. Then it recommends rejection, because it has no idea that the same exception has been approved 40 times in the past year, that the underwriting director signed off on a revised interpretation in March, and that the customer is a corporate account worth HK$3 million in annual premium.
The agent was not short of data. It was short of context. That gap is exactly what a context graph is designed to close, and it is why SAP, Atlassian and Google all made context the centrepiece of their enterprise AI announcements in the past fortnight.
What is a context graph?
A context graph is a connected map of how an organisation actually works: its people, tasks, systems, policies and past decisions, linked by their relationships and stamped with time. It gives AI agents the situational knowledge a seasoned employee carries in their head, so they can act on precedent rather than guess from documents alone.
Think of it as the difference between handing a new hire the policy manual and handing them the manual plus five years of annotated case history. The manual tells them what the rules say. The case history tells them how the rules are applied, by whom, and when exceptions are allowed.
Technically, a context graph stores entities (a customer, a contract, an approver) as nodes and their relationships (owns, approved, escalated to, superseded by) as edges. What makes it a context graph rather than a plain knowledge graph is that it also captures decision traces: the record of what was decided in a specific case, under which policy version, and with which exception.
Why are context graphs suddenly on the enterprise agenda?
Context graphs moved from theory to boardroom in October 2026 because three of the largest enterprise software vendors tied their agent strategies to them. SAP agreed to acquire TechWolf for its context graph, Atlassian published token and accuracy gains from its Teamwork Graph, and Google launched a Knowledge Catalog to ground its new Gemini agent.
On 6 October 2026, SAP announced it will acquire TechWolf, whose proprietary "context graph for work" maps tasks, skills and labour-market signals. SAP's Manoj Swaminathan described it as a grounding layer that makes token usage more efficient and lowers the cost of deploying workforce agents. The deal is expected to close in Q4 2026.
Atlassian has gone further with numbers. According to IT Brief, Atlassian's internal tests found that agents grounded in its Teamwork Graph used 48% fewer tokens and produced answers 44% more accurate than agents without it. These are vendor benchmarks, not independent results, but the direction is consistent.
Google's Gemini at Work event on 8 October added a Knowledge Catalog that maps business definitions such as net margin. Futurum Research reports that Bloomberg Media saw a 63% lift in SQL query accuracy during early development. The idea itself was popularised by Foundation Capital's December 2025 essay on context graphs as AI’s next platform opportunity.
How is a context graph different from RAG, a knowledge graph or a data warehouse?
A data warehouse stores facts for reporting, RAG retrieves relevant document passages at query time, and a knowledge graph links entities. A context graph combines entity links with decision history and time, so an agent can traverse how a situation relates to past cases, policies and people instead of reconstructing that picture from scattered text.
The distinction matters because many organisations believe they already have this capability. Most do not. Each existing layer answers a different question:
--- Data warehouse: what happened, in aggregate. Excellent for dashboards, weak at explaining why a single case was treated differently.
--- RAG (retrieval-augmented generation): which documents mention this topic. Good for policy lookup, but it rebuilds context from fragments on every query, which is costly and error-prone.
--- Knowledge graph: how entities relate. Useful, but usually static and silent on decisions.
--- Context graph: how this situation connects to precedent, owners, policy versions and outcomes, over time.
Atlassian credits its gains, as The New Stack reports, to agents traversing relationships rather than reconstructing context through retrieval. That is the core economic argument: fewer tokens spent rediscovering what the organisation already knows.
What does a context graph actually contain?
A practical enterprise context graph contains five layers: core entities such as customers and contracts, the people and roles who own them, the policies and their version history, the decision traces that record exceptions and approvals, and timestamps that show what was true when. Together these let an agent answer why, not just what.
1. Entities
Customers, suppliers, contracts, products, sites and tickets. Most of this already exists in your CRM, ERP and ticketing systems.
2. People and roles
Who owns which account, who can approve what, and who escalates to whom. This is the layer most often missing from AI pilots.
3. Policies and versions
Not just the current rule, but when it changed and why. An agent that only sees the latest version will misjudge cases opened under the old one.
4. Decision traces
Each approval, rejection and exception, linked to the case, the policy applied and the approver. This is where institutional judgement lives.
5. Time
Every edge carries a date, so the agent can reason about what was true at the moment a decision was made.
How do you build a context graph without a multi-year data programme?
Start with one high-volume decision, not the whole enterprise. Map the entities and people involved, capture decision traces going forward from existing workflow logs, connect only the systems that decision touches, and measure agent accuracy and token cost before and after. Expand to a second decision only when the first shows a measurable gain.
Step 1: Choose one decision with real exceptions
Good candidates have high volume, a written policy and frequent exceptions: credit-limit overrides, claims exceptions, refund approvals, supplier onboarding. If every case follows the rule, you do not need a context graph.
Step 2: Capture traces from the workflow, not from interviews
Approval logs, ticket histories and email threads already contain most decision traces. Structure them as they happen; do not try to reconstruct ten years of history on day one.
Step 3: Connect in place where possible
Link to systems of record rather than copying data into a new store. Our guide to zero-copy AI explains why moving data creates new governance problems.
Step 4: Measure two numbers
Track answer accuracy against a human-reviewed sample, and track tokens per resolved case. If neither moves after 60 days, the graph is not capturing the context that matters.
What does a context graph look like in a Hong Kong enterprise?
In Hong Kong, context graphs are most valuable where decisions depend on relationships and precedent: insurers handling claim exceptions, logistics firms managing customer-specific service terms, and professional services groups tracking which partner approved which engagement terms. In each case the graph turns tribal knowledge into something an agent can query and an auditor can inspect.
Return to the insurer. With a context graph, the agent sees that the water-damage claim matches 40 prior approved exceptions, that the March interpretation from the underwriting director applies, and that the account sits with a named relationship manager. It recommends payment, cites the precedent, and routes the case for one-click human confirmation.
A Kwai Chung logistics operator faces a different version. Its top 30 customers each have bespoke cut-off times and penalty waivers negotiated over years. A context graph linking contracts, account managers and past waiver decisions lets a customer-service agent answer "can we waive this late fee?" consistently, instead of escalating every case.
There is also a compliance dividend. According to Mayer Brown’s analysis, 57 of the 60 organisations in the Privacy Commissioner's 2026 AI compliance checks were already using AI in daily operations. A graph that records which data an agent used, and why, makes PDPO accountability far easier to evidence.
What are the common mistakes when building a context graph?
The most common mistakes are treating the context graph as an IT data project rather than a business decision project, trying to model the entire organisation at once, ignoring decision traces in favour of static entity links, and granting agents access to the whole graph instead of only what their role requires.
--- Boiling the ocean: an enterprise-wide ontology project can consume 18 months before a single agent improves. Start with one decision.
--- Entities without decisions: a graph of customers and products is a better CRM, not a context graph. The value sits in exceptions and approvals.
--- No owner for freshness: stale context is worse than none, because the agent will act on it confidently. Assign a business owner for each decision domain.
--- Flat access: a context graph concentrates sensitive relationships. Agents should see only the slice their role needs.
The last point connects directly to agent governance. If you cannot list every agent that can query the graph, start with our framework for building an agent inventory.
How should you present a context graph investment to the board?
Present it as a cost and risk lever, not a technology purchase. Show the target decision, current error and escalation rates, the token cost per case today, and the expected change based on a 60-day pilot. Boards approve infrastructure when it is tied to a specific decision with a measurable before and after.
A one-page board paper needs four lines: the decision being improved, today's cost per case including escalations, the pilot result on accuracy and tokens, and the governance controls that limit what agents can see.
Frame the vendor landscape honestly. SAP, Atlassian and Google are each building context into their own platforms, which helps if most of your work runs inside one of them. If your decisions span several systems, the context layer is a strategic asset you may want to own rather than rent.
Key facts at a glance
--- Definition: a connected, time-stamped map of entities, people, policies and decision traces that grounds AI agents.
--- SAP and TechWolf: acquisition announced 6 October 2026, close expected Q4 2026.
--- Atlassian Teamwork Graph: 48% fewer tokens and 44% more accurate answers in Atlassian's internal tests.
--- Google Knowledge Catalog: launched 8 October 2026; Bloomberg Media reported a 63% lift in SQL accuracy in early development.
--- Where to start: one high-volume decision with frequent exceptions.
Conclusion: agents need memory of how you decide
The next phase of enterprise AI will not be won by the organisation with the biggest model. It will be won by the one whose agents understand how that organisation actually decides. A context graph is how that understanding becomes an asset rather than something that walks out of the door when a senior manager retires.
We understand the cold edges of AI and the hard parts of your work, and UD has walked with Hong Kong enterprises for twenty-eight years, making technology a partnership with warmth.
Reviewed by the UD enterprise AI team. Vendor figures were checked on 12 October 2026 against the sources linked above and are the vendors' own benchmarks.
Ground your first AI agent in real business context
Now that you have the framework, the next step is choosing the one decision where context will pay back fastest. We'll walk you through every step, from mapping the decision and its owners to connecting your systems, deploying the agent and tracking accuracy and cost.
