There is a version of enterprise AI that works. In this version, agents do not just retrieve information or draft content. They understand how a business actually operates: which exceptions apply, what approval was granted, why a given customer gets a different price.
Most enterprise AI is not that version. The gap is not the model or the connectivity. It is context.
As Publicis Sapient put it, “AI is only as effective as the context it is given.” Without accurate, current business context, AI cannot improve outcomes. It can only infer patterns and achieve the wrong ones faster.
This series is about what context actually means at enterprise scale, where it lives, why it is harder to capture than most teams assume, and how building it correctly changes what AI can do.
What the term “context graph” means
The phrase “context graph” has been circulating in enterprise AI conversations since late 2025. Writing in Diginomica in February 2026, analyst Phil Wainewright described it as a crucial layer of knowledge that goes well beyond the core transactional data and process flows recorded in a system of record. The most important knowledge, he argued, comes from the data about the decisions that surround those transactions as the workflow proceeds.
As Publicis Sapient put it this way: an enterprise context graph is a living map of your business. It surfaces shared context between teams, regions, software, and documents. It makes explicit the relationships between decisions, data points, rules, workflows, and software, even when those relationships were never formally documented.
It is not just a catalog of your assets. It is the reasoning behind those assets that determines how your enterprise actually works. It updates continuously as systems change, decisions are made, and outcomes play out.
Bo Kim, who served as CIO of Gusto, put it simply: “The contextual layer is where a lot of CIOs are starting to spend their time today.”
Why systems of record do not capture it
Enterprise software has always been built around systems of record: ERP, CRM, HRIS. As Wainewright noted in Diginomica, these systems are very good at recording outcomes, including the final price, the escalated ticket, the approved discount, but not the reasoning behind them. Which exceptions applied? What precedent mattered? Who approved what, and why?
That context lives in Slack threads, side conversations, and people’s heads. Up until now, it has rarely been treated as data.
This is not a new problem. Businesses have always had more institutional knowledge than their software captured. The difference is that AI agents now need that knowledge to function. An agent that can reach your CRM but cannot understand the approval logic embedded in your revenue operations process will make decisions that look correct and produce the wrong outcomes.
Wainewright’s piece identified the territory precisely. Decision threads exist in the white space between traditional applications: spreadsheets, email chains, work management tools, cross-function coordination apps for revenue, engineering, security, and finance operations, and the tribal knowledge that accumulates in people’s heads, out of reach of any system.
Automation alone cannot surface business rules buried in 20-year-old systems, untangle a portfolio of 1,000 applications with no clear dependencies, or reveal where critical data actually lives and how it is used.
Publicis Sapient described a real-world case in which a single customer definition existed in 27 different places, updated by 36 different programs, with only four systems acting as true sources of record. Manual analysis took months. With an enterprise context graph, a living map appeared in minutes.
Rules versus decision traces
There is a useful distinction between two types of knowledge that an AI agent needs.
The first is explicit rules: the documented policies, price books, approval thresholds, and process documentation that exist in most organizations. They are necessary but incomplete.
Foundation Capital’s Ashu Garg explained that the rules that define each process only go so far. Humans bring a lot more context when they decide how to interpret the rules in the specific case of each transaction.
The second type is decision traces: the records of how rules were actually applied in specific situations. Which exception was granted to which customer, and under what conditions. Which approval path was used when the standard path did not apply.
As Garg framed it in his Foundation Capital essay, a context graph is institutional memory for how an organization makes decisions. Not how the process doc says it should, but how it actually works in practice.
When agents sit in the path of real workflows, they see the full context at decision time: what inputs were gathered, what policy was evaluated, what exception route was invoked, who approved, and what state was written. Persist those records, and you get something that does not exist in most enterprises today: a searchable record of how decisions were actually made.
Capturing the “how” is achievable. Capturing the “why” is harder. As Garg acknowledged in his follow-up essay, true intent is internal and unobservable. You capture the how, including the policy applied, the evidence consulted, the exception granted, the approver, and infer the why from patterns over time.
That is sufficient for most enterprise use cases. Agents do not need to know why an exception was granted in the abstract. They need to know that it was granted, under which conditions, and how often that pattern repeats.
What this looks like in practice
A context graph shows leaders how the enterprise truly operates. Not how it should operate, or how you think it operates, but how it actually behaves today.
This matters because without it, decisions rely on context that has been explicitly documented or that individual employees happen to remember. In a 50-year-old company with 20,000 people, most of the context that actually drives outcomes lives nowhere at all.
Most enterprise AI initiatives stall at the pilot stage for this reason. They can make individual tasks faster but they cannot govern systems. Context is what turns AI from a tool that speeds things up into one that actually navigates for you. Agents working without it are just producing outputs with no grounding in how your business runs.
How Workato approaches this
Workato functions as an enterprise context graph for the organizations it serves. This is not a separate product you configure or a screen you click into. It is a capability that emerges from how Workato connects to the systems, workflows, and relationships that define how a business actually runs.
Workato connects to the knowledge assets where institutional context lives: documents, tickets, emails, Slack, wikis. It tracks the activity and relationships around those assets, including who edited what, which meetings touched which decisions, and how information flows across teams. It maps reporting structures and cross-functional connections that determine who approves what and why.
None of that content lives inside Workato. But because Workato understands how it all connects, it can surface relationships that would otherwise stay invisible. That knowledge layer is what enables agents to reason accurately about your business, rather than guessing from documents or making inferences that sound plausible but turn out to be wrong.
One reason this matters: decision threads are inherently collaborative. They are where people consult others for approval, where tribal knowledge gets shared, where cross-functional connections get forged. An orchestration platform that sits in the path of real workflows, across real systems, with real governance, can capture and structure that knowledge in a way that a point tool sitting off to the side cannot.
Why this is the right starting point
Taking context graphs seriously means acknowledging how much we still do not know about how enterprises actually function. It points to a new category of software built to capture and make use of that knowledge.
Building the context layer is not a prerequisite that delays AI work. It is the investment that determines whether AI work compounds or plateaus.
Explore the rest of the series:
- Rules vs. Decision Traces: What Your AI Actually Needs to Know
- Why Most Enterprise AI Is Still Surface Level
- The Glue Function Problem: Why RevOps, DevOps, and SecOps Are the AI Opportunity
