The Four Context Operations: Write, Select, Compress, and Isolate

The right information was somewhere in the system. It just never reached the decision that needed it.

Why "Too Much Context" Is the Wrong Diagnosis

A run fails. The agent produces a plausible artifact with one wrong field. You open the trace and find the schema was fetched two turns earlier, sitting in a tool result that got trimmed. The information existed. The decision that needed it did not have it.

The default mental model here is context as a container you fill until it overflows. That model predicts the wrong failure. It tells you to watch the token counter and summarize when you get close to the limit. But most real failures are not overflow. They are misplacement, staleness, and contamination — the right fact in the wrong window, or the wrong fact crowding out the right one.

The container model also hides the cost structure. In a long agent loop, the always-on context is re-paid every turn. A fifty-turn loop pays for its system prompt, its tool definitions, and its accumulated history fifty times. Context decisions compound into inference cost, not just answer quality. That changes what "good enough" means: a slightly leaner context that survives the loop beats a richer one that gets truncated at turn thirty.

I find it more useful to treat context as state that four operations move through. Write persists state outside the window. Select pulls it in. Compress reduces it in place. Isolate splits it across windows. At every model decision, the assembled context is the output of some sequence of these four operations — and each operation has a characteristic failure. When a run degrades, the question is not "was there too much context?" It is "which operation dropped the ball?"

That reframing is the whole point. Symptoms are vague. Operations are diagnosable.

Write: Persisting State Outside the Window

Write is the operation that decides what survives a turn boundary. Scratchpads, plans, memory files, structured state fields, external stores — the mechanism varies, but the design question is constant: what deserves to outlive the current window?

The asymmetry between write and read is where most people get confused. Information written but never selected is dead weight. Information never written cannot be recovered by any downstream operation. Write is the only operation with no fallback. If you skip it, nothing later can save you.

Two failure modes dominate.

Write omission. The agent solves a sub-problem — figures out the correct API shape, resolves an ambiguity in the spec — and then discards the result because it lived only in the reasoning trace. Three turns later, a different branch re-derives the same answer at full cost, or worse, derives a different one. This looks like inconsistency. It is amnesia.

Write pollution. The opposite mistake: persisting raw tool output, dead-end reasoning, and full transcripts because storage is cheap. It is cheap until it is selected. Then it crowds out signal and the model pays attention to noise.

My rule is to write the conclusion and the evidence pointer, not the transcript. "The contacts API expects email as a string, not an object; see routes/contacts.ts:42" survives compression, survives selection, and gives a later step something to verify against. The raw HTTP response that produced that conclusion does not.

Select: Getting the Right Evidence Into the Decision

Select covers everything that pulls external or stored context into the current window: retrieval, file reads, tool calls, routing rules. It is scoped to a single decision, which is what makes it tractable. You are not asking "what is relevant to this project?" You are asking "what does this decision require?"

The precision/recall tradeoff here is real and asymmetric. Missing evidence causes confident guessing — the model fills the gap with a plausible fabrication. Surplus evidence creates competition for attention and can make salient constraints harder to use, with effects that depend on the model, the ordering, and the formatting. Both fail, but they fail differently, and the fixes are opposite.

Selection miss. The evidence exists in the store, but the query, index, or routing rule never surfaces it. This is a retrieval bug, not a reasoning bug. Blaming the model here is the most common misdiagnosis I see. If the fact was never in the window, no amount of model capability helps.

Selection flood. Dumping a whole codebase or document set and expecting the model to filter. It will not. Everything you put in competes for weight, and a buried constraint loses to a loud distractor.

The diagnostic move is to log what was selected per decision and compare it against what the decision actually required. That comparison is usually uncomfortable, which is the point.

Compress: Reducing In-Place Without Losing the Thread

Compression is a lossy transformation with a measurable budget. Two mechanisms do the work, and they fail differently.

Summarization uses a model to distill. Trimming or pruning uses heuristics or a trained pruner to remove. Summarization preserves meaning but drifts. Trimming is deterministic but blind.

Summarization failure is semantic drift. Each pass loses specifics, and errors compound across passes. If a detail matters, compress once, not recursively. A summary of a summary of a summary is a rumor.

Trimming failure is boundary loss. A hard-coded recency rule — keep the last N messages — deletes the constraint that was stated once at the start and never repeated. The rule was correct when written. The heuristic did not know that.

What to compress: tool outputs, completed phases, resolved debugging. What not to compress: active constraints, schemas, and anything the next decision depends on verbatim. The distinction is not about importance in the abstract. It is about whether a later operation needs the exact tokens or just the gist.

Compression is the operation that buys turns. Track tokens before and after, and treat the ratio as a tunable, not a constant. A compression ratio that looks aggressive in isolation may be exactly right for a phase that is genuinely done.

Isolate: Splitting Context Across Windows

Isolation buys focus and parallelism at the price of a new failure class. The mechanisms are familiar: sub-agents with their own windows, functional separation (analysis / execution / validation), hierarchical layers, and data-perimeter splits where raw input must not leave a boundary.

What isolation buys is real. No cross-contamination between tasks. Smaller windows per decision, which means less dilution. Parallel execution, which means wall-clock speed. When tasks are genuinely independent, isolation is close to free.

When they are not, it is expensive.

Handoff ambiguity. An isolated agent only knows what it was handed. A vague brief gets filled with a guess, and multiple agents guess differently about the same target. The planner says "update the user record." The executor picks a schema. The validator picks another. Nobody is wrong; nobody was told.

Lost shared state. The planner's constraint never reaches the executor because nobody wrote it into the handoff. This is a write failure wearing an isolation costume. The sub-agent is not at fault for not knowing what it was never given.

My decision rule: isolate when tasks are genuinely independent or when contamination is the risk. Do not isolate to avoid writing a clear brief. Isolation does not remove the need for a handoff schema; it makes that schema the entire contract.

The Operations Interact: Composition and Conflict

The four operations are not independent levers. They trade against each other, and the composition is where most real bugs live.

Write enables select. Nothing can be selected that was never written. This means many "retrieval failures" are upstream write failures. Before you tune the index, check whether the fact was ever persisted.

Compress fights select. Aggressive compression removes the detail a later selection step needed. The compression was correct for the phase that ran it and wrong for the phase that followed. This is why compression policy belongs to the lifecycle, not to a single node.

Isolate forces write. Every handoff is a write operation with a schema. An unspecified handoff schema is the root of most multi-agent drift. If you cannot write down what the sub-agent needs, you do not yet know what the task is.

And then there is conflict prioritization, which is unresolved in practice. When a cached instruction and a fresh observation disagree, the system needs an explicit precedence rule. Most stacks do not have one. They have whatever order the assembly code happens to produce, which is a precedence rule in the same way that a coin flip is a decision procedure.

I want to be honest about measurement here. Context quality metrics remain immature. Cache hit rate is measurable. Cost is measurable. Relevance generally requires human judgment or an A/B test with a domain expert. That gap limits how much of this you can optimize on a dashboard, and it is worth knowing before you build one.

Diagnosing a Context Failure by Tracing Backward

The four-question checklist sounds like a pipeline, but real lifecycles are not linear. You can write after selection, compress before a later write, or isolate a branch whose handoff is itself newly assembled. A mechanical checklist will misattribute a missing fact to isolation when the handoff assembler or the selection policy dropped it.

The invariant to check is simpler: the decision's required facts must be present in the assembled context with provenance and freshness. When a fact is missing, trace it backward from the decision through the actual lifecycle — assembled context, then selection/compression/handoff, then the persisted source — and find the operation that dropped it.

Walk a plausible failure through the trace. The agent contradicts the planner's constraint. Start at the executor's assembled context: the constraint is not there. Trace back one step: the executor's window was assembled from the task brief, not the planner's state. Trace back again: the planner's state did contain the constraint, but the handoff assembler never copied it into the brief. The operation that dropped it was write — the handoff write — not isolation and not the executor's reasoning.

Notice how the answer changes the fix. If you had stopped at "the executor is unreliable," you would have rewritten a prompt that was never the problem. The fix is a handoff schema that includes active constraints.

One boundary worth stating: not every task needs this machinery. A short single-turn task with a small, stable context does not have a lifecycle. Adding write, select, compress, and isolate to a task that fits in one window is overkill that adds failure surface without adding capability. The operations are for systems where context is genuinely scarce and decisions are genuinely sequential.

Instrument Before You Optimize

You cannot fix an operation you cannot observe. That is the whole argument, and it is why I would not start by tuning retrieval or rewriting summaries. I would start by logging.

The minimum viable instrumentation is one event per operation per decision, with enough fields to reconstruct the trace. A compact shape:

{
  "decision_id": "exec-042",
  "operation": "write",
  "item_id": "constraint-email-format",
  "source": "planner_state",
  "state_version": 7,
  "included": true,
  "reason": "handoff_schema_v2"
}

The fields that matter: a stable decision_id so you can group events, an item_id so you can follow one fact across operations, a source so you know where it came from, and an included flag with a reason so you can see why it was kept or dropped. With those four, you can replay a failing trajectory and attribute the failure to a single operation.

Re-run a known-failing trajectory with this logging on. Find the decision where the required fact disappeared. Name the operation. The attribution is the deliverable. Once you can name the operation, the fix has a known cost and a known failure mode, and you stop guessing.

The adjacent unresolved problem is context evaluation: measuring whether the assembled context was actually good, not just cheap. That is where the discipline is still thin, and it is the next thing worth building.