# Externalize the Working Set
# Book: Context From First Principles
# Chapter URL: https://programmer.ie/books/context/13-chapter/
# Prose fingerprint (sha256, normalized): 4562ee14aaa4b9cf24422bdd6e3053d8bf9bef78bf62a5578c7bfda48575fe76
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Chapter 12 asked which legal representation of an admitted content object should be active. Even the cheapest useful resident representations still consume capacity. Consider an illustrative dependency-migration session. The agent has accumulated an architecture investigation of roughly 18,000 tokens, a benchmark report of 12,000, a compiler trace of 25,000, a design-alternatives note of 15,000 and a vendored API reference of 30,000. Those figures describe the full working objects, not necessarily the tokens currently resident: suppose their selected views have already been compacted, yet together they still occupy substantial capacity. On most turns the task needs at most one of the five. Chapter 12 asked which form to show. It did not ask 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.
This chapter makes that distinction operational. It owns departure: the requirements a runtime must satisfy when a payload leaves the current model input but must remain available for later recovery. It does not promise that any departure is lossless by default. Identity, representation, access, integrity and successful recovery are obligations to establish and test. Chapter 14 owns how the runtime chooses what returns.
Availability is not residency So far the book has managed context as though useful information must occupy some representation inside the window. That is an assumption, and this chapter breaks it:
available to system ≠ resident in context Chapter 1’s flow applies: available information, runtime state, assembly, then the model input. Externalisation exploits the fact that information can stay available to the runtime without being present in the current inference.
External is defined relative to the model-visible context boundary and not to machines or networks. A local file, an in-process store, a database and a remote service can each be external. The invariant is that the useful payload is not represented in the current model input:
external to active context ≠ remote The operating-system working set is a useful analogy in one respect only: a resident subset of a larger store. It stops where hardware help stops. A model does not run against an address space whose missing page is transparently faulted in while the same computation continues. The runtime must recognise a need, resolve a reference and provide the content through a tool result or another model invocation. It may do that as part of an agentic sequence, but the earlier model computation is not retroactively supplied with the absent bytes. Context externalisation is therefore not virtual-memory paging.
Representation selection and residency selection Chapter 12’s chain runs from preservation policy to a legal representation set, then selection, then the active representation. Chapter 13 adds a different decision. Representation selection asks which legal representation is active. Residency selection asks whether any semantic payload should remain active at all:
representation selection ≠ residency selection
When a reference is rendered for the model, it occupies tokens even though the referenced payload does not. A runtime can also maintain an external object’s identity entirely outside the model input, with no resident reference at all, provided another mechanism can later identify it. This chapter concentrates on the visible-reference cases because they expose the difference between a short semantic cue and an opaque pointer. The table describes those cases, not every possible externalisation design:
State Semantic payload resident? Recovery reference resident? External object required? Future recovery required by policy? Resident representation Yes Optional No Not applicable Externalised, semantic reference A cue only Yes Yes Yes Externalised, opaque pointer No Yes Yes Yes Pruned No Not required No guarantee No The last row marks the policy boundary with Chapter 10. Under the pruning contract, the system need not preserve a recovery path for the removed payload; an independently surviving source may nevertheless exist. Under externalisation, recovery is an explicit obligation for the required horizon. The same source file can underlie either operation. The difference lies in the contract, not in whether bytes happen to remain on disk, and the experiment must record which contract applies.
Anchor, pointer and semantic reference Chapter 12 defined an anchor by function: a low-cost resident semantic representation satisfying some declared obligations. A pointer is a resident reference whose useful content lives elsewhere and must be resolved before it can participate:
anchor ≠ pointer An anchor carries declared semantic content the model can use without loading the full source. A bare pointer such as artifact://incident-17 identifies a potential recovery target but does not establish what happened in the incident; even the pointer’s identity and reachability must be validated. A semantic reference combines a short semantic cue with an external identity. Its two halves can fail independently: the cue may omit or distort a status, relation or constraint, while the identity may resolve incorrectly or not at all. A cue is therefore a new representation subject to Chapter 11’s preservation checks. Its illustrative fields are not a universal schema; the required fields follow from declared obligations and the recovery interface.
What externalisation is Context externalisation removes a semantic payload from the current model input while preserving an identified external representation and a recovery contract through which the runtime can make that representation available again.
Externalisation is not source deletion, and it is distinct from the subsequent act of retrieval or re-admission: departure and return have separate contracts. It also differs from refetching under Chapter 7’s policy. A refetchable source persists independently of the runtime’s act of moving context out, as with versioned documentation at its source; an externalised investigation report is deliberately retained by the runtime because later recovery is required. Both mechanisms may read files through the same tool. The distinction is why a source remains available and which identity and preservation guarantees the system owes, not the physical read operation:
externalise ≠ refetch The derived retention policy may permit externalisation, and permission does not mandate it. A content object can be legal to externalise and economically irrational to move, or a saving can violate a residency requirement:
policy legality ≠ economic desirability, and eligible ≠ apply now
Nor does it require permanent persistence. The external representation must survive for the horizon the policy requires, in whatever storage suits it, and this chapter designs no storage.
Inspect this in the Context Viewer The viewer scene for this chapter externalises one payload and leaves two references behind: a semantic cue and an opaque pointer. Open the scene and test each reference against the recovery contract. What to examine: which pointer resolves with version and integrity checks, and which merely names something. Source retention is not recoverability, and the pointer is drawn as a reference throughout — never as the evidence it names.
Only the validated pointer with version and integrity checks is recoverable. Constructed illustration. Open the externalisation scene in the Context Viewer
The recovery contract A pointer is syntax. The operational promise behind it is the recovery contract, and that is the chapter’s main object. Its properties matter more than any production schema: object identity; representation identity and type; a version or content identity where fidelity demands it; a locator or resolver; permitted project or task scope; provenance; an availability horizon; and an integrity check where exact bytes matter. The contract must also state what constitutes success: merely finding a file, reading matching bytes, or making the recovered representation available to a subsequent model invocation are different endpoints. An unverified identifier or access claim must be reported as such, never silently promoted to a guarantee.
Four identities differ, and each can change independently:
object identity ≠ representation identity ≠ version identity ≠ locator A durable object identity is designed to survive storage moves, while a locator describes where resolution currently occurs; whether either property holds is something to test. If artifact://incident-17 can resolve to a raw log, structured record or report, the contract must identify the intended representation or define a deterministic resolution rule. If progress.md is mutable, its path cannot by itself establish the version previously used. The initial experiment freezes representations and references so version drift cannot masquerade as reasoning failure. Mutable working artifacts remain an explicit extension, not a solved case. Metadata bytes and payload bytes are accounted for separately, and a content hash establishes equality only against the expected content identity, not semantic validity.
Provenance is where the artifact came from and how it was produced. Its discipline from Chapters 11 and 12 extends across the boundary, adding artifact identity, the write event, version identity and the later recovery event. It does not establish authority, which Chapter 19 owns:
provenance ≠ authority
Scope is recorded to prevent accidental resolution outside the intended project or task boundary, and broader scope semantics belong to Chapter 21.
The distinctions that matter for testing:
pointer ≠ recoverability ≠ successful recovery exists ≠ accessible ≠ recoverable recoverable ≠ reversible A pointer expresses an intended route to content; it is not evidence that the route works. A recovery contract is likewise a specification, not a completed recovery. A tested recovery checks the intended identity, resolution, existence, authorisation, readable representation, expected version and integrity, then records whether the payload was merely returned to the runtime or was actually admitted to a subsequent model input. These last two events must not be conflated. If the contract permits a newer or transformed representation, the trace must say so; that is not byte-exact restoration of the earlier context. The result is recovery under tested conditions, not a general guarantee of reversibility.
What the model has observed The epistemic risk is the chapter’s most important. A resident line reading “Evidence: artifact://incident-17” does not mean the model has observed the artifact:
available evidence ≠ observed evidence, and reference present ≠ artifact observed
Resident text should distinguish evidence actually supplied to the model from information merely available through an external handle. Otherwise the model may treat an unread artifact as supporting a conclusion. A trace should distinguish at least reference rendered, resolution attempted, identity and access checked, payload returned, and payload admitted to a particular invocation. A successful tool read alone does not prove that its result was included in the next model input. The chapter prescribes these distinctions but does not implement the events. Epistemic status must survive both artifact creation and cue generation: if the source only suspects timestamp corruption, no generated cue may silently promote the suspicion to a finding.
When the contract fails Failures are classified by where the contract breaks, and each is scored apart from reasoning quality:
Identity failure: the reference does not uniquely identify the intended object, as when two objects share an ambiguous path. Resolution failure: the identity does not resolve to a current locator or object. Version or integrity failure: the resolved object is not the expected representation, version or bytes. Access or scope failure: the object exists but the runtime is not permitted or able to reach it. Interpretability failure: it resolves correctly and cannot be understood outside its original conversation. Representation-contract failure: the reference claims raw or exact content and the stored object is transformed or incomplete. The first five machine-checkable failures and the representation-contract failure belong to the departure and recovery contract, while interpretability introduces a separate question about whether the recovered representation can be used correctly. If the runtime is given a precise identity and resolves the wrong version or object, Chapter 13’s contract has failed. If the runtime must choose among ten valid artifacts and chooses the wrong target for the task, Chapter 14’s retrieval or selection policy has failed. Those failure locations can yield the same wrong answer, but they require different tests:
recovery integrity failure ≠ retrieval selection failure
Finally, an artifact recovered correctly is not necessarily used correctly, which is Chapter 5’s ladder again. Whether staleness applies to the artifact’s content belongs to Chapter 20, and this chapter asks only whether the handle reaches the intended bytes.
Externalising exact frozen bytes introduces no intended semantic transformation at the write step, and it can still introduce truncation, encoding, version or corruption errors, so it is not failure-proof. Externalising a generated summary reintroduces Chapter 11’s transformation risk on top. The first experiment therefore externalises raw frozen sources to isolate residency from transformation.
The cost of departure A smaller live context does not automatically mean a cheaper system. Costs are separate:
Residency: payload tokens removed, reference tokens introduced, and active tokens over the trajectory. A rich reference of identifier, title, summary, tags, scope, version and provenance can consume much of the saving. Write: generation if any, serialisation, validation, storage and reference construction, which are incurred costs and billed ones only if a price is measured. Management: the registry, versioning, scope enforcement and integrity checking. Recovery: resolution latency, bytes and tokens read, reintroduced tokens and tool calls. Behaviour: measured separately. Cache and reuse: only where provider semantics and telemetry support it. Following Chapter 9, first-divergence and observable reuse effects are recorded, and mutation radius remains a proposed accounting concept. Two frequencies matter, with denominators stated. Residency frequency is the fraction of observed model invocations in which a particular payload or its selected semantic representation is admitted. Recovery frequency is the number of attempted or successful resolutions per invocation or per task, reported separately, since repeated reads may not lead to admission. Full recovery and re-admission on most turns can erase the token saving and increase latency. Task boundaries, cache-safe boundaries and pressure thresholds are candidate transition times, not recommendations. The trace must count the cost of the externalisation machinery as well as the context it saves.
What may stay resident Some information plausibly stays resident because it changes how every next action is read: the current objective, a critical active constraint, immediate plan state. These are likely candidates, not laws, and repeated recovery of an objective each turn could be pure overhead. Raw evidence outside and a semantic cue inside is a useful split, as long as the model does not reason as if it has inspected the raw evidence. Resident waste is measured only against a fixture-specific oracle with hindsight of the hidden requirements, never as a production claim.
Engineering examples Three sources show information maintained outside active model context and later reached through explicit mechanisms. They are engineering examples, not controlled studies and not independent replications.
Source Evidence type Verified claim Chapter uses Does not establish Anthropic, “Effective context engineering for AI agents” (Applied AI team) Vendor engineering guidance Agents keep lightweight identifiers such as file paths, stored queries and links and load data at runtime through tools; notes are persisted outside the window and pulled back later; sub-agents work with clean windows; runtime exploration is slower than precomputed retrieval Availability without residency as a working pattern, with a stated cost Effectiveness Anthropic, “Effective harnesses for long-running agents” (November 2025) Vendor engineering report Two failure modes, attempting too much and declaring completion prematurely; compaction alone was not sufficient; an initializer writes a pass/fail feature list, an init script, a progress file and an initial commit; each session reads progress and git history, works one feature, and commits Working state kept in durable artifacts alongside compaction That files are the best substrate WithContext MCP (boxpositron) Third-party implementation, MIT An MCP server with 33 tools for project-scoped notes in an Obsidian vault, with session changelogs and todos, and operations restricted to configured project folders with path validation Scope enforcement in a small workspace Effectiveness; adoption of its tool surface Before that machinery, the file system is the baseline any mechanism must beat: write a file, keep the path and version, read it later. Plain files offer a locator and sometimes a practical identity, but a rename breaks a path, a version identity exists only if a commit or content hash is recorded, and a repository does not by itself enforce semantic scope. More infrastructure is not better externalisation until it does something plain files cannot. Product artifacts and agent working artifacts can have different lifecycles and should not be conflated accidentally, which is a hygiene rule and not a first-principles law.
Proposed experiments Nothing here has been run.
Ecological gate. Before elaborate machinery, describe real traces: how much active context consists of large objects that are not needed on most invocations but are needed again later, how often they recur, how long they live, how large references would be, and what exactness is required. The corpus of real sessions is empty, so the opportunity is unmeasured:
externalisation can work ≠ its opportunity is common
Experiment A: departure. Does removing a payload from active context reduce occupancy, and what behavioural effects occur when the current task does not require that payload? Fixtures use frozen sources of 15,000 to 30,000 tokens containing exact identifiers and decisions; target tasks are specified in advance not to depend on those sources, and recovery is disabled during the measured interval. Conditions are: full source resident; resident compact representation; resident semantic anchor without external dependency; source stored externally with an opaque pointer; source stored externally with a semantic cue and tested identity; and fixture-specific oracle residency. The compact and anchor conditions introduce transformation, while the pointer condition isolates departure more closely. They are interpreted as distinct contrasts, not as one pure manipulation. A matched semantic cue must carry the same claims across any cue-bearing conditions, or differences may reflect extra information rather than residency. Record active payload and reference tokens, total occupancy, external write and management costs, and separately evaluate task success and unsupported claims about unread artifacts. Active sizes intentionally differ; matched-budget comparisons are secondary, and no behavioural difference is automatically attributed to residency alone.
Experiment B: recovery integrity. Give the runtime an explicit frozen artifact identity and require resolution without ranking alternative candidates, separating this test from Chapter 14’s selection problem. Check object and representation identity, version, expected hash, existence, scope, access and provenance requirements with deterministic assertions. Record both retrieval to the runtime and actual admission to an invocation when admission is part of the tested contract. Inject a missing object, moved locator, ambiguous alias, wrong version, permission denial, corrupted bytes, representation mismatch and missing provenance. A context-dependent artifact is assessed separately for interpretability, since inability to understand correctly recovered bytes is not the same kind of failure as a bad hash. Use human review or a blinded model judge only for interpretation questions; no judge is needed for deterministic checks.
A transformed-artifact condition is added only later and separately, since it would mix Chapter 11’s transformation risk with Chapter 13’s recovery risk.
Results that would narrow the chapter. Resident typed compaction matches externalisation at lower cost; references consume most of the saving; recovery is frequent enough to raise total cost or latency; opaque pointers degrade decisions before any retrieval; semantic references distort status or relations; contract failures are common; real traces rarely contain such objects; or plain files match the artifact machinery. Each is a valid result.
What returns next Chapter 13 ends when the external representation, reference and recovery contract are specified and the runtime has demonstrated the required resolution path under test. It does not claim that a model can choose that artifact or use its contents correctly. Chapter 14 begins with the selection problem: which object to return, when, in what form and for which task. No ranking, query expansion or automatic recall is built here, and an artifact persisted outside the window is not automatically agent memory. Durable cross-session influence remains the Memory book’s question.
The chapter keeps three points whatever the experiments show. Context is a working set drawn from a larger information world and is not a storage system. Information can remain available without remaining resident. And leaving the window safely takes more than a string that looks like a reference: it takes an identified external representation, a recovery contract with provenance and scope, and evidence, independent of model behaviour, that the contract resolves to the intended information.
Once the system has a larger external information world than can fit in context, how does it decide what should return for this computation?
References Anthropic Applied AI team (Rajasekaran, Dixon, Ryan, Hadfield, et al.). “Effective context engineering for AI agents.” Vendor engineering guidance, September 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents Young, J., et al. “Effective harnesses for long-running agents.” Anthropic engineering report, published 26 November 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents boxpositron. “WithContext MCP Server.” Third-party implementation, MIT licence, verified September 2026. Implementation facts only. https://github.com/boxpositron/with-context-mcp