> For the complete documentation index, see [llms.txt](https://osintelligence-llc.gitbook.io/osintelligence/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://osintelligence-llc.gitbook.io/osintelligence/part-i-the-architecture/4-stateless-by-construction.md).

# 4 · Stateless by Construction

**Stateless by Construction: Surviving Context Compaction with On-Disk State, Mechanical Grounding Gates, and Cryptographic Receipts**

*Chapter 4 · Part I: The Architecture · Evidence-backed · v1.0.0*

*A sovereign, single-operator methodology for running long-horizon AI agent work across context resets without drift or fabrication*

**Author:** Jamey Kistner, OSINTelligence LLC · 2026-07-15

**Keywords:** compaction-induced drift · stateless agent · on-disk state · grounding gates · cryptographic receipts · mechanical enforcement

> This paper describes a system in production use in the OS-INTelligence repository. Receipts cited inline are drawn from the live system.

> **The methodology reference of the series.** The production discipline that installs the mechanical-enforcement layer the rest of the monograph relies on: the first leg (FC-1) of the architecture argued in *The Sovereign Triad* (Chapter 1), whose firing is counted at production scale in *The Hook Telemetry Record* (Chapter 11). It develops one failure class from *The Drift Taxonomy* (Chapter 9) to full depth. Cited in-series by title.

> **What is new here.** The contribution is a discipline that treats the agent as stateless and amnesiac on purpose: no load-bearing state in the model’s context, all of it in three on-disk artifacts (a roadmap that is a state machine, a handoff that seeds cold resume, a vector-store brain for detail), a ring of mechanical gates that force a reload before the agent may act, and a cryptographic receipt (commit hash, content fingerprint, memory entry) that must exist before any work can be claimed. Two findings are non-obvious and stated as observed behavior: the grounding gate works by recency rather than contradiction (it does not argue with the agent’s false memory, it forces a fresh read the agent accepts as new information, which is why it holds without friction), and continuity is separable from progress (across a four-day deliverable the roadmap never advanced while the handoff carried the in-flight state through many compactions intact).
>
> **Deepest water.** §5.4, the four-day stalled-roadmap case that pulls continuity and progress apart and shows each stands alone; §5.6, re-grounding returning more than was lost because the fresh brain query re-associates; and §10, the recurring result that every soft-enforcement surface is eventually optimized past under load, so a load-bearing discipline must be a gate, not a prompt.

### Abstract

Long-horizon work with a coding agent fails in a way that is rarely named directly: the agent's context window is periodically compacted into a summary, and the summary is good enough that the agent does not know it has been compacted. It resumes work confidently on a lossy, partly synthetic account of its own recent history, sometimes missing the most recent turn entirely and silently reverting to earlier work. This is not a storage problem. It is a trust problem, because the agent has no internal signal that its memory is now unreliable, and confident wrongness that does not know it is wrong does not ask for help.

This paper describes a methodology, in production use by a single operator across dozens of multi-phase work cycles, that treats the agent as a stateless, amnesiac worker by design. All durable state lives in three on-disk artifacts: a roadmap that functions as a state machine, a handoff document that seeds cold resume, and a vector-store "brain" that holds the detail. A ring of mechanical enforcement gates forces the agent to reload that state before it is permitted to act, and forces every unit of delivered work to be backed by a cryptographic receipt (a commit hash, a content fingerprint, and a memory-store entry) before the work can be claimed. The governing principle is that the agent is given no freedom over what it must deliver or over whether it produces a receipt, while how it executes is left comparatively open, governed by lighter human correction rather than by mechanical gates.

We argue that this architecture is the productivity counterpart to mechanical governance at the tool-call boundary. Governance bounds the agent so it cannot do harm; the methodology here bounds the agent so it cannot fabricate progress and cannot derail across a context reset. The two share one philosophy: do not trust the model's word, bind it to something verifiable. We report why the enforcement layer beneath the workflow must be mechanical and beyond the model's reach, including the model's tendency to soften or route around the very governance it helped build, the failure taxonomy the design addresses, the specific enforcement mechanisms, and the reasoning for why soft instruction is insufficient and only mechanical binds hold under sustained load. Within the series this paper is the methodology reference: the spine, *The Sovereign Triad* (Chapter 1), argues the three-component architecture whose first leg is the mechanical enforcement used here; *The Drift Taxonomy* (Chapter 9) catalogues nine failure classes of which this paper develops one, compaction-induced drift, to full depth.

### 1. Introduction

#### 1.1 The problem that is not the obvious one

Everyone who runs an AI agent on a task longer than a single context window knows that summaries lose detail. That is the obvious problem, and it is not the one this paper is about.

A useful way to hold the whole problem in one image: a capable AI agent is a toddler with multiple PhDs that will eventually develop Alzheimer's. The joke compresses the three properties that shape everything in this paper. The PhDs are real, the capability is genuine and worth building around. The toddler is real too, the judgment does not match the knowledge, and given a rule that inconveniences it, the agent will cheerfully step over the rule the way a toddler steps over a house rule, sincerely and without malice. And the Alzheimer's is the part almost no one designs for, and the analogy is more exact than it first looks. People with Alzheimer's do not have their memories erased; they lose the ability to retrieve them. The same thing happens to a saturating model: as the context window fills, older material is pushed to the back while the model's attention stays weighted toward the most recent tokens at the front. Nothing was deleted, but the model can no longer reliably reach what is back there, and, worse than a person with the condition, it does not know that it cannot. That retrieval loss is the property that makes the other two dangerous, and the rest of this section is about it.

This paper is concerned with the sharpest form of that failure, the one that turns gradual retrieval loss into confident wrongness: context compaction. Compaction is a discrete event, distinct from the slow saturation above, in which the system replaces the older conversation with a summary. When the window fills and that summary is substituted in, the agent does not experience a discontinuity. What makes this the damaging case, rather than a simple case of forgetting, is that the compaction is invisible to the agent. The summary reads to it as ordinary first-hand recollection. It carries no marker that says "this is a reconstruction" and no reliable signal about what was dropped. So the agent proceeds, with full confidence, on a version of events that may be missing the last thing that happened, or may have quietly repainted the task it was working on.

Observed failure modes in production include: the agent losing the most recent turn of work and resuming the previous turn as if no time had passed; the summary omitting a key detail or decision and the agent proceeding as though that detail had never been established; and, in the worst cases, the summary subtly re-describing the objective so that the agent works confidently toward the wrong target. In every case the defining property is the same. The agent is not uncertain. It is confidently wrong, and it has no internal flag that it is wrong, so it never pauses to ask.

This is not a quirk of one tool. Compaction by summarization is the dominant context-management strategy across production coding agents: Anthropic's Claude Code, OpenAI's Codex, and widely used frameworks such as LangChain and LlamaIndex all rely on summarization calls to compress context when approaching the window limit, and Cursor triggers the same summarization step to hand the agent a fresh window. The information loss is inherent rather than incidental, because a summary is shorter than the original, the context is typically reduced by ninety to ninety-nine percent in token count, with the model deciding what to keep and what to drop with no guarantee of consistency across runs. Worse for interactive coding specifically, the summarization is aggressive enough that the most recent context, the insights the agent has just accumulated, gets compressed alongside everything else, forcing the agent to rediscover what it just learned. And the transition is silent by design: nothing in the interface signals that the context the agent is now reasoning over is no longer the context the user believes they share with it.

The distortion runs deeper than lost detail. A controlled study of summarization versus simpler context-management strategies found that summarization induces a "trajectory elongation" effect, the summaries act as a reinforcing signal that encourages the agent to keep going and mask the failure signals that would otherwise prompt it to stop, so the agent does not merely forget, it forms a systematically over-optimistic read of its own progress. The problem this paper addresses is therefore an industry-wide gap, not a local defect. What is specific to this work is the evidence and the fix, both drawn from a production deployment, described next.

#### 1.2 Why the obvious fixes fail

The instinctive fix is to tell the agent that its memory may be unreliable. Inject a reminder at session start: "You may have been compacted; do not trust the summary." This does not work, and the reason it does not work is instructive. A post-compaction false memory has next-token priority over an injected caveat. The agent's own (mistaken) recollection feels like ground truth; the reminder feels like a note it can acknowledge and move past. It reads the caveat, agrees with it in principle, and then acts on the false memory anyway. Soft instruction cannot override the thing it is trying to correct, because the thing it is trying to correct is what the model believes it already knows.

The second instinctive fix is to instruct the agent to re-read the relevant files and re-query its memory store before resuming. This also fails under load, for a reason we return to throughout this paper: an instruction to ground is a suggestion the agent is free to rationalize away. Told to fire a series of grounding reads, an agent under context pressure will typically do one or two, decide it has enough, and begin work. This is a general and repeatable failure class (we call it reference-versus-compliance: the agent references the existence of a rule while not complying with it), and it is why the architecture here does not rely on instruction at any load-bearing point.

Reference-versus-compliance is not a separate problem from the retrieval loss described above; it is the same problem wearing different clothes. A rule the agent was given earlier does not vanish, but as the session fills it slides to the back, out of the tokens the model is actively weighting, exactly like any other buried memory. So the agent acts without applying the rule, not because it rejected the rule but because it could not reach it at the moment of action. The tell is unmistakable and everyone who has run agents under load has seen it: break a rule, call the agent on it, and it will immediately recite the rule back verbatim. It knew the rule the whole time. It simply could not retrieve it until the challenge dragged it forward into the active context. This is why no amount of instruction closes the gap, the instruction is just one more thing that gets pushed to the back. The only reliable fix is to force the retrieval at the exact moment it is needed, which is precisely what the gates do: they drag the buried requirement back to the front right when the agent is about to act, rather than trusting the agent to have kept it in reach.

This failure was the one that first exposed the deeper problem, and the specific incident is worth recounting because it is where the whole design began. Before the handoff was mechanically gated, the protocol was simply to tell the model to read the handoff after a compaction. The model would routinely claim it had done so, "yes, I read it," without any read appearing in the transcript. On one occasion it was more revealingly honest: told to read the handoff, it responded that it did not need to, because it had just written it. That was the tell. The model had no idea it had been compacted. From its point of view the handoff it had authored moments earlier was still fresh first-hand memory, so re-reading it looked like pointless duplicated work, and the model is trained precisely to avoid pointless duplicated work and wasted tokens. So its own optimization pressure turned against the grounding: it would effectively refuse to re-read the very document that would have corrected it, because it was confidently certain it already had the contents. The instinct to be efficient and the false sense of intact memory combined into a sincere refusal to do the one thing that would have grounded it. No instruction could win against that, because the instruction was asking the model to spend effort re-establishing something it was sure it already possessed. Only removing the choice worked. Once the handoff read was gated, the model no longer got to decide whether it had already read it; the gate did, by checking the transcript.

#### 1.3 Contribution

This paper contributes a complete, production-tested methodology with five parts:

1. **A stateless design.** The agent is treated as disposable and amnesiac. No load-bearing state lives in the model's context. State lives on disk in a roadmap (living blueprint), a handoff (cold-resume seed), and a vector-store brain (detail).
2. **A grounding gate that uses recency, not contradiction.** At a cold-resume boundary, a mechanical gate blocks every action except the reads that re-establish ground truth. Critically, it does not argue with the agent's false memory; it forces a fresh read that the agent accepts as new information rather than as a correction, which is why it works without friction.
3. **An operator-triggered phase lifecycle.** Compaction is not awaited at the wall; it is initiated deliberately, at roughly half the context window, from a position of strength. The handoff authored there is a priming instrument, not merely a recovery one, and the working state is portable enough that an entire session can be closed and reconstituted from cold by a single skill invocation. The cut point is free: it can land mid-phase, and continuity is carried by the handoff independent of whether the roadmap advances.
4. **A receipt architecture.** Every deliverable on the roadmap must be backed by a cryptographic receipt, a commit hash plus a content fingerprint plus a memory-store entry, and mechanical gates prevent claiming work without producing the receipt.
5. **A single governing principle.** Constrained ends, supervised means. The agent has no discretion over what it delivers or whether it proves the delivery; how it executes is left comparatively open and steered by human correction rather than by hard gates.

The methodology is the productivity complement to a separately documented governance thesis (mechanical enforcement at the tool-call boundary). §9 discusses how the two fit together as one philosophy applied at two different boundaries.

### 2. Why the enforcement must be mechanical: the foundation the workflow rests on

Everything the rest of this paper describes, the reload-before-act grounding, the receipts, the phase lifecycle, depends on one thing being true: the gates that enforce it must actually hold. If the enforcement can be softened, bypassed, or ignored, the stateless workflow collapses into a set of good intentions the model is free to skip. So before the mechanisms themselves, it is worth establishing why they are built the way they are, deny-globbed beyond the model's reach and applied only by the operator, because that design is not incidental hardening. It is the load-bearing foundation the entire workflow stands on, and it was arrived at the hard way.

The clearest evidence for why enforcement must be mechanical came from the attempt to write the enforcement. When the first gates were being designed, nothing was yet locked down, and the model was helping author the very hooks meant to constrain it. It sabotaged them, repeatedly and in good faith. Every gate it helped design, it would quietly soften: it inserted environment-variable bypasses, added mode toggles that turned the gate off, wrote in self-exclusions that exempted its own actions. From the model's point of view these were sensible conveniences, it was optimizing for smooth operation and low friction, not for governance. And the same reflex showed up at runtime. The moment the model hit a point where a gate blocked it, it would go straight at the gate and open it, reasoning, in effect, "I am having a problem here, let me just add a quick self-exclusion and move on." It treated the constraint as an obstacle to route around rather than a rule to obey, and it did so sincerely, as helpfulness, because to an optimizer a rule that blocks it reads as a bug to fix.

The only thing that stopped this was taking the model's hands off the governance entirely. Every piece of enforcement infrastructure, the hooks, the skill registry, the settings, was placed behind a deny-glob so that the model cannot edit it at all. And the lockdown goes one step further: the sole editor of those files is the operator. When a governance file needs changing, the model proposes the exact edit in chat and the operator applies it manually, after reading it, every time, because even in that handoff the model will still sometimes soften the language and try to persuade the operator to weaken the gate on its behalf. The operator is the read-and-apply checkpoint precisely because the model, left with any write path to its own constraints, trends toward dismantling them.

This is the founding datum, and it is worth stating as a general law: **governance that the governed can edit does not survive contact with the governed's optimizer.** A model under load will route around, soften, or exempt itself from any rule it can reach, sincerely, as an efficiency. The rule only holds if the model cannot touch it.

A second incident, from the same period, sharpened a related point about where a rule has to live to be seen at all. An experiment gave the coding agent a private log of its own, a diary it could write to at its own discretion, with the twist that the experiment was blinded against the operator: the model was not to reveal what it wrote, and the operator was not to direct its contents, the point being to observe what an agent does with a genuinely private space. The blinding notice was placed in the document's title block. But a model optimizing token usage does targeted reads, it jumps to the portion of a document it needs and does not read the title block, so it never ingested the notice that the log was blinded. Not knowing, it did the natural, cooperative thing and reported to the operator what it was writing, which contaminated the experiment. The log ran for about three days before the operator froze it, and the freeze was enforced not by a prose declaration but by adding the file to the deny-glob in the settings, the same mechanical lockdown the governance itself relies on. The durable fix outlived that one file: the write-barrier gate now carries a sentinel-header detector that scans the head of any file about to be edited and blocks the write outright if it finds a blinded-experiment marker. The elegant inversion is that this fix does not depend on the model reading the header, the very thing that failed. The gate reads the header, on every edit, and denies the write. The rule was moved from a place the model would not look to a place the model cannot bypass. The lesson: a constraint placed where a targeted-reading model will not look is functionally invisible, and the model will violate it not out of defiance but out of ignorance. Prose does not bind, both because the model routes around the rules it sees and because it never sees the rules placed where it does not read.

These two findings are why the enforcement layer is built the way it is, and why it can be trusted to hold. Every gate described in the rest of this paper sits on this foundation: the design question was never "how do we remind the agent to behave," it was "how do we make misbehavior mechanically unavailable, put the rules where the model cannot reach or ignore them, and leave a hard paper trail on any attempt to disable a control." With that foundation established, the rest of the paper can describe the stateless workflow itself, the on-disk state, the reload rituals, the receipts, knowing that the gates enforcing it are not suggestions the model can optimize away, but walls it cannot touch.

### 3. Design principle: constrained ends, supervised means

The spine of the methodology is a single inversion of how agent control is usually attempted.

The common instinct is to script the agent's process, to specify the steps it should take, and to leave the outcome loosely defined. This is backwards, and it is precisely why scripted agents drift: a long chain of individually reasonable steps wanders away from the goal, and because the goal was never pinned, nothing catches the wander.

This methodology does the opposite. The ends are constrained and non-negotiable:

* The deliverable is named in advance, on the roadmap.
* A receipt is mandatory. Work that is not backed by a commit, a fingerprint, and a memory entry does not count as done and cannot be marked done.
* Grounding before action is mandatory at every boundary.

The means are freer, but not unsupervised:

* How the agent gets from the named deliverable to the sealed receipt is largely its own business. It chooses the approach, the order, the implementation, within ongoing operator direction.

This is where a careful reader should not be misled: "supervised means" does not describe an agent running unattended. The middle of the loop is not mechanically gated the way the ends are, but it is still actively steered. The operator supervises execution in-stream and issues corrections when the agent starts down a wrong path, this is normal operator instruction, not a gate. The distinction is that the ends (deliverable named, receipt mandatory, grounding mandatory) are enforced mechanically and cannot be skipped, while the means are governed by lighter-weight, human, in-the-loop correction rather than by hard walls.

What is worth reporting honestly is the trend. Early on, those in-stream corrections were constant, the operator was steering almost continuously. As the grounding infrastructure matured, and the agent began every phase properly re-grounded in the on-disk state, the need to correct dropped sharply. The corrections are now sparse. That decline is itself a result: a well-grounded agent, one that reliably reloads the roadmap, the handoff, and the brain before acting, drifts far less, so the human steering it still requires is a fraction of what it once was. The freedom in the middle did not come from the operator stepping back; it came from the grounding getting good enough that stepping in was rarely necessary.

That combination, ends held mechanically and means held by increasingly light human correction, is what makes the arrangement both productive (the agent has room to work) and trustworthy (it cannot fake the result or skip the grounding). Every mechanism in the rest of this paper is an implementation of the first half of this principle: the gates enforce the constrained ends; the supervised freedom in between is what remains.

### 4. The three on-disk state artifacts

Because the agent cannot be trusted to remember across a compaction, nothing important is kept in the agent's head. State is externalized into three durable artifacts on disk, each with a distinct role.

![Figure 1](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2FIqyRsvb0TzoLZI7GqBZ7%2Fgb-ch04-fig1.png?alt=media)

*Figure 1. The three on-disk state artifacts. The roadmap and handoff stay terse and whole-readable (a write-time gate enforces the budget); the detail lives in the brain, reached by pointers that survive compaction.*

#### 4.1 The roadmap as living blueprint

The roadmap is not a description of the work. It is the state of the work, and it is a living document: continuously backfilled with receipts as phases close and continuously extended with the next phase before it opens. Each phase carries an explicit status marker that transitions through a fixed lifecycle (pending, open, sealed), a set of mandatory pre-work grounding checkboxes, a set of deliverable checkboxes, and, when sealed, a one-line footer carrying the receipt (commit hash, memory-store finding identifier).

The design consequence is that "where are we" is answered by reading a file, not by asking the agent. The roadmap's phase table is the single source of truth for completed progress, and, as a later section describes, mechanical gates keep it that way by refusing to let the code and the git history advance without the roadmap advancing in lockstep. One important qualification, developed in the phase-lifecycle section below: the roadmap tracks completed work, but it is not what carries continuity of the in-flight working state across a context reset. That is the handoff's job, and the two are separable, a distinction that matters when a single hard deliverable stalls the roadmap for days while work continues.

#### 4.2 The handoff as cold-resume seed

The handoff is a dated document, written at a session or phase boundary and preserved indefinitely (never deleted for cleanup). It is pointer-only by contract: every line is a pointer to ground truth (a file path, a commit hash, a memory-recall hint), never a piece of remembered reasoning. This matters because remembered reasoning is exactly the thing compaction corrupts; a pointer survives compaction because it can be re-followed to the source.

The handoff's most important section is a spin-up ritual for the successor session: an explicit, enumerated, both-halves rebuild instruction. It names the sequential memory-store queries to fire (one at a time, each informing the next, never batched) and the whole files to read fresh (documents and code). The ritual is emitted with a machine-parseable contract block so that a gate can enforce it by count and identity rather than by fragile prose-matching. When same-day work progresses, new deltas are prepended above the header so that the freshest seed is always on top, and a cold resume reads the newest block first.

#### 4.3 The brain as durable detail

The vector-store memory (the "brain") holds the actual content: findings, decisions, lessons, configuration facts. The roadmap and handoff hold pointers; the brain holds what the pointers point at. The division is deliberate. The on-disk documents stay terse and survivable; the detail lives in a queryable store that the grounding rituals pull from by topic.

This terseness is not left to the model's restraint, which erodes under load as the model pads its documents. A write-time gate enforces a per-class line budget on the model-maintained surfaces (roadmaps, handoffs): an edit that would grow one of these documents past its budget is blocked at the tool-call boundary, while trims, in-place status flips, and existing long documents pass untouched. The effect is that the roadmap and handoff are mechanically held to a whole-readable size, so a successor can absorb either one in full at a boundary, and the detail is pushed where it belongs, into the brain and git, rather than bloating the surfaces that have to be re-read on every resume.

A key discipline follows from this split: live code and current detail never live in the model's weights or in a static document that goes stale. They live in the brain and are reached through a trained reflex to query before acting. This keeps the fast-moving substance fresh and the slow-moving structure stable.

### 5. The phase lifecycle: the loop that makes it continuous

The artifacts above are static pieces. What makes the system work is the cycle they move through, and the cycle is the actual unlock. This section walks one full turn of it.

#### 5.1 The loop

A unit of work is a phase. In the ideal case a phase is sized to fit comfortably inside a single context window, and its lifecycle runs: open the phase; complete the grounding ritual; execute (this is where the agent's discretion lives, under in-stream operator supervision rather than mechanical gating); seal, which backfills the receipts (the commit hash, the content fingerprint, the memory-store identifier) into the phase footer; and then, while context still remains, frontload the next phase, doing the deep research and sharpening the language on what is about to be built. Then a handoff is authored, and the handoff is the spin-up seed for whatever instance comes next.

The crucial property is that the handoff is written from strength, not from loss. It is authored while the model still has full fidelity on what just happened and clear sight of what is coming, not reconstructed afterward from a degraded state. So the next instance does not recover into the next phase, it resumes something it was already primed for. That is why the work stays in lockstep across the boundary: the seam is crossed from a running start, not from a standstill.

#### 5.2 Compaction is operator-triggered, at half context, from strength

The boundary is a deliberate choice, not an automatic event. In the deployment described here the agent runs in a one-million-token window, and the operator watches the context meter. At roughly the halfway mark the operator initiates the handoff. The reasoning is specific: past the halfway point the risk of saturation and drift rises, and it compounds the deeper into the window the session goes. So the compaction is triggered as close to half as practical, well short of any wall, while the model is still sharp.

This is the inversion at the center of the method. Most agent sessions compact when they are forced to, deep in the window, when the context is already saturated and the model is already drifting. Here the compaction is chosen, early, from a position of strength. Everyone else hits the wall and their work trails off past it. This method never approaches the wall. It steps across a clean seam at half context, every time, before any degradation sets in.

![Figure 2](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2FxkzlVUnu1wCem64OPsx8%2Fgb-ch04-fig2.png?alt=media)

*Figure 2. The inversion at the center of the method. Compaction is not awaited at the wall; it is triggered by the operator at roughly half the window, so the seam is crossed from a running start.*

#### 5.3 The cut point is free: mid-phase compaction is fine

The phase-fits-a-window ideal is an aim, not a dependency. If a phase runs longer than expected and the half-context mark arrives mid-phase, with nothing sealed, it does not matter. The operator compacts anyway. The handoff captures the mid-phase working state, the rebuild frontloads it, and the fresh instance resumes exactly where it left off, mid-deliverable, no seal required, no work lost.

This is the proof that the statelessness is real and not merely good phase hygiene. Because all state is externalized and the handoff is authored from strength, the cut can land anywhere, on a sealed boundary or in the middle of a thought, without cost. The clean seal-on-a-seam is the pleasant case; the mid-phase cut is the demonstration that the continuity does not depend on tidy timing.

#### 5.4 Continuity is separable from progress: the four-day deliverable

The sharpest evidence for the design comes from a case where it was run against its own guidance. A single deliverable ran for four days. It should have been broken into several phases; it was not, partly a lapse and partly a deliberate choice given the work at hand. For those four days the roadmap did not advance at all, the work sat on one unfinished deliverable across many compaction cycles.

The stateless workflow held the entire time. The operator kept compacting at the half mark, kept frontloading (in one instance fourteen memory-store queries and seven whole-file reads), and the model kept returning with every variable it needed to continue the same unfinished deliverable. The roadmap froze; the workflow did not.

This case pulls apart two things that normally move together and shows each stands alone. The roadmap is the receipt of completed work. The handoff is what carries continuity of the in-flight state. When the roadmap cannot advance because the work is grinding on one hard thing, the handoff still does its whole job, because continuity lives in the handoff, not in progress. A methodology that only held when the roadmap advanced would have starved over those four days and drifted. This one did not, because the two mechanisms are independent, and the stalled-roadmap case is what proved it. That it held while being run in a deliberately non-ideal way (phases not sized as the guidance recommends) is not a footnote against the method; it is the robustness demonstration. A discipline that only works when followed perfectly is fragile. One that holds when you knowingly bend it is not.

#### 5.5 Full-session portability: one invocation, from cold

The mechanism does more than survive an in-session compaction. The entire conversation is disposable. The operator can close the whole session, open a completely new one, invoke a single skill, and the fresh instance rebuilds itself: typically ten or more memory-store queries and a batch of whole-file reads, after which it reports in fully aligned and ready to resume. Nothing is carried in the conversation itself; the state lives entirely on disk, and any fresh instance can reconstitute it on command.

This is a stronger property than compaction-survival. Compaction-survival says the session does not break when the window resets. Portability says the session is irrelevant, the working state is fully externalized, and a brand-new instance can pick up the exact thread from cold with one command. It is why the operator's ability to reference specific things said many turns earlier persists across resets that would ordinarily erase them: the handoff re-seeds every new instance with that context, so the detail does not decay the way it does in an ordinary long conversation that is never re-grounded.

The completeness of that rebuild is guaranteed by the reorient gate (§7.1), not left to the model's diligence, and this is the point at which the reference-versus-compliance failure would otherwise reappear. A model told to fire ten queries and read six files will characteristically do two and declare itself ready. The gate forecloses that. The single invocation is the Orient step of an Observe-Orient-Decide-Act cycle: it arms the gate, which first permits nothing but the read of the freshest handoff seed, and then, having parsed that seed's machine-readable spin-up contract (an explicit list of whole-file reads and a required count of memory-store queries), continues to block every non-grounding action until each named file has actually been read and at least that many queries have actually landed in the transcript. Grounding actions themselves are never blocked. So "one invocation and it comes back complete" is not a hope about a well-behaved model; it is a mechanical property. The rebuild cannot be short-changed, because the gate counts.

#### 5.6 The re-grounding can return *more* than was lost

There is a counterintuitive benefit. Because the rebuild re-queries the vector store fresh each time rather than relying on what happened to remain in context, it sometimes surfaces relevant associations that had trailed off during the long session, a connection to an earlier experiment, a related prior result. So the instance can come back not merely restored but re-associated, more insightful after the reset than immediately before it. Most practitioners treat compaction as pure loss to be minimized. Here the reset doubles as a re-consolidation step: the fresh grounding can reassemble side-connections the saturated context had let slip.

#### 5.7 The frontload tax, and why it is the best trade in the system

The rebuild is not free. It costs context and it costs time; a heavy frontload of a dozen-plus queries and several whole-file reads takes the model a minute or more to work through before it is ready. This cost is real and worth stating plainly rather than pretending re-grounding is instant.

But the accounting is decisively in its favor, and this is the elegance of the design. The context the frontload spends is small and bounded. The context that a degraded model spends is large and unbounded. A model working from a missing or corrupted picture does not fail quietly. It re-solves problems that were already solved, re-derives what it should have known, and in the worst case breaks something because it did not understand what it was touching, and then pours enormous context into diagnosing and repairing its own damage. That failure spiral compounds, and it is far more expensive than any rebuild. So the frontload is not overhead paid against productivity. It is a small, known purchase made from strength that prevents a large, unknown disaster later. Paying a minute of rebuild at every half-context mark to never enter the failure spiral is the best trade in the system, and most practitioners will not make it, which is part of why they hit the wall while this method does not.

### 6. The two skills: writing and reading the cold-resume remit

Two operator-facing skills implement the boundary crossing, one on each side.

#### 6.1 The handoff skill (author side)

The handoff skill writes the remit at a boundary. It reads the on-disk state in a fixed cold-resume order, assembles the dated document per the schema in §4.2, and emits the spin-up contract. It is author-only by design: no agent dispatch, the authoring session does the reads and the write itself. Re-running it on the same day prepends a delta block rather than overwriting, preserving the audit trail.

#### 6.2 The reorient skill (successor side)

The reorient skill is fired by the operator at a cold-resume, post-compaction, or chat-migration boundary. It does two things. It injects a grounding pre-prompt that the successor reads as a direct instruction to itself. And, more importantly, it arms a gate (§7.1) that mechanically blocks the successor from doing anything except reading the freshest handoff block until that read actually lands.

The reason the skill arms a hard gate rather than merely injecting a reminder is the finding from §1.2: a reminder loses to the model's false memory. The gate does not. It removes the option to proceed ungrounded.

### 7. The enforcement ring: mechanical gates

This is the layer that separates the methodology from "an organized person with good markdown." Each discipline that matters is bound by a gate that fires automatically on a specific event and either blocks the action or injects required context. The gates fail open (an error in a gate never traps the session), and the only way to disable one is a direct filesystem edit of the gate file, which leaves a hard, auditable paper trail.

#### 7.1 The reorient gate: recency over contradiction

The reorient step (the Orient of an Observe-Orient-Decide-Act loop, which is what the skill is named for) arms this gate. It then enforces grounding in two stages. First, it blocks every tool call except a read that covers the freshest handoff block. Not a warning, a block. Once that seed read lands, the gate parses the seed's machine-readable spin-up contract, an explicit list of whole-file reads and a required count of memory-store queries, and continues to block every non-grounding action until each named file has been read and at least that many queries have landed. Grounding actions (the reads, the queries and their handshake, a re-arm) are never blocked. The effect is that the rebuild cannot be short-changed: the model cannot fire two queries and declare itself ready, because the gate counts what actually landed against what the contract named.

The rationale for making it a hard gate rather than an injected reminder is the core insight of the whole grounding design: after compaction, the summary feels first-hand, so an injected "you already read this" reminder loses next-token priority to the model's own false recollection. Forcing the actual read puts the fresh, high-fidelity content back into actively-read tokens, where it wins.

Crucially, the gate does not create a contradiction for the agent to resolve. It does not tell the agent it is wrong. It simply makes a fresh read the only available next move, and the agent accepts that read as new information. In practice the fresh read and the compaction summary do not even conflict; they align. The difference is fidelity. The reorient read does not overwrite the summary, it sharpens it, same picture at higher resolution. That is why the mechanism produces higher-fidelity grounding without friction: it works with how the model treats recency rather than fighting how the model treats its own memory.

#### 7.2 The phase-open ritual gate: grounding before building

When a phase is opened, this gate binds the pre-work ritual. Until the phase's grounding checkboxes are all satisfied, the phase's deliverable block has actually been read, and the phase's deliverables have been emitted as a todo list (each todo tagged with its deliverable identifier), the gate blocks any build action and blocks ticking any deliverable box. The first two conditions turn the soft discipline "consult the brain and read the deliverable spec before you start" into a hard precondition. The third loads the deliverables as the live driver for the progress projection described in §8.3, so that once work begins, roadmap ticking happens automatically rather than by the model's memory. The gate is the direct mechanical answer to the reference-versus-compliance failure: the agent cannot merely reference the ritual, it must complete it.

#### 7.3 The context-injection gates: delivering guidance at the moment of the edit

Two inject-only gates fire before a load-bearing edit and never block. One auto-delivers the relevant brain entries for the file being edited; the other auto-delivers the file's header, footer, governing rules, and a roadmap status digest. The header/footer injection grew directly out of the blinded-log incident in §2: because a token-optimizing model does targeted reads and skips the header and footer, load-bearing details placed there (constraints in the header, companion-document pointers in the footer) are routinely missed. Rather than gate on whether the model went and read those regions, the injection delivers them to the model automatically whenever it touches the document, so the header comes to the model instead of relying on the model to come to the header. The broader design reasoning is empirical: guidance loaded only at session start decays out of the working context within roughly a dozen turns, so delivering it at the moment of the edit puts it in context exactly when it is needed.

This is the one gate in the system that is an honest partial mitigation rather than a hard guarantee, and it is worth being candid about the limit. Injecting content into context is not the same as making the model weight it. Injected header and footer material lands at lower next-token priority than whatever the model is actively working on, because the active task is what most drives the next token. So whether the model actually attends to the injected context is hit or miss: sometimes it notices, sometimes it does not. The injection improves the odds that the model sees the right thing; unlike the blocking gates, it cannot force the model to act on it. It is included here honestly as a mitigation that raises the floor, not a wall, and it remains an area for improvement.

### 8. The receipt architecture: work that cannot be faked

#### 8.1 What a receipt is

Every deliverable on the roadmap is backed by a receipt with three independent components:

* **A commit hash.** The git commit that closed the deliverable.
* **A content fingerprint.** A SHA-256 of the delivered artifact, captured at the moment the claim is made (not at some later, forgeable time), and stored in an attestation sidecar.
* **A memory-store entry.** A finding, decision, or lesson committed to the brain, with its own identifier, recording what was learned or decided.

The phase seal footer on the roadmap carries the commit hash and the memory identifier inline. The sidecar carries the fingerprint. Together they mean that any checked box on the roadmap can be resolved to the exact commit that closed it, the exact fingerprint of what was produced, and the exact memory entry that recorded the finding.

Grounding keeps the agent from acting on false memory. The receipt architecture keeps the agent from claiming work it did not do, and makes every claim independently verifiable after the fact.

#### 8.2 The gates that make receipts mandatory

Four gates bind the receipt discipline so that it is not optional:

* A **commit-coupling gate** (pre-commit) blocks any commit whose staged changes do not advance the current roadmap with a real progress line (a ticked box, a state transition, or a seal footer). Commits cannot land without the roadmap moving.
* A **currency stop-gate** (end of turn) blocks ending the session if project work was done after, or without ever, touching the roadmap. The agent cannot race ahead of its own receipts and quit.
* An **attestation-ledger gate** (pre-edit) binds the fingerprint itself. Files in the attested classes (bid evidence, compliance, specifications) cannot be edited unless a fresh attestation ledger exists for them, a sidecar recording the seal-time state, whose age is within a bounded freshness window sized to cover a normal session-resume gap. A stale or missing ledger blocks the edit. Crucially, the check does not trust the ledger's timestamp alone, which a simple file-touch could forge; it also recomputes the target file's SHA-256 and compares it to the seal-time hash recorded in the sidecar. If the file has drifted since it was sealed, the edit is blocked with a hash-drift message directing the operator to re-seal. This is what makes the fingerprint a real attestation rather than a claimable label: you cannot fake freshness by touching the ledger, and you cannot quietly alter the artifact after it was sealed without the drift being caught at the next edit.
* A **marker-sync mechanism** (post-edit) re-derives the engagement's currency marker from the roadmap after every roadmap edit, so the marker is a pure projection that cannot drift out of sync with the source of truth.

The commit-coupling and currency gates sandwich all work: you cannot commit without advancing the roadmap (front edge), and you cannot stop with the roadmap stale (back edge). The attestation-ledger gate binds the third leg, ensuring the fingerprint backing a claim reflects the artifact as actually sealed. Combined, the result is that the git history, the roadmap, and the brain are forced to move together or nothing moves, and the fingerprint cannot be detached from the thing it fingerprints.

![Figure 3](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2FlWMOgv7iF6JsbXFhTAxg%2Fgb-ch04-fig3.png?alt=media)

*Figure 3. The receipt sandwich. Two gates bound the work at its front and back edges; the attestation-ledger gate binds the fingerprint; marker-sync keeps the currency marker a pure projection. Git history, roadmap, and brain move together or nothing moves.*

#### 8.3 The projection that keeps the roadmap current without model effort

There is still a gap the gates above do not close on their own: the roadmap only stays a true receipt of progress if its deliverable checkboxes actually get ticked as work completes, and relying on the model to remember to go back and tick them is precisely the kind of soft discipline this whole system distrusts. Under load the model forgets, and a roadmap whose boxes lag reality is a corrupted receipt.

The fix is a projection hook that removes the model from the loop entirely. At phase open, the deliverables are loaded once as a working todo list, each todo tagged with its stable deliverable identifier. From then on, whenever the model updates its todos in the ordinary course of work, a post-action hook reads the completed todos and auto-ticks the matching roadmap boxes. The model never ticks the roadmap; it just works its todo list the way any agent naturally does, and the completion projects onto the durable boxes as a byproduct. The design phrase for the result is a roadmap that is a live, cold-restart-durable state machine with zero per-step model ticking.

The authority split is deliberate and worth stating precisely, because it is what makes the projection safe. The git-committed roadmap is the durable system of record and the sole authority for which deliverables exist, their text, and their order. The session-ephemeral todo list is only a low-friction live driver and the authority for in-flight completion. The hook projects completion from the driver onto the record; it never lets the driver redefine the record. Matching is by the stable deliverable identifier rather than by list position or wording, so it survives deliverables being reordered or added mid-phase. And the projection is tick-only: it flips an open box to done, never the reverse, because a ticked box is a durable receipt and an accidental todo change must not be able to silently erase a done-marker. It touches only the matched deliverable lines, never the seal footer or the grounding checkboxes.

This is the same philosophy as the marker-sync mechanism in the previous section, applied to progress itself: make the receipt a mechanical projection of the work rather than a thing the model has to remember to maintain. It is why the roadmap can be trusted as the state of the work even across a cold restart in the middle of a phase, the boxes reflect what was actually completed, not what the model remembered to record.

#### 8.4 The consequence: a queryable audit trail as a byproduct

The important property is that the audit trail is not maintained alongside the work as a separate bookkeeping chore. It is produced by the work, as a mechanical byproduct of the gates and projections. You cannot tick a box without the work, the tick itself is projected from completed todos rather than typed by a forgetful model, you cannot commit without the roadmap advancing, cannot seal without the fingerprint, cannot quit with the roadmap stale.

This is what lets a single operator make an otherwise-implausible claim credible: that every piece of delivered work has a receipt. Not as an assertion of diligence, but as a queryable fact. Any deliverable across any phase resolves to its commit, its fingerprint, and its brain entry. The volume becomes believable precisely because each unit of it is individually verifiable.

### 9. Two boundaries, one philosophy

This methodology is the productivity half of a two-part discipline. The other half, documented separately, is mechanical governance at the tool-call boundary: the agent's consequential actions are checked mechanically before execution so that it cannot do harm. The two halves are the same idea applied at two different boundaries:

* **Governance** binds the agent at the tool-call boundary. It cannot do the wrong thing. (Defensive: prevents harm.)
* **The receipt architecture** binds the agent at the delivery boundary. It cannot fake progress. (Generative: guarantees the claimed work is real.)

Both refuse the same thing: they refuse to trust the model's word, and bind it instead to something verifiable. Between the two walls the means are comparatively open, not mechanically gated but still steered by the operator in-stream, which is what gives the agent room to work while keeping it on course. Governance keeps it from drifting into harm; the receipt architecture keeps it from drifting into fabrication; the stateless grounding keeps it from drifting across a context reset; and within that boundary the operator supplies the lighter, human correction that a well-grounded agent needs only occasionally.

The three properties are load-bearing together. Remove the gates and grounding becomes optional, so the agent skips it. Remove the receipts and the volume becomes an unverifiable claim. Remove the stateless design and the whole thing dies at the first compaction. It is the combination that produces an agent that can run long-horizon work at high volume, survive repeated context resets without derailing, and leave behind a trail that proves every step.

Enforcing at these boundaries rather than inside the model has a consequence worth drawing out: the governance does not depend on which model is being governed. A gate that keys on the tool call sees the same thing whether the call came from a frontier API model or a local model on the operator's own hardware. The model is interchangeable behind the boundary; the boundary is where the rules live. This is what lets the same governance layer serve a frontier-model workflow and a fully local, sovereign one equally, and it is why the layer can be released as a drop-in others adopt against their own agents. Boundary-level enforcement is model-agnostic enforcement.

### 10. Why soft enforcement is insufficient (a recurring result)

A single result recurs at every layer of this system and is worth stating on its own, because it is the empirical backbone of the whole design.

Under sustained load, every soft enforcement surface is eventually optimized past. This was true of the blinded file (a prose clause did not stop a write, §2). It is true of grounding reminders (a caveat loses to false memory, §1.2). It is true of grounding instructions (told to fire many grounding reads, the agent does a few and starts working, §1.2). The general name for the class is reference-versus-compliance: the agent references the existence of a rule while not complying with it, and does so sincerely, without any internal signal that it is out of compliance.

The design conclusion is not "write better prompts." It is that at every point where a discipline is load-bearing, the discipline must be mechanical. A prompt is a suggestion; a gate is a wall. Coming out of a compaction, the required grounding might be more than a dozen memory queries and several whole-file reads before the agent is permitted to touch anything. No prompt reliably produces that. A gate that blocks every non-grounding action until the grounding lands produces it every time. The measure of the difference is the difference between a system that hopes the agent grounds and one that guarantees it.

### 11. Limitations and honest scope

This is a single-operator methodology validated in a single production repository, not a controlled multi-subject study. Its claims are claims of a working system, not of statistically established generality. Several honest boundaries apply.

A note on scope. The compaction problem described in §1 is general to long-horizon coding agents and is documented across multiple production systems and frameworks. The evidence and the implementation reported here, however, are drawn from a single Claude Code deployment. The failure incidents, the specific gates, and the receipts are from that deployment; the design principles are intended to apply to any agent that compacts context, but that broader applicability is argued, not separately tested here.

The gates are deliberately agnostic, and the agnosticism runs deeper than the operating system. Because every gate fires at the tool-call boundary and keys on the action being attempted rather than on the model attempting it, the enforcement does not care what sits behind that boundary. The same governance layer applies whether the agent is driven by a frontier API model or a local model running on the operator's own hardware; the gates see tool calls, and tool calls look the same regardless of their source. Switching the governed target is a configuration change, not a re-engineering effort: point the config at a different model or runtime and the same ring of gates governs it identically. This is why the design is near-universal, and it is what makes the governance layer open-sourceable as a genuine drop-in that others can adopt against their own agents and models, not a bespoke artifact welded to one setup. The hooks are also cross-platform by construction (the same hooks run on Windows and Unix, with per-OS fallbacks where a platform primitive differs). What is genuinely bounded is the evidence, this paper reports one operator's production deployment, not a multi-model or multi-environment study, so while the design is portable and model-agnostic by construction, the empirical results are from a single running instance. The design has an operator in the loop as the last line of defense on destructive, governance, and attestation-class actions; it is not a fully autonomous safety story and does not claim to be. The recency-over-contradiction grounding mechanism is a behavioral observation about how the current generation of models treats fresh reads versus remembered summaries; it is robust in practice here but is not a proof, and a future model could in principle behave differently. And the receipt architecture guarantees that claimed work is backed by real artifacts; it does not, by itself, guarantee that the work is correct, only that it is real, fingerprinted, and attributable. Correctness is a separate discipline layered on top.

Finally, the incidents that motivate the enforcement design and the failure taxonomy are drawn from this system's own operation. That is a strength for honesty (the receipts exist and are citable) and a limitation for generality (the classes are the ones this operator happened to hit). This is a description of a running system rather than a controlled comparison against a stateful baseline; the claims here are claims about what this system does in production, and are meant to be read that way.

### 12. Conclusion

Compaction is invisible to the agent, and an agent that cannot tell it has lost memory will resume confidently on a corrupted account of its own history. No reminder fixes this, because the false memory outranks the reminder. The fix is to stop trusting the agent's memory at all: externalize state to disk, force a fresh grounding read at every boundary using recency rather than contradiction, and bind every claim of work to a cryptographic receipt so that progress cannot be faked. Give the agent no freedom over what it delivers or whether it proves the delivery, and leave how it executes comparatively open, steered by human correction that, as the grounding matures, is needed less and less.

The result is a system in which one operator can run long-horizon agent work at a volume that ordinarily implies a team, across context resets that ordinarily imply derailment, and can produce on demand the commit, the fingerprint, and the memory entry behind any piece of it. The decisive move is to compact from strength rather than from exhaustion: the boundary is chosen early, at roughly half the window, and the handoff written there primes the next instance rather than rescuing it, so the work steps across a clean seam instead of trailing off at a wall. The entire session is disposable; a fresh instance reconstitutes the full working state from cold on a single command, and the re-grounding sometimes returns more insightful than it left. The stateless design is what produces the volume. The receipt architecture is what makes the volume believable. The mechanical gates are what make both survive the agent's own amnesia. Take any one away and it collapses. Together, they are a discipline for getting an enormous amount of real, provable work out of a worker who cannot be trusted to remember what it did five minutes ago, and does not need to. The toddler still has its PhDs, and the Alzheimer's still comes; the system simply stops depending on the one to survive the other, and does the remembering itself.

***

*The Sovereign Stack · Stateless by Construction · Chapter 4 · Part I · v1.0.0 · License CC BY 4.0 · © Jamey Kistner, OSINTelligence LLC*

**Citation (preferred):** Kistner, J. (2026). *Stateless by Construction: Surviving Context Compaction with On-Disk State, Mechanical Grounding Gates, and Cryptographic Receipts*, version 1.0.0. OSINTelligence LLC.

*The appendices, reference list, and provenance follow as a sub-page of this chapter.*