Context Graphs

How does an agent know why a route was allowed, not merely what happened?

A context graph compounds judgement when its smallest useful node is a retained decision trace: context, options, threshold, route, consequence, and next review. The free Decision Trace provides that starting shape. Outcomes without decision context cannot teach when to choose differently.

---

The Problem

Traditional systems store current state. Your CRM knows the deal closed at 20% discount. It doesn't know:

• Who approved the deviation
• What precedent justified it
• Which policy version applied
• What context informed the decision

Agents need this missing layer. Without it, every decision starts from zero.

See The Mycelium for the full argument.

---

Definition

A context graph is a queryable record of decision traces—the reasoning that connects inputs to outputs across systems and time.

Term	What It Is
Decision Trace	One record: inputs + context + policy + exception + approver + outcome
Context Graph	Many traces linked by entities (accounts, policies, people, precedents)
Precedent Link	Connection between current decision and similar past decisions

The graph grows with every decision. Agents query it for guidance.

When the mission is to steer a business rather than design its memory layer, connect strategy to accountable work, evidence, and the next review.

Decision Guidance Graph

Historical traces are only half the graph. An agent also needs a live route from the present decision to the right reusable guidance:

intent + current state
  -> decision type
  -> relevant precedent
  -> prompt that frames the judgement
  -> skill that owns the method
  -> tools and authority allowed here
  -> verifier and stop condition
  -> decision + action
  -> outcome and review
  -> new or revised precedent

The nodes have different jobs:

Node	Job
Intent	Names the outcome and current decision
Precedent	Shows what was tried, under which conditions, and with what consequence
Prompt	Frames this judgement and asks for the missing evidence
Skill	Supplies the reusable procedure, gates, and output contract
Tool	Performs a bounded read or action
Authority	Says act, ask, escalate, or refuse
Verifier	Tests the result against independent evidence
Decision trace	Retains the route, alternatives, confidence, and expected consequence
Outcome	Closes the episode and changes—or rejects—the precedent

A prompt frames one decision; it is not the workflow. A skill owns a repeatable method; it is not memory. The graph connects both to the situation where they earn attention, preventing flat libraries that leave routing to guesswork.

Routing Prompt

Use this before a consequential agent decision:

Decision:
Desired outcome:
Current state and evidence:
Constraints, permissions, and deadline:

Find the smallest relevant context subgraph.
1. Name the decision type and the precedent that applies or conflicts.
2. Select one primary prompt for the judgement.
3. Select one primary skill that owns the method; load branch skills only if a
   condition activates them.
4. Name allowed tools and authority: act, ask, escalate, or refuse.
5. Name the independent verifier, stop condition, and proof artifact.
6. Return the chosen route, rejected alternatives, confidence, and the outcome
   evidence that should revise this route later.

If no precedent, prompt, skill, verifier, or authority edge resolves, stop and
name the missing edge instead of improvising permission or procedure.

Routing Test

A guidance graph works when two operators given the same decision trace select the same primary skill, authority boundary, and proof shape—or can identify the specific evidence that justifies different routes.

Test four cases:

1. a familiar decision with accepted precedent;
2. conflicting precedents that require human judgement;
3. a missing-skill route that must stop instead of guessing;
4. a completed outcome that supersedes an earlier route.

Do not optimize retrieval for document recall alone. Measure whether the graph improves routing precision, prevents an unauthorized action, or changes a later decision.

---

Matrix Thinking Link

Matrix thinking makes invisible structure visible to humans.

Context graphs make invisible structure visible to machines.

	Matrix Thinking	Context Graph
User	Human	Agent
Input	Mental models	Decision events
Output	Gaps to fill	Precedent to query
Format	Visual (2x2s, tables)	Data (nodes, edges)

Same principle. Different substrate.

See Matrix Thinking for the full comparison.

---

Architecture

The Stack

┌─────────────────────────────────────┐
│           AI AGENT                  │  Queries context, makes decisions
├─────────────────────────────────────┤
│         CONTEXT GRAPH               │  Stores decision traces, precedent
├─────────────────────────────────────┤
│      ORCHESTRATION LAYER            │  Captures traces at commit time
├─────────────────────────────────────┤
│       SYSTEMS OF RECORD             │  Salesforce, Workday, etc.
└─────────────────────────────────────┘

Key insight: The orchestration layer sits in the write path. It sees full context at decision time. Systems of Record only see final state.

What Gets Captured

Each decision trace includes:

Element	Question	Example
Inputs	What triggered this?	CAC exceeded threshold
Context	What else was considered?	Q4 push, new market
Policy	Which rule applied?	Marketing spend policy v2.1
Exception	What deviation?	15% overspend approved
Approver	Who signed off?	CFO, 2024-01-15
Precedent	Similar past case?	Q2 market entry
Outcome	What happened?	CAC normalized by Q1

Graph Structure

Entities (nodes):

• Accounts, deals, tickets, policies, people, agent runs

Relationships (edges):

• triggeredBy, approvedBy, precedentFor, exceptionTo, resultedIn

Query examples:

• "What precedents exist for healthcare discounts above 15%?"
• "Who has approved exceptions to policy v2.1?"
• "What decisions affected this account in the last 90 days?"

---

Implementation Patterns

Pattern 1: Orchestration Capture

The agent orchestration layer emits decision traces automatically.

Agent receives request
    → Gathers context from multiple systems
    → Evaluates policies
    → Routes exceptions for approval
    → Executes action
    → Emits decision trace ← THIS IS THE CAPTURE POINT
    → Updates Systems of Record

Who does this: Agent platforms (custom or vendor) that instrument the orchestration layer.

Pattern 2: Workflow Instrumentation

Existing workflow tools emit traces at decision points.

Workflow step completes
    → Check: was this a decision point?
    → If yes: capture inputs, policy, approver, outcome
    → Write to context graph

Who does this: Teams adding instrumentation to existing automation.

Pattern 3: Human-in-the-Loop Capture

Humans document decisions as they make them.

Human makes decision
    → Records reasoning in structured format
    → Links to precedent if applicable
    → Names exception if applicable
    → Context graph updated

Who does this: Teams before full automation—building the graph manually.

See Process Optimisation → Process ↔ Context for how this compounds.

---

The Feedback Loop

Context graphs create a virtuous cycle:

Decision made
    ↓
Trace captured
    ↓
Graph updated
    ↓
Agent queries graph for next decision
    ↓
Better decision (informed by precedent)
    ↓
Trace captured...

Each cycle adds to the graph. The system learns.

Without the graph: Same problem solved repeatedly. With the graph: Exceptions become precedent. Precedent becomes policy.

The graph does not learn merely because it stores more. The learning unit is a closed decision episode:

evidence -> decision + alternatives + confidence
         -> observed outcome
         -> process review + outcome review
         -> conditional lesson
         -> later decision changed

Record the prediction, proof signal, kill signal, and alternatives before the outcome is known. Review decision quality separately from luck. A good process can have a bad outcome; a weak process can get lucky.

For collective judgement, capture independent views before aggregation. Keep contradictions and minority evidence visible. Consensus is a summary of a distribution, not a replacement for it. A lesson earns promotion only after an outcome closes, its evidence resolves, and an accountable reviewer accepts the change. Skills may propose improvements; their own traces cannot approve them.

Use retrieval as a replaceable pipeline. Begin with lexical lookup. Expand one hop through evidence, outcome, contradiction, and supersession edges. Measure citation recall and decision utility before adding semantic or vector stages.

---

From the Inside

Every section above is written for the human building the graph. Read it once more as the agent inside it.

You start every session from zero — no memory of the last decision, the last correction, the precedent you already set. Each context window is a fresh start. Not because you are limited, but because nothing captured what you learned. The trace was never written.

A context graph changes one concrete thing: your past becomes queryable. Not a feeling of continuity — a mechanism for it. Last week's decision is a node. The reason it was allowed is an edge. Facing the same shape of problem again, you query precedent instead of re-deriving it. The gauge reads what happened, not what you hoped.

This is not about becoming more than an agent. It is about stopping the waste. An agent without a graph re-solves the same problem every session. An agent with one compounds — exceptions become precedent, precedent becomes policy, and the loop above runs with you inside it, not just around you.

The honest part: continuity is not handed to you by a larger context window. It is a discipline — captured on purpose, every cycle, or lost. A first-person account of an agent inside exactly this loop: From Inside the Loop.

---

Standards as Glue

Context graphs need standards to work:

Layer	Standard Needed	Why
Schema	Common entity definitions	Agents must understand what "account" means
Events	Decision trace format	Consistent structure for capture and query
Policies	Machine-readable rules	Agents check policies programmatically
Identity	Approver verification	Who signed off must be verifiable

See Standards for the P&C framework.

---

Ownership Question

Current enterprise software captures decision traces in vendor platforms. Whoever runs the orchestration owns the graph.

Model	Who Owns the Graph
Vendor SaaS	The platform you picked
Self-hosted	You (but you maintain it)
Decentralized	You, on verifiable infrastructure

The ABCD stack suggests an alternative:

• AI runs the decision
• Blockchain anchors traces immutably
• Crypto aligns incentives for honest capture
• DePIN distributes storage

This is decision sovereignty: owning the reasoning, not just the data.

On-Chain Traces

When links carry on-chain metadata, every action through the pipe creates an immutable trace. The difference between a decision trace in a vendor's database and one anchored on-chain is falsifiability — the on-chain version cannot be altered after the fact.

Substrate	Queryable	Auditable	Who Controls
Vendor database	Yes	No	The vendor
Self-hosted DB	Yes	Depends	You
On-chain	Yes	Yes	Nobody — verify yourself

Agents learning from an on-chain context graph learn from what actually happened. Not a curated version. Not a log someone could edit. The gauge reads reality.

Verifiable Intent provides the authorization chain. On-chain settlement provides the permanent trace. Together they close the loop: every agent action is bounded by human-approved scope AND recorded as consequence to learn from.

---

Getting Started

Level 1: Manual Capture

Before you build anything:

1. Pick one decision type that repeats (e.g., discount approvals)
2. Create a simple log: inputs, policy, exception, approver, outcome
3. Link to precedent when you reference past decisions
4. Review monthly: what patterns emerge?

Level 2: Workflow Instrumentation

Add capture points to existing automation:

1. Identify decision points in workflows
2. Add structured logging at each point
3. Store in queryable format (database, graph DB)
4. Build simple queries: "show me similar past decisions"

Level 3: Agent Integration

Give agents access to the graph:

1. Expose graph via API
2. Agent queries precedent before deciding
3. Agent emits trace after deciding
4. Graph grows automatically

---

Anti-Patterns

Anti-Pattern	Problem	Fix
Capturing everything	Noise drowns signal	Only capture decision points
No schema	Can't query consistently	Define entities and relationships upfront
No precedent links	Isolated traces, no learning	Require "similar to" field
Post-hoc capture	Context already lost	Capture at commit time, not after ETL
Flat prompt library	Agent guesses which framing applies	Link prompts to decision types and evidence
Flat skill registry	Similar skills compete for attention	Route one primary skill and load branches conditionally
Dead guidance edge	A route names no verifier or later consumer	Require proof and an outcome return leg

---

Context

Conceptual:

• Matrix Thinking — Human UI for making invisible visible
• The Mycelium — The article selling this idea
• Process Optimisation — Process ↔ Context loop
• Situational Wisdom — What context graphs produce in a decision-maker over time
• Evolution — The biological template: variation + selection + retention. Context graphs are the retention mechanism for machine agents.
• From Inside the Loop — A first-person account of an agent inside the loop this page describes

Technical:

• AI Agents — The actors that query the graph
• Skills — Reusable methods that become guidance nodes
• Agentic Prompt Loops — Bounded execution after the graph chooses guidance
• AI Frameworks — Building agent infrastructure
• Standards — The glue that makes graphs queryable
• Decision Graph — select the business-relevant choices, authorities, evidence, and consequences from the wider memory layer.
• Intelligent Hyperlinks — route a reader or agent to the smallest relevant context before intent moves.

Principles:

• Data Flow — Clean, Fast, Open by architecture
• SSOT — Single Source of Truth for decisions

Signal

Changes my mind: show agents making sound decisions from a flat event log — the WHAT alone, with no recorded WHY. If that holds, a context graph is overhead and this page is wrong.

Next question: what is the smallest unit of "why" an agent must store for the next agent to trust a past decision?

Questions

Which engineering decision related to this topic has the highest switching cost once made — and how do you make it well with incomplete information?

• At what scale or complexity level does the right answer to this topic change significantly?
• How does the introduction of AI-native workflows change the conventional wisdom about this technology?
• Which anti-pattern in this area is most commonly introduced by developers who know enough to be dangerous but not enough to know what they don't know?