Compress and Isolate — The Other Two Pillars

The sessions that go wrong slowly are worse than the ones that go wrong fast. An agent starts a long task sharp and precise; three hours in, it is re-reading files it already read, contradicting decisions it already made, and dragging four failed attempts behind it like tin cans on a string. Nothing about the write and select pillars from part 4 prevents this. Writing got the right standing context in; selecting fetched the right material at the right moment. But nothing, so far, has taken anything out. That is the job of the other two pillars.

The four-bucket taxonomy I am working through — write, select, compress, isolate — is LangChain's, articulated by Lance Martin in their context-engineering guide, and it earns its keep precisely here: the first two pillars are about supply, the last two are about disposal. Most people practise supply instinctively. Almost nobody practises disposal until a long session has taught them why.

Compression is not summarising for fun

Compression is the pillar that keeps a working context useful as it ages. The crude version everyone meets first is the automatic squeeze: the tool notices the window filling up and mechanically summarises the conversation so it can keep going. That works, in the sense that the session survives. It also loses things, because an automatic summary does not know which details were load-bearing.

The deliberate version is what Dex Horthy and the HumanLayer team call intentional compaction — a practice I will come back to properly in part 7, because they built a whole workflow around it. The move is simple to describe: at a natural boundary in the work, you have the agent distil the session into a small artefact — decisions made, files touched, the current state of the task, the next step — and then you start a fresh context window seeded with that artefact and nothing else. The history is gone. The meaning of the history survives, at perhaps a fiftieth of the token cost.

What does the artefact look like? Mine are plain markdown, and shamelessly boring:

# Compaction — invoice-service, tax rounding fix

## Decided
- Rounding happens once, at line-item level, in `TaxCalculator.RoundLine`
- The per-invoice second rounding in `InvoiceTotals` is the bug; remove it
- Keep banker's rounding; three tests encode the expected values

## Touched
- src/Billing/TaxCalculator.cs (fix applied)
- src/Billing/InvoiceTotals.cs (NOT yet changed)
- tests/Billing/TaxRoundingTests.cs (two of three tests added)

## Next
- Remove the double rounding in InvoiceTotals.RecalculateTotals
- Add the third test (credit notes) before touching anything else

Read it slowly, because the shape teaches the discipline. Every line is either a decision, a location, or a next action. There is no narrative, no transcript, no “then I tried”. A good compaction artefact is the answer to one question: what would a fresh copy of me need to continue this work without repeating any of it?

Compression has quieter forms too. Reducing a long design document to its outline before handing it over. Providing a two-line summary of each module with a link to the full file, so the agent drills into detail only where the task demands it. Pruning conversation history of resolved errors and superseded decisions — a wrong turn that was corrected an hour ago is pure noise now, and worse than noise, as part 6 will show. All of these are the same instinct applied at different scales: keep the meaning, shed the tokens.

The file system is the biggest context window you own

There is a limit to how much any summary can hold, and the most interesting compression strategy sidesteps the window entirely: have the agent write things down outside it. Notes, research findings, intermediate results, long tool outputs — persisted to files, out of the window, recallable by path when needed again.

The team behind the Manus agent made this the centre of their architecture. Yichao “Peak” Ji and the Manus team describe treating the file system as “the ultimate context: unlimited in size, persistent by nature, and directly operable by the agent”. I find that framing clarifying beyond its origin. The context window is expensive, volatile and small; the disk is cheap, durable and effectively infinite. An agent that knows how to externalise its own working memory — write the fifty-file survey to research/survey.md, keep only the path in the window — has traded its scarcest resource for its most abundant one.

This is also why the compaction artefact above is a file and not a message. Files survive the session. Files can seed the next session, or a different agent, or me in three weeks when the work resumes. The window forgets; the repository remembers.

Isolation, or the case for walls

The fourth pillar deals with a different pollutant: work that belongs to the task but should never share a window with it.

The canonical example is exploration. Answering “where is discount logic applied across this codebase?” might mean reading thirty files, grepping a dozen patterns, and following five dead ends. Every one of those reads lands in the context window of whoever did the searching. If the main agent does it, the main window now carries thirty files of mostly-irrelevant source for the rest of the session — paid for on every subsequent turn.

The fix is to fork the exploration into a sub-agent: a separate context window that does the messy reading, fills itself with search results and dead ends, and returns only the conclusion — half a page of findings — to the parent. The sub-agent's window is then discarded, dead ends and all. The parent pays for the answer, not the investigation.

Two things about sub-agents took me embarrassingly long to internalise. First, the returned summary is a contract, and it deserves the same care as any interface: a sub-agent that dumps its raw transcript back at the parent has isolated nothing. Second — and this is the one that corrects most early multi-agent enthusiasm — the reason to split work across agents is context hygiene, not job titles. A “front-end agent” and a “back-end agent” chatting to each other is theatre unless the split actually keeps two incompatible bodies of context out of each other's windows. Sometimes it does, and the pattern is justified. When it does not, one agent with disciplined compression beats a committee.

Isolation has smaller-scale forms as well. Keeping structured task state in an external object rather than woven through the conversation. Scoping an agent to one directory of a monorepo so its context never inherits its neighbours' conventions. Running a risky experiment in a throwaway session so that its failures never poison the main line of work. The common thread is deciding, in advance, which contexts must never mix.

One economy, four levers

Put the four pillars side by side and they stop looking like a list and start looking like an economy. Write is investment: standing context authored once, amortised over every session. Select is procurement: the right material fetched at the right moment. Compress is waste management: meaning retained, bulk shed. Isolate is zoning: incompatible work kept behind walls. Every context-engineering technique I have met — memory files, RAG, compaction, sub-agents, scratchpads on disk — is one of these four levers wearing task-specific clothes.

What the pillars do not tell you is when to pull the levers — how full is too full, and what happens to an agent that crosses the line. There is a working answer to that, and an honest one about how much of it is measured versus practitioner folklore. Next, the smart zone, the dumb zone and poisoned context.