The $47,000 Question
Last quarter, a Fortune 500 company's AI agent approved a $47,000 customer refund. The refund violated three internal policies, ignored a fraud flag, and set a precedent that cost millions in subsequent claims.
When the CTO asked the obvious question — "Why was this allowed?" — nobody had an answer.
Not the AI team. Not the operations team. Not the vendor.
The agent had access to customer data, transaction history, and policy documents. It had retrieval-augmented generation. It had guardrails. What it didn't have was context — not in the shallow sense of "more information in the prompt," but in the deeper sense:
Why have we made similar decisions before?
What constraints applied?
Who had authority?
What precedent does this set?
This is the story playing out across enterprises adopting AI agents. The technology works — until it doesn't. And when it fails, the failure isn't "the model hallucinated." It's "the organization had no infrastructure for the agent to understand how decisions actually get made here."
This guide is about that infrastructure. It's called a Context Graph.
By the end, you'll understand:
What a Context Graph actually is (and isn't)
Why it matters for enterprise AI
How to build one from the ground up
Let's start with the fundamentals.
The One-Line Definition
A Context Graph is a decision-aware knowledge structure that captures not just what exists, but why decisions were made, under what constraints, by whose authority, and whether those decisions can be reused.
That's a dense sentence. Let's unpack it.
Before defining what a Context Graph is, let's clear up what it isn't:
| Common Misconception | Why It's Wrong |
| "It's a document store" | Documents store content, not decision provenance |
| "It's chat history" | Conversations lack structure, authority, constraints |
| "It's a richer Knowledge Graph" | Knowledge Graphs model entities; Context Graphs model judgment |
| "It's RAG with more context" | RAG retrieves facts; Context Graphs retrieve constraints |
| "It's agent memory" | Memory stores information; Context Graphs govern reuse |
| "It's a semantic layer | Semantic layers define metrics; Context Graphs capture how they're applied |
The most common question I hear: "Isn't a Context Graph just better memory for agents?"
No. Memory is one layer. Context Graphs govern reuse.
This distinction is fundamental:
| Knowledge Graph | Context Grap | |
| What it models | Truth (what exists) | Judgment (what was allowed) |
| Structure | Entity → Relationship → Entity | Event → State → Judgment → Outcome |
| Nature | Descriptive | Normative |
| Purpose | Describes the world | Governs action within it |
| Answers | "What is true?" | "What was allowed — and why?" |
| Time dimension | State Clock (what is true now) | Event Clock (why it became true) |
| Constraints | None | Reuse conditions enforced |
Knowledge Graphs are valuable. They tell you that Customer A has Contract B with Vendor C. They model entities and relationships.
But they can't tell you why the exception was granted last quarter, who had authority to approve it, what
conditions made it valid, or whether that logic applies to the current situation.
"Knowledge Graphs describe the world. Context Graphs govern action within it."
How is a Context Graph different from a Knowledge Graph?
Knowledge Graphs describe what exists. Context Graphs govern action by modeling judgment, authority, constraints, and decision outcomes.
Here's a framing that clarifies the distinction:
Most enterprise systems only capture half of time.
The State Clock captures what is true now — the current record, the present snapshot. Your CRM, ERP, and databases are sophisticated State Clocks.
The Event Clock captures why things became true — the reasoning, the decisions, the judgment that turned state into action.
Example:
State Clock: The deal closed at $500K
Event Clock: Why the sales rep discounted 30% against policy, why the VP approved it anyway, what market conditions made it urgent, what precedent it set
We've invested billions in State Clock infrastructure. We've barely begun building Event Clock infrastructure.
"We have built systems that remember what happened, but not why it made sense at the time."
A Context Graph isn't just a data store. It sits directly in the decision path:
Perception → Reasoning → [ CONTEXT GRAPH ] → Action
↑ ↓ │
Prior Decisions Constraints
& Precedents & Authority
This is why I call Context Graphs the Control Plane for agentic systems:
In a Context Graph, the decision itself becomes a node — not metadata attached to other entities:
Decision Node
│
├── Inputs & Evidence
│ What information was considered
│
├── Policy Context
│ Which policies applied (version at decision time)
│
├── Conflict Detection
│ What tensions or contradictions existed
│
├── Judgment
│ What was decided and the rationale
│
├── Authority & Scope
│ Who decided, within what bounds
│
├── Temporal Validity
│ When this decision applies
│
├── Reuse Constraints
│ Conditions under which this can be reused
│
└── Outcome
What happened as a result
This structure makes decisions queryable, auditable, and reusable — with guardrails.
Before any agent acts on a precedent, it must answer one question:
"Am I allowed to reuse this decision here and now?"
If the conditions don't match — if the temporal window has passed, if the authority scope is wrong, or if the reuse constraints aren't met — the agent must escalate, not proceed.
That's not memory. That's runtime governance.
One more important distinction:
| Rules | Context Graphs | |
| Nature | Baseline intent | Lived precedent |
| Source | Policy documents | Actual decisions |
| Captures | What should happen | What actually happened |
| Edge cases | Often silent | Explicitly captured |
| Updates | Manual | Continuous |
Rules define what should happen. They're encoded in policy documents and often silent on edge cases.
Context Graphs capture what actually happened. They're extracted from real decisions, including all the
exceptions, overrides, and judgment calls that rules don't anticipate.
This is why Context Graphs reduce hallucinations better than RAG alone:
RAG retrieves: "Here's information about vendor exceptions"
Context Graphs retrieve: "Here's what was decided, under what conditions, with what authority, and whether those conditions apply now"
Agents retrieve constraints, not just facts.
The Two Halves of Context
Context itself is heterogeneous. There are two halves that must connect:
How the company actually works:
Standard operating procedures
Exception policies
Tribal knowledge
The "we always do X because of Y" reasoning
What things mean:
Metric definitions and calculations
What "healthy customer" means
How "at-risk" is calculated
Business logic behind dashboards
A renewal decision pulls from both:
Operational: "Here's our exception policy for discounts"
Analytical: "Here's how we calculate customer health, here's what 'at-risk' means"
Context Graphs must bridge both halves.
Summary: What a Context Graph Is
A decision-aware knowledge structure
The Control Plane for agentic systems
Event Clock infrastructure (the "why")
Decisions as first-class, queryable objects
Runtime governance with reuse constraints
Bridge between operational and analytical context
Not a document store
Not chat history
Not "Knowledge Graph 2.0"
Not just agent memory
Not RAG with more context
Every enterprise has what I call the schema-truth gap: the distance between what systems formally record and what the organization actually knows.
Your CRM captures that a deal closed at $500K. It doesn't capture:
Why the sales rep discounted 30% against policy
Why the VP approved it anyway
What market conditions made it urgent
What precedent it set for future negotiations
Your ERP records that a vendor payment was processed. It doesn't record:
Why the penalty was waived during that specific incident
Whose authority covered that exception
Whether the same logic applies next time
Agents inherit this gap. They can query every system of record in your enterprise and still not understand how decisions actually get made.
For any significant decision in your organization, ask:
1. Which data should we trust and why?
2. Which policy should be applied and why?
3. Why was something treated as an exception?
4. Who approved the deviation?
5. What was the current state at decision time?
If your systems can't answer all five, your agents are guessing.
This isn't a model problem. It's an infrastructure problem.
Let me show you what happens when context exists but precedent control fails.
Vendor Atlas Systems missed its SLA. But there were extenuating circumstances — a region-wide cloud outage affected their ability to respond.
Finance reviewed and approved a penalty waiver:
Scoped to the outage window (March 12-14)
Approved by Regional Finance Director
Limited to regional exceptions under $50K
Explicitly noted as NOT setting precedent
The Context Graph captured it properly:
Decision: SLA Penalty Waiver (DEC-2025-03-001)
├── Operational Context: Regional cloud outage (AWS us-east-1)
├── Policy Context: SLA v3.2, Force Majeure Clause §4.2
├── Judgment: Exception granted, scoped to outage window
├── Authority: Regional Finance Director (scope: <$50K regional)
├── Temporal Validity: March 12–14, 2025 ONLY
├── Reuse Constraints:
│ ├── Requires documented external event
│ ├── Same region must be affected
│ └── Does NOT set precedent for future incidents
└── Outcome: $12,400 waived
Three months later, a different agent encounters a new SLA miss from Atlas Systems. No outage this time — just a standard service failure.
The agent sees the prior exception. It reuses that exception logic.
Finance asks: "Why is this happening again?"
The system remembered an exception happened. It didn't enforce:
Result: Exception applied outside scope → compliance risk → audit exposure → eroded trust.
The Fix
With proper Context Graph infrastructure:
Agent Query
"Can I reuse decision DEC-2025-03-001?"
Context Graph Checks
Agent Response
Escalate to human review
Result
Correct behavior, governance maintained
The agent asked: "Am I allowed to reuse this decision here and now?"
The answer was no. It escalated instead of proceeding.
That's the difference between automation and autonomy
Here's what most people miss about the Context Graph opportunity:
For the last decade, "heterogeneity" in data meant a mess of point tools orbiting closed warehouses. Iceberg and open table formats are ending that era — storage is becoming open, compute is becoming fungible.
But fragmentation isn't disappearing. Heterogeneity is moving up the stack.
Instead of five warehouses, enterprises are deploying hundreds of agents, copilots, and AI applications. Each with its own:
The new arguments won't be about where data lives. They'll be about:
One customer told me: "We have 1,000+ agent instances and no way to govern them. It's like BI sprawl all over again."
Agent queries: "Can I reuse decision DEC-2025-03-001?"
Context Graph checks:
Agent response: Escalate to human review
Result: Correct behavior, governance maintained
There's a popular thesis that vertical agent startups will own Context Graphs for their domain — sales agents capture sales context, support agents capture support context.
This runs into enterprise reality: execution paths are local, but context is global.
When a renewal agent proposes a 20% discount, it pulls from:
Every enterprise has a different combination of these systems. One runs Salesforce + Zendesk + Snowflake. Another runs HubSpot + Intercom + Databricks. A third has a homegrown CRM + ServiceNow + BigQuery.
To truly capture context, a vertical agent would need 50–100+ integrations just for common cases. Multiply across every vertical agent — sales, support, finance, HR — each building the same integrations.
"Execution paths are local. Context is global."
The vertical agent sees the execution path. It can't see the full context web.
Here's a problem that gets worse with scale:
Without shared context, one agent's exception becomes another agent's mistake.
The Atlas Systems failure wasn't a single-agent problem. It was a coordination failure:
Result: Behavior drift across the system
Context Graphs provide coordination infrastructure:
Context Graphs are coordination infrastructure, not storage.
How do Context Graphs support multi-agent coordination?
They provide a shared decision ledger, scoped authority enforcement, and conflict detection so agents remain aligned.
In a world with hundreds of agents operating simultaneously, the hard problem isn't initial context capture. It's coordination and improvement:
Vertical agents run feedback loops within their domain — they can only improve context for their workflow. They can't improve the shared building blocks: entity resolution, semantic definitions, cross-domain precedents.
A universal context layer runs the feedback loop once, at the platform level, and every agent benefits.
THE CONTEXT FLYWHEEL
Accuracy ───────► Trust
▲ │
│ ▼
Feedback ◄─────── Adoption
• Accuracy creates trust (better decisions)
• Trust creates adoption (more usage)
• Adoption creates feedback (more corrections)
• Feedback creates accuracy (better context)
"This is a platform problem, not an application problem."
There's a strategic dimension enterprises are starting to recognize.
They learned a lesson from cloud data warehouses: handing over both data and compute meant watching their most strategic asset — how they operate — become someone else's leverage.
This is why Iceberg exists. This is why open table formats are winning.
Now imagine doing that with something even more valuable than data: the accumulated institutional knowledge of how your company makes decisions.
The tribal knowledge. The exception logic. The "we always do X because of Y" reasoning.
That's what Context Graphs capture.
Enterprises won't hand that over to a dozen vertical agent startups, each owning a slice of their operational DNA.
"Their strategic asset is context, not agents."
They'll want to own their own context — with open, federated platforms that any agent can read from, humans can govern, and the organization can improve over time.
Here's the strategic insight:
"The data moat is drying up. The new competitive advantage is decision traces."
Data is commoditizing. Everyone has access to similar information. LLMs can process it similarly.
But decision traces — the accumulated patterns of judgment, the organizational physics, the "why" behind the "what" — those are unique to each organization.
The most valuable IP an organization produces isn't its data. It's its accumulated patterns of judgment.
| Problem | How Context Graphs Solve It |
|---|---|
| Schema-truth gap | Capture the "why," not just the "what" |
| Agents guessing | Provide decision-time context with constraints |
| Exception drift | Enforce reuse conditions at runtime |
| Multi-agent chaos | Shared decision ledger, conflict detection |
| Context fragmentation | Platform-level coordination |
| Strategic vulnerability | Customer-owned context infrastructure |
| Commoditized data | Decision traces as the new moat |
What problem do Context Graphs solve in enterprise AI?
They close the schema-truth gap by capturing why decisions were made, not just what happened, preventing agents from guessing or misapplying precedent.
Before building decision traces, you need confidence that:
…are the same entity.
This isn't glamorous work, but it's foundational. Entities must be connected to the right products, contracts, incidents, and people.
"Skip entity resolution, and you don't get context. You get expensive guesswork."
Here's how the layers fit together.
┌─────────────────────────────────────────────────────────────┐
│ Layer 6: GOVERNANCE
│ Policies, constraints, authority bounds
│ (What agents CAN do)
├─────────────────────────────────────────────────────────────┤
│ Layer 5: CONTEXT GRAPH (CONTROL PLANE)
│ Decisions, judgments, precedents, reuse constraints
│ (The core — governs action)
├─────────────────────────────────────────────────────────────┤
│ Layer 4: OPERATIONAL + ANALYTICAL BRIDGE
│ SOPs + metric definitions
│ (Connects the two halves of context)
├─────────────────────────────────────────────────────────────┤
│ Layer 3: ENTITY RESOLUTION
│ Unified identity across systems
│ (Foundation for everything above)
├─────────────────────────────────────────────────────────────┤
│ Layer 2: KNOWLEDGE GRAPH
│ Entities, relationships, attributes
│ (State Clock — what exists)
├─────────────────────────────────────────────────────────────┤
│ Layer 1: SYSTEMS OF RECORD
│ CRM, ERP, Billing, Support, Data Warehouse
│ (Existing silos — not going away)
└─────────────────────────────────────────────────────────────┘
Map the decision points across your organization:
| Domain | Decision Points |
|---|---|
| Sales | Discount approvals, deal exceptions, pricing overrides |
| Support | Escalations, SLA exceptions, refund approvals |
| Finance | Payment terms, penalty waivers, budget exceptions |
| HR | Policy exceptions, approval workflows |
| Operations | Vendor decisions, procurement approvals |
For each decision, capture:
decision_trace:
id: "DEC-2025-03-001"
timestamp: "2025-03-14T10:30:00Z"
decision_type: "sla_penalty_waiver"
# What was decided
outcome: "exception_granted"
# Inputs considered
inputs:
- type: "incident"
ref: "INC-2025-001234"
- type: "external_event"
ref: "AWS-OUTAGE-2025-03"
- type: "policy"
ref: "SLA-POLICY-v3.2"
section: "Force Majeure Clause §4.2"
# Context at decision time
context:
operational: "Vendor response within SLA for controllable factors"
analytical: "Vendor health score: 78"
# Judgment
conflict_detected: "Breach vs Force Majeure"
judgment: "Exception granted - outage-related delays excluded"
rationale: "Vendor demonstrated good faith response"
# Authority
authority:
approver: "sarah.chen@company.com"
role: "Regional Finance Director"
scope: "Regional exceptions < $50K"
# Validity and reuse
temporal_validity:
start: "2025-03-12"
end: "2025-03-14"
reuse_constraints:
- "Requires documented external event"
- "Same region must be affected"
- "Does NOT set precedent"
| Source | How to Capture |
|---|---|
| Approval workflows | Hook into ServiceNow, Jira, custom systems |
| Email / Slack | NLP extraction of decisions and rationale |
| CRM stage changes | Capture reason codes and notes |
| Support tickets | Extract escalation decisions |
| Meeting notes | Parse decision outcomes from transcripts |
Node Types
| Node Type | What It Represents |
|---|---|
| Decision | The decision itself (first-class object) |
| Evidence | Facts that informed the decision |
| Policy | Rules that applied (with version) |
| Authority | Who decided, with what scope |
| Context | Operational and analytical frame |
| Outcome | What resulted from the decision |
Edge Types
| Edge | Connects | Purpose |
|---|---|---|
| INFORMED_BY | Decision → Evidence | What facts were considered |
| APPLIED_POLICY | Decision → Policy | Which rules governed |
| AUTHORIZED_BY | Decision → Authority | Who approved |
| WITHIN_CONTEXT | Decision → Context | Frame at decision time |
| RESULTED_IN | Decision → Outcome | What happened |
| PRECEDED_BY | Decision → Decision | Decision chain |
| SETS_PRECEDENT_FOR | Decision → Constraint | Reuse conditions |
| SIMILAR_TO | Decision → Decision | Precedent matching |
Technology Options
| Option | Best For |
|---|---|
| Neo4j | Complex traversals, mature tooling |
| Amazon Neptune | AWS integration, managed service |
| TigerGraph | High-performance analytics |
| Dgraph | GraphQL native |
| Postgres + JSON | Existing stack, simpler queries |
Connect the two halves.
┌─────────────────────────────────────────────────────────────┐
│
│ OPERATIONAL CONTEXT ANALYTICAL CONTEXT
│ (How we work) (What things mean)
│
│ ┌─────────────────┐ ┌─────────────────┐
│ │ Exception │◄────►│ Customer Health
│ │ policies │ │ score definition
│ └─────────────────┘ └─────────────────┘
│ │ │
│ └──────────┬──────────┘
│ │
│ ▼
│ ┌─────────────────────────────────────────────┐
│ │ DECISION: Override health score
│ │ REASON: Champion departure signals risk
│ │ despite quantitative score
│ └─────────────────────────────────────────────┘
│
└─────────────────────────────────────────────────────────────┘
This is the critical capability. Before an agent reuses any precedent:
REUSE CONSTRAINT CHECK
IF ANY CHECK FAILS → ESCALATE
IF ALL CHECKS PASS → PROCEED WITH AUDIT LOG
| Type | Description | Example |
|---|---|---|
| temporal_bound | Valid only within window | "Mar 12-14, 2025" |
| authority_scope | Requires approval level | "Regional FD or above" |
| condition_match | Specific conditions required | "Documented external event" |
| entity_scope | Applies to specific entities | "Same vendor" |
| no_precedent | Explicitly doesn't set precedent | "One-time exception" |
| threshold_based | Value within range | "Impact < $50K" |
Agents need APIs to query the Context Graph at decision time.
Find similar precedents:
Query: "Find decisions similar to current situation"
Returns: Matching decisions with similarity scores
Filter: Must pass reuse constraint check
Get applicable policies:
Query: "What policies apply to this decision type?"
Returns: Current policy versions with relevant sections
Filter: Effective date, expiry date
Check authority:
Query: "Does this actor have authority for this action?"
Returns: Yes/No with scope details
Include: Delegation chain if applicable
Get full decision context:
Query: “Give me everything needed to make this decision”
Returns: Entity context, precedents, policies,
operational context, analytical context
| Query Type | Target Latency |
|---|---|
| Precedent lookup | < 100ms |
| Policy retrieval | < 50ms |
| Authority check | < 50ms |
| Full context assembly | < 500ms |
Track Outcomes
When a decision is reused, was the result good?
outcome_tracking:
decision_id: "DEC-2025-06-042"
based_on_precedent: "DEC-2025-03-001"
outcome:
status: "success" | "failure" | "partial"
timestamp: "2025-06-20T14:30:00Z"
metrics:
financial_impact: "$8,200"
customer_satisfaction: "maintained"
compliance_issues: "none"
precedent_feedback:
was_precedent_helpful: true
similarity_score_accurate: true
constraints_appropriate: true
Based on outcomes, adjust confidence in precedents:
Precedent Quality Score = f(
times_reused,
successful_reuses,
outcome_severity_when_failed,
time_since_creation,
context_drift_indicators
)
As decisions accumulate, patterns emerge:
Define who can do what:
authority_model:
roles:
- name: "Regional Finance Director"
scope:
geographic: "regional"
financial_limit: 50000
decision_types:
- "sla_penalty_waiver"
- "payment_term_exception"
can_delegate_to:
- "Finance Manager"
escalation_rules:
- condition: "financial_impact > authority.financial_limit"
action: "escalate_to_next_level"
- condition: "decision_sets_precedent"
action: "require_additional_approval"
Not everyone should see everything:
Context Graphs need ongoing governance:
Foundation
| Metric | What It Measures | Target |
|---|---|---|
| Precedent reuse rate | How often past decisions inform new ones | > 40% |
| Constraint compliance | Decisions that pass reuse checks | > 95% |
| Trace completeness | Decisions with full provenance | > 90% |
| Outcome coverage | Decisions with recorded outcomes | > 80% |
| Context freshness | Age of context at decision time | < 24 hours |
| Escalation rate | Decisions requiring human review | 10–30% |
| False precedent rate | Bad matches that caused issues | < 2% |
| Risk | Description | Mitigation |
|---|---|---|
| Judgment fossilization | "Always done it this way" gets encoded | Decay functions, review cycles, expiration dates |
| Context collapse | Bad precedents matched by naive similarity | Multi-dimensional similarity, human review for high stakes |
| Exception drift | Decisions reused outside valid scope | Explicit constraints, runtime checking, escalation |
| Weak reasoning legitimized | Gut feelings become doctrine | Confidence scoring, outcome tracking, sunset clauses |
| Bias encoding | Organizational dysfunction preserved | Multi-stakeholder capture, regular audits |
| Stale context | System lags reality | Freshness scoring, auto-refresh triggers |
| Innovation suppression | "Never done before" blocks new strategies | Novel-situation flags, innovation escape hatches |
What problem does the “schema-truth gap” describe?
The schema-truth gap is the difference between what systems formally record and what the organization actually knows about why decisions were made.
Remember the $47,000 refund that opened this guide?
With Context Graph infrastructure, when the CTO asks "Why was this allowed?", there's an answer:
“This decision was made at 10:47 AM by Agent-Refund-07. The agent considered customer transaction history, support case CS-2024-1847, and policy document REF-POL-v3.2. The agent found three similar precedents from Q3, but none matched the fraud flag condition present in this case. The agent should have escalated but proceeded because the reuse constraint check wasn't implemented for fraud signals. We've now updated the constraint model. Here are the seven other pending decisions that should be reviewed under the updated constraints.”
That's not just an answer. It's the foundation for improvement.
The shift from systems of record to systems of reasoning isn't optional for enterprises serious about AI. It's the foundation everything else is built on.
Context Graphs are how we build it.
The organizations that build this infrastructure will compound their intelligence with every decision. Those that don't will keep relearning the same lessons, making the same mistakes, and asking "Why was this allowed?" without ever getting a real answer.
Start with entity resolution. Instrument decision points. Build the graph. Implement reuse constraints. Close the feedback loop.
The infrastructure is buildable. The question is whether you'll build it — or let your agents keep guessing.