The Context Graph is the latest obsession in the AI world. Context Graphs promises to solve the AI agents problem for decision-making but misses the mark by a lot! Understand the issues of the design and avoid a Trillion-Dollar mistake.

If you’ve read the recent thesis from Foundation Capital, the pitch is seductive: Enterprise data is fragmented, and critical decision-making logic is lost in Slack threads and Zoom calls. Their proposed solution is to record every “decision trace,” stitch them into a massive graph, and let AI agents query this history to guide future actions.

While the problem is real as agents absolutely lack cross-system awareness, the solution collapses concerns, inverts causality, and attempts to inject structure after execution rather than before.

They call this AI’s “Trillion-Dollar Opportunity.”

I call it

The decision archaeology and a Trillion-Dollar Mistake.

This isn’t decision intelligence. It is decision archaeology that addresses symptoms of issues from data-driven mindset using LLMs driven agent hallucinating and making up facts.

We have to address the root cause not doubling down on what it caused the issue in the first place.

Here is why relying on “what happened” to determine “what should happen” is a fundamental architectural flaw, and why the future belongs to those who build decisions explicitly using proper decision modeling such as DMN, or Dynamic Decision Graph (DDG) and activate them using Continuous Decision Model (CDM).

The Trap of “Inductive” AI

The Context Graph model relies on a dangerous assumption: that history is the same thing as rules and policy.

It assumes that if you collect enough historical data (logs, traces, emails), you can infer the correct rules for the future. In data science, this is inductive reasoning. In the enterprise, it is a liability.

Imagine a VP approves a 30% discount on a Friday afternoon because a specific client had a bad service experience. It was a one-off exception.

  • The Context Graph records this trace. When an agent encounters a similar client next month, it queries the graph, sees the precedent, and suggests a 30% discount. It treats the exception as the rule.
  • The Reality is that the discount was an anomaly, not a policy.

By using decision traces to guide agents, you treat precedent as policy. This leads to bias reinforcement, policy drift, and the calcification of bad habits. You aren't building an intelligent system; you are building a system that blindly repeats the organization's past mistakes.

Why “Decision Archaeology” Fails

The Context Graph approach attempts to solve the intent and logic problem with a data-driven solution. It forces the agent to become an archaeologist, sifting through layers of broken pottery (logs and traces) to guess what the vase originally looked like.

The Context Graph mixes logs, traces, data, rules, and decisions with no boundary, collapsing them into one structure. But these elements serve different roles:

  • Logs record raw events
  • Traces describe what happened
  • Data feeds the decision
  • Rules define the guardrails and policies
  • Decisions define the outcome and the rationale

When all of these are thrown into a single graph, the system loses the ability to distinguish what defines a decision, what governs it, and what simply describes it. The result is not context. It is structural confusion.

The hope to reconstruct the original structure of a decision fails in three critical ways.

1. It Confuses Memory with Meaning

A Context Graph can tell you that Person A spoke to Person B about Topic C. It connects the dots. But it cannot define intent. Without an explicit model, the system cannot distinguish between:

  • Valid logic vs. Invalid logic
  • Current policy vs. Deprecated rules
  • Governed norms vs. Ad-hoc exceptions

The intent, situation, and relevance of past events cannot be reconstructed from logs or traces of “who talked to whom”. They must be modeled explicitly and activated at runtime.

2. It Inverts the Lifecycle of Context

A context for decision execution must be constructed before the actual executed. It is the safe, governed boundary of inputs relevant to this specific instance.

The Context Graph relies on the same architecture that powers most modern LLM applications (Retrieval-Augmented Generation, or RAG): store everything first, figure out what matters later.

This inverts the necessary lifecycle of safe decision-making. The system waits for a query, then searches through history (logs, vectors, graph edges) to find similar past events. It tries to reconstruct context from the rear-view mirror, relying on the statistical hope that similar looking text equals relevant business logic.

That isn't context; that is just accidental events server as memory. An agent acting on this memory is not following rules. It is just improvising based on signals from the past.

3. It Creates a “Black Box” of Precedent

When an agent uses history as its instruction manual, explainability vanishes.

If you ask a Context Graph agent why it denied a claim, it cannot cite a specific rule or policy. It can only cite a statistical correlation. It sees a cluster of denied claims in the past that look mathematically similar to the current one, so it mimics the pattern.

  • Manager: “Why did you deny this claim?”
  • Agent: “Because it is statistically similar to 500 denied claims from last year.”

That is not an explanation. That is just a correlation. In regulated industries like Finance, Healthcare, and Legal, “because we usually do it this way” is not an audit trail. It is a liability.

The Better Way: Model Explicitly, Don't Stitch

To build agents that are safe, explainable, and reliable, we need to stop stitching traces and start defining models. The correct architecture relies on CDM (Continuous Decision Model), DMN (Decision Model and Notation), (DDG) Dynamic Decision Graph and LiveContext.

Here is how the hierarchy of needs actually works:

1. The Intent Layer (DMN or DDG)

“What is the outcome and how are we going about it?”

Instead of inferring rules, we use a decision model such as DMN to Dynamic Decision Graph to explicitly map inputs to outcomes and rationale. This is the decision blueprint. It provides clarity by design, ensuring that every decision is traceable to a specific, current policy not a vague “similarity” to a past event.

Explicitly modeling decisions is how you achieve to transparency at execution and explainability and defensibility.

2. The Flow Layer (CDM)

“When should this decision happen?”

This is the traffic controller. It manages the stages of the business journey. It determines if a decision should be triggered, suppressed, or escalated based on the current situation. It provides situational awareness through modeling, not based on signal guessing.

3. The Input Layer (LiveContext)

“What data matters right now?”

Instead of dumping a massive, noisy graph into the agent's context window, LiveContext pulls specific, governed, semantically valid decision-ready data required for this specific decision model. It is precise, minimized, and relevant to the decision, and its situation.

4. The Trace (The Output)

“What happened?”

This is the crucial distinction. In a proper architecture, the trace is the receipt, not the recipe. It is captured after the decision for audit and learning, but it does not blindly drive the next decision.

5. The Learning (Adaptive)

“What to optimize?”

In this Context Graph there is no optimization, in fact it’s all about data-driven hopes and dreams. It misses the critical requirement that decisions must improve over time. In a proper architecture, optimization is explicit: inside the decision model for short-term tuning, and inside the Continuous Decision Model (CDM) for long-term KPIs. This ensures the system actually learns from past outcomes and their impacts rather than just repeating them.

Book a Custom Demo

First or last name is too short






The Verdict

The industry is currently obsessed with “Magic AI” the idea that if we just feed enough unstructured data into a model, intelligence will emerge. Context Graphs are an extension of that magical thinking.
But enterprise operations are not magical; they are deterministic. Payroll must be correct. Compliance must be followed. Margins must be preserved.

If you are building the next generation of enterprise software, you have a choice:

  1. The Decision Archaeology Approach: Build a system that guesses what to do based on the-best-efforts of what you used to do.
  2. The Decision-Centric Approach: Build a system that knows what to do because you defined the intent. Ensure decisions are first-class citizens of organizations.

If you want agents that act with clarity rather than confusion, stop stitching the past. Instead, design agents based on Decision Intelligence rather than Decision Archaeology:

Published January 12th, 2026 at 07:00 am