THINKING
Context is shared. Commitment is not.
Everyone is talking about context management. RAG pipelines, memory systems, knowledge graphs, long-context windows. The question driving most of the work: how do you give agents enough information to act well?
It is the right question. But context is not commitment.
The problem is not the information. It is that the decisions made from that context have no persistent form. They exist as action, not as record.
Facts are not enough either
The standard response is better memory: store more, retrieve better, keep agents informed. This helps. But facts alone do not solve the coordination problem, because coordination failures are not caused by missing information. They are caused by missing decisions.
A fact is static: this is what we know. A decision is relational: based on this data, someone chose this direction. It has a basis, an author, and consequences. And unlike a fact, a decision can be revisited, refined, or replaced.
The failures that follow are recognizable. Agents re-derive decisions already made. Two agents make contradictory calls from identical source material. An agent overwrites a prior direction with no trace of what changed or why. These are not memory failures. They are commitment failures: the system has no durable record of what has been adopted, by whom, under what scope, or what breaks downstream when it changes.
Four distinct things go wrong. Agents hold different views of what has been committed. A plan exists but nobody knows if it has been adopted. It is unclear who can revise or supersede a prior call. Later actors cannot reconstruct why something was chosen or what it affects.
Context management helps with the first. It does not address the other three.
What is missing is not more context. It is a shared commitment ledger: a durable record of what has been committed, by whom, under what scope, and what depends on it. The solution is to make decisions the load-bearing unit of that ledger.
Blackboard architectures, DMN, and recent write-side memory adjudication work have explored adjacent problems. Rosen and Rosen's May 2026 preprint on durable intermediate artifacts is the closest public formulation. Their framing centers on artifacts broadly; ours centers on decisions as the specific coordination primitive, the normative layer that governs agent behavior rather than merely preserving agent work product. What we are describing is a practical implementation with MCP-native coordination and typed state. Not a claim to have invented the underlying insight.
Decision states as agent signals
A decision is worth capturing when it constrains future agent behavior or commits direction. Not every micro-choice. The sparseness is a feature. A bloated decision layer is bureaucratic exhaust, not coordination.
A decision is a typed record. It carries: the specific data and context it was derived from, the author (human or agent), and a state. The state is not administrative. It is a precise signal to every agent that encounters it.
| State | Signal to the agent |
|---|---|
| Proposed | Someone is already working on this. Do not duplicate the reasoning. |
| Active | Active constraint. Work within it. |
| Amended | Still valid, but refined. Read the amendment for the full picture. |
| Superseded | No longer valid. Trace to what replaced it and why. |
> These four states are a working vocabulary, not a complete lifecycle model. In a full implementation, amendment is better modeled as a lineage relation. A decision can be Active and amended simultaneously. The table reflects how agents should read the signals; the architecture is a separate conversation.
"Amended" and "superseded" are not synonyms. They say something different.
An amended decision means the intention holds, but something concrete has changed in the implementation or framing. The agent should read original and amendment together. The old decision is not wrong. It is refined.
A superseded decision means something fundamental has shifted. The intention no longer holds. The old decision is now only historical. The agent should trace forward to what replaced it, not try to reconcile the two.
This distinction has real consequences for a swarm. An agent encountering an amended decision knows to combine both for the current picture. An agent encountering a superseded decision knows to stop and look for what comes next.
Relations between decisions can begin as simple references: a slug, a link, a named source. That is enough to get started. What makes the model scale is a backend that maintains the reverse index: given this document, what depends on it? That is the infrastructure that makes the next two capabilities possible.
Not all edges carry the same weight. Asserted edges are declared explicitly when a decision is created or consumed. They drive enforcement and impact preview. Inferred edges are derived from agent reasoning, traces, or natural language. They drive warnings and review requests, never hard invalidation. Treating both as equivalent is where reverse dependency systems break down.
The author holds the thread
AI work in this model happens in natural language. A decision is not a schema entry or a status flag. It is a written statement: grounded in specific context, readable as text, legible to the next agent or human who needs to understand what was committed and why.
The human plays the role of author. Not approver, not monitor. Author. The person who holds the narrative thread across sessions, agents, and the gaps between them. When a new agent starts, it reads what came before and builds on it. The work has continuity because one voice carries it forward.
In practice, that means a routing and ownership system: explicit roles, defined escalation criteria, and risk-tiered approval. Cosmetic changes auto-approve. Isolated changes need a quick sign-off. Behavioral or cross-cutting changes require full review. The categorization is not automated judgment. It is a rule the team defines upfront.
The author's role is not to manage every agent action. It is to maintain the shared commitment ledger: propose, approve, refine, supersede. And to inspect continuously. Not as a one-time setup. As ongoing process engineering.
This is a new kind of work. Not architecture review as a phase. Authorship at the speed of agent execution. Continuous process optimization.
CI for your decision layer
Schedule an agent to traverse the active decision tree periodically. For each active or amended decision: is the data it was based on still current? Has anything changed that would alter this call? Flag what has drifted. Surface it for the author before the next agent runs into a stale constraint.
This is CI for your decision layer. The agent does the sweep. The swarm does not run into outdated ground.
Not every signal goes to human review. Low-impact drift is handled by the CI agent itself: revalidation, reindexing, updated confidence markers. Structural changes escalate: breaking compatibility, superseded active decisions, significant scope shifts. CI that routes every dependency shift to a human is not CI. It is bureaucratic exhaust.
The sweep does not have to wait for a schedule. When a source document changes state, the decisions that depend on it can receive a signal immediately. The author sees the dependency break before the next agent run encounters a stale constraint. Periodic inspection catches gradual drift. Reactive signals catch the moment it happens.
The model also works in reverse. Before an author changes or removes source material, the system can surface everything that depends on it. Changing this document affects these eight decisions. Archiving this item will flag three active constraints for review. This is impact preview: not a post-facto flag, but a pre-action signal. The author acts with full visibility into downstream consequences.
Process as state
Most systems treat process and content as separate concerns. One layer governs what exists. Another governs how it moves. The two communicate at the edges.
The model described here does not separate them. A step in the pipeline is a state. Process lives in the same model as the content it governs, subject to the same access rules, the same audit trail, the same dependency graph.
This matters because it changes the scale at which optimization happens. A small adjustment stays local and touches nothing else. A fundamental change propagates to everything that depends on it. Both are the same operation on the same model. The system does not need to know in advance which kind of change you are making. The dependency graph handles it.
That is what makes continuous process optimization tractable. Not a separate infrastructure for process management. Process as state.
What the backend has to provide
For this model to work, the backend has to treat decisions as first-class content. Typed storage. Explicit states. Access control. Audit trail. The same model as anything else in the system.
It also has to maintain the reverse index. Given this document, what depends on it? The decisions are not just records. They are a live dependency graph. That is what makes reactive signals and impact preview possible, and what separates a shared commitment ledger from a decision log.
The backend is the shared ground for agents, humans, and APIs simultaneously. Coordination emerges from state, not from explicit wiring between agents. A step can be added or removed independently. The others do not notice. Nothing else changes.
Context is how agents understand the world. Decisions are how teams stay coherent across agents, across time, and across the gaps between sessions.
This is the philosophy we are building toward with Forge.