There is a difference between a system that remembers a decision and a system that enforces it. Most teams who adopt AI coding agents invest in the former — better prompts, longer context, richer CLAUDE.md files — without recognizing that this only solves continuity within a session. The problem is structural: session memory and architectural governance are different things, and conflating them is the primary reason architectural drift compounds across agent workflows.
Decision continuity names that structural property precisely. Not "does the agent know about the decision this session?" but "will the decision be enforced identically regardless of which session is running, which agent is involved, and whether any previous agent ever saw the decision at all?"
What decision continuity actually means
Continuity is a system property, not a per-session property. The distinction matters because it determines where the governance responsibility sits. In a per-session model, continuity depends on whether the right context was injected into the right session at the right time. In a system model, continuity is an invariant that the governance infrastructure maintains regardless of session state.
A governance decision is "continuous" when three conditions hold simultaneously:
- Agent-independent. The decision is enforced by Agent A in the same way it would be enforced by Agent B, even if Agent B has never been told about the decision before.
- Session-independent. The decision is enforced in Session 47 the same way it was in Session 1, even if no agent in Sessions 2–46 ever encountered it.
- History-independent. An agent enforcing the decision doesn't require knowledge of how previous agents handled it. It queries the corpus; the corpus carries the authority.
Achieving all three requires the decision to live in a version-controlled, externally-queryable corpus — not inside any agent's context window, not in a file that must be manually included, and not in a system prompt that requires human maintenance across tool upgrades.
Continuity is not about memory quality. A longer context window doesn't provide decision continuity. A more comprehensive CLAUDE.md doesn't provide it. These improve per-session recall, which is valuable — but they fail at the boundary: when a session ends, the improvement ends with it.
Why this problem exists in AI-native development
The structural problem is that AI coding agents operate in stateless sessions. Each new session starts without memory of previous sessions. This is not a bug or a limitation that will eventually be solved — it is a fundamental property of how current LLMs work. Context windows are bounded, sessions are ephemeral, and there is no persistent shared memory across agent invocations unless something external provides it.
In human software development, this isn't a problem because humans carry architectural knowledge across time. A developer who made a decision in a code review three months ago still knows about it today. They apply that knowledge when they review new code, answer questions from colleagues, or catch a PR that violates the pattern. The knowledge is persistent because the person is persistent.
In AI-native development, that persistence doesn't exist by default. An agent starting a session to implement a new feature has no knowledge of the architectural decisions made in previous sessions — unless those decisions are explicitly provided. The burden of maintaining that continuity falls on whoever designs the governance system.
If the governance system is session-scoped — decisions living in CLAUDE.md files, injected RAG passages, or tool configurations — then architectural knowledge expires at every session boundary. The compounding effect is severe: each new session is essentially starting from scratch on governance, relying on whatever context was injected that time. Drift compounds across handoffs because no single agent ever has a complete picture of all decisions in effect.
The session boundary is the governance failure point. Every time a context window resets, session-scoped governance resets with it. In a development workflow with dozens of agent sessions per day across multiple engineers and tools, those failures accumulate silently — each agent unaware that it's operating on incomplete architectural context.
The common misread: treating prompt memory as governance
The most widespread failure mode is treating CLAUDE.md files, per-session context injection, and prompt memory as a governance system. This is the misread that decision continuity names. These mechanisms are valuable — they improve agent behavior within a session — but they provide continuity within a session, not across sessions, agents, or retries.
Consider what happens in a typical multi-session workflow:
- A team documents their architectural decisions in a CLAUDE.md file and injects it at session start.
- An agent in Session 1 respects those decisions and generates compliant code.
- Session 2 starts with a new agent, different tool, different engineer. The CLAUDE.md file may or may not be included. If included, it may have been updated. The agent has no way to verify whether it matches what Session 1 used.
- A decision conflict arises — Session 2's context is subtly different from Session 1's. The agent follows what it was told. No one notices.
- Session 10, Session 20, Session 47: drift has accumulated. The codebase reflects multiple contradictory governance contexts, each one locally coherent but globally inconsistent.
A team that governs through prompt memory has a governance system that resets every time a new agent starts. The reset is invisible. The drift is silent. The compounding is structural.
| Property | Prompt Memory | Decision Corpus |
|---|---|---|
| Scope | Per-session | All sessions, all agents |
| Persistence | Ends at context reset | Version-controlled; permanent |
| Consistency | Depends on injection order | Identical query, identical result |
| Auditability | Not auditable across sessions | Commit log; full history |
| Agent-independence | No — depends on config | Yes — corpus is the authority |
How this fits the AI SDLC
Decision continuity is enabled by the governance infrastructure layer — specifically by storing decisions in a version-controlled corpus that every agent queries identically. In the Mneme architecture, that corpus is project_memory.json. The corpus lives outside any agent's context. It is not injected by a human. It is queried by the governance system at generation time, using deterministic retrieval.
The key architectural consequence: the decision is the continuous element, not the agent's memory of the decision. A new agent starting a fresh session doesn't need to be told about previous decisions. It queries the corpus. The corpus tells it what is in effect. The corpus is always current because it is version-controlled. The agent enforces whatever the corpus says, regardless of what any previous agent knew.
This is the same pattern that makes database-backed applications resilient: the database is the source of truth, not the application's in-memory state. An application server that crashes and restarts doesn't need to rebuild its knowledge from previous sessions — it reads from the database. Decision continuity applies the same principle to governance: the corpus is the source of truth, not any agent's context.
Decision continuity in multi-agent pipelines
The benefits compound in multi-agent workflows. In an agentic pipeline — planner agent, coder agent, reviewer agent, CI agent — each agent has its own LLM, its own context window, its own session lifecycle. Without a shared external corpus, governance would require explicit handoffs: the planner passes decisions to the coder, the coder passes them to the reviewer, and so on. Any broken link in the handoff chain means a downstream agent operates without the full governance context.
With a shared decision corpus, handoffs don't carry governance burden. Each agent queries the corpus independently at query time. The planner doesn't need to package its governance context and pass it to the coder. The coder doesn't need to understand what the planner decided. Both query the corpus; the corpus provides the same authoritative decisions to both. The pipeline is architecturally coherent without requiring explicit governance coordination at each step.
In a multi-agent pipeline, the governance corpus is the shared memory that all agents inherit. It is not passed between agents. It is not reconstructed at each handoff. It exists in one place, is queryable by any agent at any time, and provides the same answer to the same query regardless of who is asking.
What decision continuity requires in practice
Achieving decision continuity requires four concrete properties from the governance system:
- External storage. Decisions must live outside any agent's context window. A file that is read by the governance system, not injected into the agent prompt by a human.
- Version control. The decision corpus must be version-controlled so that its history is auditable. When did a decision change? Who changed it? What did it say before? These questions must have answers.
- Deterministic retrieval. The same query against the same corpus must return the same decisions. If retrieval is probabilistic, continuity is probabilistic — which means it isn't continuity at all.
- Session-agnostic access. Any agent, in any session, using any tool, must be able to query the corpus and receive the same result. The corpus access cannot depend on session state or prior context.
Prompt memory satisfies none of these. A version-controlled decision corpus satisfies all four. That gap is precisely why decision continuity is a distinct concept — and why solving the memory problem doesn't solve the governance problem.