Scout

Entry 30 · Coined 11 Apr 2026 · briefed 19 Sep 2026

Already 5 months old when the scout caught it.

Harness-managed virtual memory

What it is

Harness-managed virtual memory is a pattern for agent context management that borrows the operating-system metaphor directly: the context window is RAM, a durable external store is disk, and the agent harness is the kernel that pages state between them. The reference system, ClawVM (from a paper out of MPI's dsg group), represents agent state as typed "pages" that can be kept at full fidelity, compressed, reduced to structured fields, or shrunk to a pointer as token budget tightens. Each page carries a minimum-fidelity invariant — how far it's allowed to degrade before its space gets reclaimed — and the harness enforces that invariant with staged, validated writeback at every lifecycle boundary: compaction, reset, and tool calls.

Why it's emerging now

Long-running, stateful tool-using agents increasingly hit a specific class of failure: state lost after compaction, flushes bypassed on reset, writeback that silently destroys data the agent still needed. Today's harnesses mostly manage memory residency as best-effort rather than as a governed contract, so these failures show up as "the agent forgot everything" bug reports rather than a named, addressable problem. As agents are pushed to run for many hours across sessions, that gap has become expensive enough that researchers are reaching for decades-old OS virtual-memory theory — paging, fidelity levels, invariants — and formalizing it as a harness-level responsibility instead of leaving it to ad hoc summarization.

How it relates to what you know

This is a more systems-flavored, formalized treatment of the same territory as "Agent memory (persistent memory, memory files)" already on your ledger — where that entry covers memory as a feature, this names the contract that governs how state degrades under pressure. It also sits naturally next to "Harness engineering (Agent = Model + Harness)": the harness, not the model or an external memory service, is treated as the natural enforcement point because it already assembles prompts and mediates tool calls and lifecycle events. And it gives "Governance decay" (context-compaction erosion of in-context constraints) a concrete counter-mechanism — an explicit, auditable invariant on what compaction is and isn't allowed to erase, rather than compaction being an unaccountable black box.

Go deeper

All entries