How to operationalize a context graph
The word context graph has been overused to the point where it is hard to tell what it means and what it does not. Jaya Gupta at Foundation Capital is the reason it caught: her argument is that agents have no access to decision traces, the record of why something happened, and that capturing those traces is the next durable data moat. Context layer and semantic layer have been following the term around ever since.
Whatever it means to whoever is using it, having one is usually said to solve at least one of these:
- Retrieval. Agents get to complete and relevant information.
- Provenance. Agent output traces back to a source of truth, so the work is auditable.
- Memory. A record of how the organization actually decides: precedents, exceptions, the tacit knowledge that lives in people's heads.
- Governance. Agents hallucinate less and surface only approved, current information.
The call to action is the same in almost every case. Extend context to your agents. And whichever of those four problems you are actually trying to solve, the build looks roughly the same. That build is what this guide covers: the layers, the steps, the human gates, and what a grounded agent run looks like when it works.
One example runs through the whole piece. A provider sends a prior authorization request to a health insurer for semaglutide. It gets denied. Someone has to work out why and resubmit it.
What people mean when they say an agent needs context, and how that differs from RAG
Agents and LLMs have no view of your domain, and no view of how your enterprise runs. Enterprises run on standard operating procedures, defined policies, and rules. Handing those to an agent through RAG has not solved any of the four problems above. We have covered in detail how different retrieval architectures have different ceilings on consistency, accuracy, domain alignment, and provenance.
The thing to understand first is that enterprise operations run on two kinds of knowledge. Explicit knowledge is written down: SOPs, policies, regulations, domain ontologies. Implicit knowledge is not. It is the tribal knowledge sitting in the heads of the people doing the work. A context graph worth the name gives an agent both.
Explicit knowledge splits into three layers. Implicit knowledge is the fourth.
"Layers one through three live in documents. Layer four does not, and it is the one that governs what people actually do."
Context for an agent means information from all four layers, handed over in a structure the agent can reason across deterministically rather than probabilistically. That structure is the whole point, and it is where this departs from RAG.
RAG exposes chunks of text. Chunks are not connected data, so a probabilistic engine has to do two jobs at once: find text that looks similar, then reason across it in a way nobody can inspect. That is an architectural ceiling, and it caps accuracy, consistency, and explainability no matter how good the retrieval gets.
The first prescriptive recommendation: start with the explicit sources. Domain ontologies, enterprise taxonomies, then policies and SOPs.
Step 1. Load a domain ontology
An ontology is a formal framework that defines the concepts, properties, and relationships inside a specific domain, in a machine-readable format, so that meaning and interpretation stay bounded and aligned to that domain.
Pick the one that fits your use case. This step is more tedious than it sounds. Depending on your vertical you can usually start from a publicly available ontology, and you can work with an ontologist to trim it, because published ontologies run enormous and most of what they cover will be irrelevant to you. It depends entirely on what you want the ontology to do.
Ontology files come as OWL or RDF. Here is what one looks like rendered.
That is layer one.
Step 2. Bring your enterprise taxonomy
Same idea as the domain ontology, applied to your company instead of your field. An enterprise taxonomy is a structured classification of an organization's information, assets, and data under a shared vocabulary. A glossary, in other words, for your company or your department.
Take the word "customer." Sales counts an account as a customer when the contract is signed. Finance counts one when the money lands. Customer success counts one when onboarding finishes. Same word, three definitions, and every AI system you build on top of it inherits all three unless somebody writes the glossary down first.
The common format is SKOS (RDF/XML, Turtle, or JSON-LD), the W3C standard: concepts, broader and narrower and related relationships, preferred and alternate labels. It is what most interoperable taxonomies use.
If you do not have one, an LLM can draft it. Your domain experts then review that draft and decide what is actually right.
Step 3. Ingest SOPs, policies, and procedures
These are the operational rules your workflows actually run on. They are what gets handed to a new employee alongside the tribal knowledge, and they are what you would hand an agent. Some of them are out of date, and it is worth arguing about which, but for the most part this is the corpus.
Chunking and embedding SOPs has not worked. What does work is using the two structures you just built, the ontology and the taxonomy, to guide the ingestion, so the SOPs come out as machine-readable structure with their concepts linked into the layers underneath.
Then that structure gets reviewed. A domain expert has to check, from a governance standpoint, that every connection the ingestion made is actually correct. Here is what the result looks like.
That review interface is what we mean when we talk about shifting the human in the loop to the left. The expert checks the knowledge structure once, before it is used, instead of checking every answer forever afterward.
At this point your explicit knowledge is a context graph. Layers one through three are in place. Which is a good moment to find out what three layers can and cannot do.
The denial, walked through
The request goes in for semaglutide. BMI 31, one qualifying comorbidity. The agent assembles the prior authorization packet and submits it. Denied.
Now it has to be resubmitted, and there are two ways to work the denial. They differ in what the reviewer who signs the resubmission can actually check.
The blackbox route hands the denial letter to a model and asks why it failed. What comes back is a fluent paragraph with no provenance behind it. The reviewer either takes it on faith or does the work again by hand.
The grounded route lets the three explicit layers decompose the denial. Each one answers a different unknown in it, from a source you can point to.
What each explicit layer resolves
One denial letter, three unknowns, three sources you can point to.
Each layer turns one unknown into a known that traces to a source. That is the difference from the blackbox: a reason a reviewer can audit, rather than a better guess.
Three layers ran and all three resolved. One thing stays open.
In March the payer narrowed "documented lifestyle intervention" to the last twelve months. Revenue integrity had separately ruled that this patient's dietitian visit counts as qualifying. Neither fact is in a document any of the three layers could read. One lived in a Teams thread and the other was a call somebody made on a Tuesday.
That residue is the denial's real cause, and it is the part a blackbox would have buried inside a confident answer. Surfacing it is what three layers get you. Closing it is what the fourth layer and the loops are for.
Pre-publication flag — remove this callout before publishing
The policy specifics in the walkthrough above are an illustrative composite. The step-therapy detail, the twelve-month lifestyle-intervention window, and the physician-issues-the-denial requirement all need sign-off from a revenue-cycle or clinical reviewer before this post ships. A wrong PA detail in front of a VP of Revenue Integrity costs more than the example earns.
Layer 4: tapping implicit knowledge
Explicit knowledge has one limitation, and the denial just demonstrated it: operational reality drifts away from the document. The edge cases and the exceptions live in the heads of the people doing the work. The workarounds may or may not make it back into the SOP. The whole goal of this layer is closing that distance.
SOP updates need to be tracked meticulously, for attribution and for the audit trail. The inputs for those updates come from the conversational stream: Slack and Teams threads, email, Jira, ITSM tickets, whatever else the work leaves a trace in. Recommendations get surfaced to domain experts, who review and finalize them. Once approved, they flow back into the graph.
What happens when the new rule contradicts the old one
New SOPs conflict with old SOPs, and when the update took effect matters as much as what it says. Every incoming update raises the same question. Does the previous version retire completely, stay as-is, or coexist with the new one?
That is a domain expert's call, and here is why it has to be.
Take a refund policy. An e-commerce store allows T-shirt returns within two weeks. Ahead of the holidays, the policy stretches to four weeks. Does the old policy stop existing? No. Anyone who bought a shirt before the holidays bought it under the two-week rule, and that rule still governs their return. The new rule governs purchases made after the change. Both versions are live, and which one applies depends on the date on the receipt.
Other cases go the other way. A regulatory update may require the old version to be phased out entirely, with no coexistence at all. These are tactical decisions with real consequences, and a human has to make them. An LLM can help curate the options. The decision stays with the human.
The two loops
Knowledge is dynamic. Concepts get sunsetted and facts get superseded. A knowledge foundation needs plumbing for that, and every update through it has to be curated by someone who knows the domain. Two loops feed the foundation, and they run at it from opposite ends. Both end in the same place: an SOP update, carrying the audit trail of who changed what and when.
The capture loop starts with a message
A Slack thread, an email trail, a comment on a Jira ticket, a ServiceNow record. Something in there captures an exception, an edge case, or a new rule, and it routes to a domain expert.
This is the loop that would have caught the denial before it happened. Both facts that sank the resubmission moved through Teams weeks earlier, and neither one reached a document.
Pulling the sentence out of the thread is the easy half, and it is the half every vendor demos. The hard half is authority. Messages arrive constantly and almost all of them are noise, so before anything gets promoted you have to decide whether a given statement is a decision at all. Someone says the dietitian visit should count. Is that a ruling, or is that one person thinking out loud? Answering that takes somebody who knows how the org actually assigns authority, and no model does it alone.
The audit loop starts with a failure
An answer dead-ends, the gap surfaces, and a domain expert reviews what should have happened instead.
Some of these are cases the policy never anticipated. A prior auth for a pediatric patient with a comorbidity combination nobody wrote a rule for gets flagged or rejected, and that is the moment you find out the policy has a hole in it. The expert writes new coverage, and the next agent works from the corrected version.
The foundation is not something you load once and query forever. Every answer traces back to it, so every wrong answer tells you exactly what it was missing.
Underneath both loops sits the ordinary maintenance of the explicit layers, which is reconciliation rather than a loop. A document changes, and that change is a discrete event you can detect. The payer posts new medical policy. A protocol gets revised. The QA rubric is updated. The work is deciding which version governs and where two sources disagree. Heavy per event, and it runs in batches. It fails as a stale version or an unreconciled conflict.
What it looks like once the loops have run
Same request, same four layers, and this time the twelve-month window and the dietitian ruling are both already in the SOP. Nothing needs adjudicating. The agent retrieves, reasons, and submits, and no loop fires at all. A working foundation is boring from the outside. That is the point of it.
Why the domain expert is the whole thing
This is where the moat is. A competitor can license the same model and read the same public documents. What they cannot read is your March policy change that only ever lived in a Teams thread, or the call your revenue lead made on one patient's dietitian visit. That knowledge is yours alone, and these two loops are the only way it reaches an agent in a form the agent can act on.
You can skip the implicit half of this entirely. If your rules genuinely live in current documents, or a human checks every output before it counts, you do not need any of it.