Externalize the Working Set

Explain this chapter with AI

Copy this prompt into ChatGPT, Claude, Gemini, a local model, or another AI.

Apply this chapter with AI

Copy this prompt into ChatGPT, Claude, Gemini, a local model, or another AI.

Chapter 12 ended with an irreducible remainder: pinned exact spans, active dense episodes, compact views of the recent past, anchors of the deep past. Still resident, still costing capacity and cache stability. Consider what that remainder looks like in a concrete session. An agent halfway through a dependency migration holds five working objects: an architecture investigation at roughly 18,000 tokens, a benchmark report at 12,000, a compiler trace at 25,000, a design-alternatives note at 15,000, and a vendored API reference at 30,000. Progressive fidelity has done its honest work and the resident views are compact. The sum is still near 100,000 tokens of occupancy, and on most turns the model consults at most one of the five. The tiers answered how little of each object must be shown. None of them asked whether the object needs to be shown at all.

Progressive fidelity still consumes window space. The next move is to take information out of the window entirely.

That sentence closed the previous chapter. This chapter earns it.

Availability is not residency

Until now the book has managed context largely as though useful information must occupy some representation inside the window. That assumption was productive: Chapters 10 through 12 built the full repertoire of in-window management, deletion, compaction, and tiered fading. But it is still an assumption, and this chapter breaks it:

available to system
        โ‰ 
resident in context

Information can remain available to the surrounding system, on disk, in an artifact store, in a note file, in a database, without being represented in the current model invocation at all. Only when some representation is supplied to the model does it become context for that computation. Chapter 1 drew the vocabulary lines between available information, session state, current context, and window capacity. Externalisation is what makes those lines operational rather than definitional.

The working-set analogy from operating systems earns its place here if kept precise. A running process has far more mapped memory than fits in physical RAM; the resident working set is the subset physically present, and the rest waits on disk. A model invocation is analogous in one respect only:

                AVAILABLE INFORMATION
                       โ”‚
             โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
             โ”‚                   โ”‚
        RESIDENT             EXTERNAL
             โ”‚                   โ”‚
     current ContextBundle   artifacts / files
             โ”‚                   โ”‚
             โ””โ”€โ”€โ”€โ”€ reference โ”€โ”€โ”€โ”€โ”˜

The analogy stops where hardware help stops. There is no page fault that transparently restores an evicted episode when the model reaches for it. If the live context carries only a reference, the surrounding system must decide, by explicit mechanism, what returns and when. Chapter 14 owns that decision. This chapter owns departure: how information leaves the live context while remaining recoverable, and what leaving costs.

Retention is not fidelity is not residency

Chapter 12 split retention from fidelity: the retention class states which transformations are legal, the fidelity level states which legal representation is active. Externalisation adds the third variable:

RETENTION CLASS
What transformations are legal?

FIDELITY LEVEL
Which legal representation is active?

RESIDENCY
Is the information represented in
the current invocation at all?

An architecture investigation illustrates all three at once. Its retention class may require that the full report remain available. Its fidelity range may span a dense brief down to an eighty-token anchor. Its residency may currently be zero: no representation of the investigation in this invocation beyond a stable identifier. A tiny reference remains resident while the information itself does not, and the three variables move independently. Pressure demotes fidelity; a departure decision changes residency; neither rewrites the retention contract.

The states the book has now earned compare as follows. Every row is a distinct policy position, and the table exists so later chapters can name positions without renegotiating them.

State Resident payload? Resident semantics? Full source available? Recovery obligation?
Full resident yes yes in context n/a
Compact / anchor resident (Ch12) reduced yes, minimal only if source retained no
Externalised with anchor (Ch13) identifier plus anchor partial yes, external yes
Externalised with pointer only (Ch13) identifier only no yes, external yes
Pruned (Ch10) no no not guaranteed no

The middle two rows are this chapter. The last row is the firewall with Chapter 10, stated exactly: pruning means future recovery is not required by the policy; externalisation means future recovery remains part of the contract. A pruned item may coincidentally still exist somewhere. An externalised item is intentionally preserved outside the live context because future recovery is expected. The same physical file can serve either policy. The difference is the contract, and the experiment records which contract each condition ran under.

An anchor is not a pointer

Chapter 12 defined an anchor as the minimum resident representation preserving identity, outcome, invariant, and source. Chapter 13 sharpens what an anchor is not: a pointer. A semantic anchor carries useful meaning itself:

Incident 17: deadlock caused by lock-order inversion;
fixed in commit abc123.

The model can reason from that without any retrieval. A reference identifies information elsewhere:

artifact://incident-17

The model cannot recover a single detail from the pointer alone. Most production references combine both:

Incident 17 โ€” lock-order inversion.
Evidence: artifact://incident-17

The combination matters because each half fails differently. An anchor can mislead through lossy compression of the source; a pointer can fail by not resolving at all. Keeping the two visibly separate lets the experiment score semantic sufficiency and recovery integrity independently instead of collapsing both into one behavioural number. It also imposes an epistemic requirement the chapter enforces throughout: a reference must never invite the model to act as though it has read the artifact. Resident text should distinguish known resident facts from details available externally but not currently loaded, or the system has built a confident ignorance machine.

What externalisation is

Context externalisation moves information out of the current model-visible working set while preserving a durable identity and a path by which the surrounding system can make it available again.

Four properties carry the weight: the payload is not currently resident; it is durably represented elsewhere; it has a stable identity; it is recoverable with provenance intact. Externalisation is not deletion with optimism. It is departure with a return address.

Once the payload leaves, vague prose such as “see the earlier investigation” is insufficient. A durable external object needs an identity: an artifact identifier, a file path, a URI-like handle, a content-addressed hash, a database key, a note path. The book does not crown one canonical form. It derives the properties the identity needs: stable enough to reference later, unique within the relevant scope, independent of current wording, and safe to expose in context. Identity is not location. An identifier such as artifact:investigation-017 may currently resolve to a stored file, and the storage may move without the identity breaking. The principle is enough; no object store is designed here.

Provenance must survive the move. An external artifact should be able to answer where it came from, when it was created, which context items produced it, whether it is raw or transformed, and which model or tool created it. The provenance discipline of Chapters 11 and 12 transfers unchanged. Externalisation without provenance preserves text while destroying trust: a recovered log the model cannot attribute is a rumour with a file handle.

Honesty extends to representation type. An external object may be the raw original, a generated report, structured state, or a compacted representation, and these are not equivalent. The reference must not imply that the full source is available when only a summary exists. Chapter 12’s fidelity distinction is reused, not reinvented: the artifact record carries its representation type, and the resident reference carries no more promise than the artifact keeps.

Recoverability, finally, must be tested rather than assumed. Chapter 7 classified some information as externalisable and refetchable. This chapter makes those labels operational. A reference is useful only if it resolves, the object still exists, the scope permits access, the object is readable, and the correct version is identifiable. The durable principle reads:

A pointer is not recoverability. It is a claim about recoverability.

The experiment treats every reference as a claim and checks it.

The cost of writing information out

Moving information out of context is not free, and the chapter refuses the naive ledger in which a smaller live context automatically means a cheaper system. The write side bills artifact creation, serialisation, storage, metadata, the resident reference tokens that replace the payload, future read latency, future read tokens, and management complexity. The honest per-decision accounting is tokens removed from residency minus reference tokens introduced, with artifact-write cost recorded alongside. A reference bloated with identifier, title, summary, tags, scope, version, and provenance can consume much of what departure saved. Metadata inflates; the experiment weighs every reference.

The read side decides whether the savings survive. An externalised artifact saves repeated residency only if it is not constantly reloaded. A 100,000-token artifact resident every turn is expensive occupancy; the same artifact externalised but re-read every turn is the same expense with extra steps. Externalisation’s value therefore depends on reuse frequency, residency frequency, and recovery frequency, and Chapter 14 will eventually optimise re-entry on exactly these variables. This chapter establishes the accounting without spending it.

Cache economics transfer from Chapter 9 without reopening that chapter. Removing a historical span rewrites the prompt prefix at the transition: a one-time mutation with a divergence position and a radius, possibly deferred to a task boundary, a cache-safe boundary, or a pressure threshold. Afterwards, later bundles are substantially smaller. The ledger records one-time rewrite cost against subsequent residency savings, using the inherited machinery. Eligibility is still not timing: an item can be a correct externalisation candidate while now is the wrong moment to move it.

Externalisation also buys something beyond tokens. A large log compressed into prose loses exact lines; if the full log survives as an external artifact, the resident context can carry a short semantic anchor while the exact source stays recoverable. Reasoning representation separates from evidence representation. The claim stays bounded: the model still needs the evidence reintroduced before it can reason over exact details. But the system no longer has to destroy the source merely to save window space, which is the precise failure that one-shot compaction kept producing.

When a reference breaks

Four failure modes are defined here because each demands a different fix, and the experiment scores them separately from reasoning quality.

Orphaned references. The context promises artifact://investigation-17 and the artifact is missing, moved, permission-changed, or the store is unreachable. This is an externalisation integrity failure, never a retrieval-ranking failure, and it is measured as reference resolution failure.

Aliasing. Two different objects acquire one ambiguous identity. A note at notes/database-investigation.md is overwritten by a later, different investigation under the same path. Stable identity plus version or revision is the defence; the experiment prefers exact frozen references so ground truth survives. Content addressing is not required. The simplest unambiguous mechanism wins.

Locator invalidation. The pointer no longer resolves to the expected artifact or version. The chapter calls this reference drift or locator invalidation deliberately: whether the artifact’s content remains factually current belongs to Chapter 20, which owns world staleness. Chapter 13 asks only whether the handle still reaches the intended bytes.

Context-free artifacts. The artifact exists and resolves but cannot be understood outside its original conversation. “Fixed it by changing the second one” is perfectly recoverable and perfectly useless. Externalised artifacts need enough self-description, entities, provenance, structure, to stand outside the transcript that birthed them, without reproducing the whole transcript.

Two further cautions guard the resident side. First, uncertain conclusions must not harden during the move: if the artifact says serializer corruption is suspected but unverified, the anchor must not say it caused the bug. Chapter 11’s epistemic-status survival audits every anchor. Second, artifact creation can itself be lossy. Externalising the raw frozen source is fidelity-transparent; externalising a generated summary reintroduces every compaction concern of Chapter 11 under a new name. The first experiment externalises raw frozen sources precisely to isolate the residency mechanism from the compaction mechanism. Transformed artifacts come later, labelled as such.

What stays resident, and why

Not everything eligible should leave. Some information must remain continuously resident because it changes how every next action is interpreted: the current task objective, a critical active constraint, immediate plan state. A copy may exist externally, but repeatedly recovering the objective each turn would be pure overhead with no behavioural gain. Available externally does not imply should be non-resident. Residency has behavioural value, and the oracle condition in the experiment quantifies exactly how much by identifying turns where residency was waste: tokens kept resident on computations that never needed them, the residency analogue of Chapter 12’s over-fidelity, labelled only where hidden probes make the judgement defensible.

Candidate selection therefore stays conservative. Strong candidates are large recoverable sources, completed investigations with durable artifacts, detailed benchmark evidence, long logs, reference documentation, intermediate analysis. Retention class grants permission; it never mandates the action. The economic bet is explicit: externalisation pays when the cost of repeated residency exceeds write, reference, and recovery costs under acceptable behavioural risk. Like caching amortisation, with different variables, and with no universal equation claimed.

Persistent artifacts in real agents

Two first-party engineering sources and one third-party implementation show independent convergence on the same pattern. None is a controlled study. All are engineering evidence for availability-without-residency as a working architecture.

Anthropic’s context-engineering guidance describes just-in-time context as the maturing alternative to preloading everything: agents hold lightweight identifiers such as file paths, stored queries, and web links, then dynamically load data at runtime through tools. Its coding agent drops project instructions into context up front while glob and grep primitives retrieve files just in time, bypassing stale indexes. The same essay’s long-horizon section makes the residency argument directly: compaction distils the window, structured note-taking persists notes outside the window for later re-admission, and sub-agent architectures isolate deep search context so the lead agent receives only a distilled summary. The essay even names the trade this chapter prices: runtime exploration is slower than precomputed retrieval, and agents without good navigation heuristics waste context chasing dead ends.

Anthropic’s long-running-agent harness work supplies the harder case, continuity across context windows rather than within one. Even a frontier model with compaction failed a production-scale build from a bare prompt in two characteristic ways: attempting too much at once and running out of window mid-feature, and declaring victory over half-finished work. The harness answer was external working state by design. An initializer agent writes the environment an incrementally-working coding agent will need: a comprehensive feature list with pass/fail status, an init script, an initial commit. Each coding session then starts by reading progress notes and git history, works one feature, and ends by committing code and updating the progress file. The reported evidence is not that files are the best substrate. It is that production-style long-running designs independently externalise working state into durable artifacts rather than relying on transcript continuity, with compaction explicitly found insufficient as the sole continuity mechanism.

WithContext MCP is the concrete third-party store at the small end of the same spectrum. An MCP server giving agents project-scoped note management against an Obsidian vault: stable note paths, read, write, search, and list operations, session tracking with changelogs and todos, frontmatter and section editing, templates, and organisation presets. Two properties matter for this chapter and both are verified against the repository: operations are restricted to configured project folders with path validation that rejects traversal, which is scope enforcement in production form; and the tool surface separates writing state out from reading it back, which is the departure/return split this chapter and the next divide between themselves. Obsidian is not canonical and the 33-tool surface is not adopted. The transferable idea is the agent-visible external workspace with explicit project scoping.

Before any of that machinery, the file system itself is the baseline the experiment must beat. Write a file, keep the path, read it later. Repositories already provide identity, durability, version control, scope, and tool access for some use cases, which makes plain files a strong minimal externalisation mechanism rather than a placeholder. One separation is enforced: product and source artifacts are not the same as agent working artifacts, and session scratch should not be casually committed into application repositories. That distinction constrains the book’s own laboratory more than the prose, and it is recorded where the laboratory lives.

Mutable and immutable artifacts divide the design space without either side winning universally. Immutable evidence, test runs, logs, captured investigations, frozen reports, carries strong provenance and trivial reference semantics. Mutable working state, plan files, progress notes, todo lists, supports ongoing work but means later reads may see different content than earlier ones. The experiment uses exact frozen references so version drift cannot masquerade as reasoning error; collaborative mutable artifacts are named as the harder problem and left there.

Scope constrains recovery from the start. Task or project scope is all the experiment needs, and external availability must never become accidental cross-project leakage: an artifact from one project is not visible in another merely because the storage layer can reach it. Externalisation records scope metadata at write time. Broader context-world isolation belongs to Chapter 21.

Proposed experiments

Both experiments use deterministic long-investigation fixtures with known hidden future probes, following the fixture philosophy of Chapters 11 and 12. A source artifact of roughly 15,000 to 30,000 tokens carries exact identifiers, decisions, rationale, discarded alternatives, supporting evidence, incidental detail, and one hidden detail needed later. Fidelity schedulers never see the probes. The size is illustrative; the hidden-probe structure is mandatory.

Experiment 1: residency comparison. Six conditions on intermediate tasks that do not require the hidden detail, with no reloading permitted, so the measurement isolates the benefit of non-residency. A, full source resident every turn. B, resident compact summary in the Chapter 11 typed style. C, resident low-fidelity anchor in the Chapter 12 style. D, external full source with a resident opaque reference only. E, external full source with a resident semantic anchor plus recovery identity. F, oracle residency using probe knowledge to keep the minimum resident information, a ceiling rather than a policy. Conditions D and E carry a reference-richness sub-axis under the same artifact: opaque identifier alone, plus short title, plus semantic anchor, plus metadata. The question is how much resident reference later use actually requires, answered behaviourally rather than by taste.

Experiment 2: explicit recovery integrity. For probes that need detail existing only externally, the evaluator issues a deterministic explicit load for a named artifact. No ranking, no search, no discovery; Chapter 14 is not smuggled in. The trial scores reference resolution, correct artifact, correct version, content intact, provenance intact, then supplies the recovered artifact and measures downstream behaviour. Integrity failures and reasoning failures are recorded as different events throughout: could not find the artifact is never merged with loaded it but reasoned badly.

Measurements for both, at minimum: resident tokens, reference tokens, artifact bytes, write cost, recovery frequency, reintroduced tokens, reference integrity, artifact integrity, downstream behaviour, cache transition cost. Resident waste is reported for oracle-checkable turns only. Reference overhead is reported per richness level so metadata inflation is visible as a number.

Falsification is stated in advance. References consuming most of the savings, reload frequencies that make residency cheaper, common integrity failures, anchors that shed epistemic or provenance content, latency or friction that reduces task success, typed compaction matching externalisation at lower complexity, few realistic traces containing large externalisable objects, version tracking whose complexity exceeds its benefit: any of these shrinks the mechanism. If the best result is that compact summaries should stay resident and artifacts add little, Chapter 13 narrows to that finding and the architecture is simpler for it. If externalisation buys large occupancy savings with rare recovery, it earns the larger role the outline proposes. The experiment is not designed to let externalisation win. It is designed to find out whether departure pays.

Context Lab and corpus implications

Nothing here is implemented in this repository; the records below are specified so the laboratory can grow them when an experiment consumes them. Conceptually, an external-artifact record carries identifier, scope, representation type, source references, creation time, version, size, content hash where appropriate, recovery locator, and recoverability status. An externalisation decision carries source item identifiers, artifact identifier, resident reference, tokens removed, reference tokens, mutation radius, application time, and policy version. Artifact and decision stay separate objects: an artifact can exist without being externalised from any context, and a decision refers to an artifact. Chapter 12’s representation/selection split is preserved, and lineage records the source items and capture the artifact derives from, enough to prove correspondence between the external object and its intended source.

On the corpus side the position is stated plainly. Project Context holds zero genuine ecological sessions at drafting time, so no prevalence claim enters this chapter. Synthetic deterministic fixtures remain the correct causal substrate for the residency and recovery experiments. Later real traces can answer how often large externalisable objects occur, how much context residency changes would save, and how frequently departed information is needed again. Those answers are unmeasured, and the chapter’s mechanism stands or falls on fixtures first.

What must return next

Externalisation draws its boundary with retrieval in one sentence. This chapter answers how information leaves the live context while remaining recoverable. The next answers when and how it should come back. No ranking, no query expansion, no embedding search, and no automatic recall were built here; the recovery contract defines the interface those mechanisms will one day call. Memory stays on its side of its own boundary: a benchmark output needed all project and discarded after is externalised working state, not memory, and durable cross-session influence remains the Memory book’s question, not this chapter’s.

Three principles survive the chapter whether or not the experiments favour aggressive departure. The context window is a working set, not a storage system. Information can remain available without remaining resident. And externalisation is only safe when the system preserves enough identity, provenance, and recoverability to make leaving the window reversible. Once information lives elsewhere, the system needs a principled way to bring back only what the current computation needs.

References

  • Anthropic Applied AI team (Rajasekaran, Dixon, Ryan, Hadfield, et al.). “Effective context engineering for AI agents.” First-party engineering essay, September 2025, verified September 2026. Just-in-time context with lightweight identifiers; dynamically loading data at runtime; structured note-taking persisted outside the context window; sub-agent context isolation. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  • Young, J., et al. “Effective harnesses for long-running agents.” First-party engineering essay, Anthropic, November 2025, verified September 2026. Initializer and coding-agent pattern; feature list, progress file, init script, and git history as continuity substrate; limits of compaction across context windows. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
  • boxpositron. “WithContext MCP Server.” Third-party implementation, MIT licence at review, v3.0.6, verified September 2026. Project-scoped durable notes with stable paths; read/write/search/list operations; session tracking; path validation restricting operations to project folders. https://github.com/boxpositron/with-context-mcp