A budget with seven claims on it and a fixed total needs somewhere to give, and four moves are available. LangChain set them out as a group on 2 July 2025 under four verbs, which are write, select, compress and isolate. The grouping caught on because every technique in the field turns out to be one of those four, applied to a different part of the context.
None of the four is new on its own. Persisting state outside a process, fetching only the rows a request needs, summarising a log and giving a job its own address space are all old ideas from other parts of computing. What the grouping added is the reminder that a team has exactly four options, so an argument about the context budget is an argument about which of the four to apply and in what order.
The order matters more than most write ups admit, and one ordering rule does most of the work. Selection comes before compression, because a summariser handed sixteen irrelevant passages returns a shorter, more confident and equally irrelevant paragraph, and charges a model call for it.
The sections below take the four moves one at a time, with the compression prompt written out in full, then give the ordering rule with the code that implements it, and finish with the four set against what each costs and what each risks.
Write and the state that lives outside the window
Writing means putting material somewhere the window is not, and keeping only a reference to it inside the window. A scratchpad holds intermediate work within one run, a memory record holds what should survive between runs, and a file, a row in a database or an object store holds anything too large to carry.
What writing buys is a change of unit. A tool result of four thousand tokens becomes an identifier of eight, and the model can ask for the rest by name when it needs it. Forty turns of transcript become a session key.
What writing costs is a second system that has to stay correct. Something decides what gets written, something decides when a written record stops being true, and nothing in the model will notice a stale record. Writing with no selection produces a store nobody reads back, which costs money to keep and reaches no answer.
Select and the choice of what comes in
Selection is the decision about what enters the window for this step, and it covers more than document retrieval.
- Passages are selected by a search over the index, which is pages ten and eleven.
- Memories are selected by a lookup against the current customer, the current task or the current step.
- Tools are selected by filtering the registry, since a model offered eleven tools is being asked a harder question than one offered three.
- Turns are selected by keeping the recent ones whole and treating the older ones differently.
Selection is the move with the highest ceiling and the lowest floor. A step where the right passage was selected can still go wrong in six ways. A step where it was not has no route to a correct answer, and the model will answer anyway.
Compress and what a summary throws away
Compression keeps the meaning and spends fewer tokens on it. Summarising the older turns of a conversation is the common case, and trimming a verbose tool result or pruning superseded steps from an agent's trace are the same move applied elsewhere.
Compression is itself a model call, which means it has a prompt, a temperature and its own failure modes. Teams write that prompt in four words and then wonder why the assistant forgot a commitment.
WEAK COMPRESSION PROMPT
Summarise the conversation so far.
STRONG COMPRESSION PROMPT
Rewrite the conversation below as a handover note for the next turn of
the same assistant. Aim for 250 tokens.
KEEP, verbatim wherever possible
- every identifier: order numbers, case numbers, policy clauses
- every figure stated by the customer or returned by a tool, with
its units
- every commitment made to the customer, with its date
- anything the customer corrected, and what it was corrected from
- the customer's stated goal, in the customer's own words
DROP
- greetings, apologies and restatements of the question
- anything a later turn has already superseded
- your own earlier explanations of policy
FORMAT
Goal:
Facts: one per line, each tagged with its turn number
Commitments: one per line, or the single word NONE
Corrections: one per line, or the single word NONE
Open: the one thing still unresolved
If two facts conflict, keep both and mark the pair CONFLICT. Never
resolve a conflict inside the summary.
Five things changed and the last one matters most. Identifiers and figures are kept verbatim, because a paraphrased order number is a wrong order number. Corrections are kept with what they replaced, since a summary holding only the corrected value loses the fact that the customer had to correct it. The format then gives the next call something parseable, and the token target gives the compressor a budget of its own.
And the conflict rule stops the summariser from making a decision nobody asked it to make. A compressor that quietly picks one of two contradictory facts has hidden a problem that the next page names and gives a remedy for.
Isolate and the clean window for a subtask
Isolation gives a subtask its own window with nothing in it except what the subtask needs. Reading a forty page contract to answer one question is the standard case. A separate call receives the contract and the question, returns two sentences, and the forty pages never enter the main context at all.
The cost is the boundary. Whatever crosses back is all the caller gets, so the design question is what the returned object contains, and a subtask that returns a paragraph of prose has given the caller something it must parse again. The deeper cost is that the isolated call cannot see the caller's context, so it can produce an answer that is correct about the document and wrong about the customer. Page 21 works through when several isolated agents beat one well built one, and the answer is less often than the diagrams suggest.
Why selection comes before compression
The moves compose, and the composition has an order. Written out as code, one turn of a support assistant applies all four.
def prepare_context(session, question, budget):
# WRITE. The full transcript and every tool result live outside the
# window. What travels inside it is identifiers.
store.append(session.id, session.last_turn)
# SELECT. Cast wide, then narrow. Tools are selected too.
candidates = index.search(question, k=20)
passages = rerank(question, candidates)[:4]
tools = registry.for_intent(classify_intent(question)) # 3 of 11
# COMPRESS, and only now, so the summariser never sees the sixteen
# passages that were dropped one line above.
history = session.turns[-3:]
if count_tokens(session.turns) > budget["history"]:
older = summarise(session.turns[:-3], HANDOVER_PROMPT)
history = [older] + history
# ISOLATE. A long document gets its own call, and two sentences come
# back into this one.
if needs_deep_read(passages):
passages = [subagent(READ_DOCUMENT, passages, fresh_window=True)]
return assemble(tools, passages, history, question)
Reversing the two middle blocks changes the result and the bill. A summariser run over twenty retrieved passages spends a model call turning sixteen irrelevant ones into a compact paragraph that reads authoritative, then hands that paragraph to the answering call as though it were evidence. The four passages that mattered are now diluted inside it, and no downstream check can recover them.
The same ordering applies to the transcript. Selecting the last three turns whole and compressing only what sits behind them keeps the recent detail exact, since recent turns are where the identifiers and the corrections live.
The four moves set against cost and risk
| Move | What it does to the context | What it costs | What it risks |
|---|---|---|---|
| Write | Replaces a payload with a reference | Storage and a second system to keep correct | A record that goes stale with nothing to invalidate it |
| Select | Decides what enters the window for this step | Retrieval quality becomes the ceiling on the answer | The one passage that mattered never coming back |
| Compress | Keeps fewer tokens for the same meaning | A model call, its latency and its own errors | A silent loss, since both summaries read complete |
| Isolate | Gives a subtask a window of its own | A handoff, and two contexts that cannot see each other | An answer right in its own window and wrong in the caller's |
The risk column is the one to read twice. Three of the four failures are silent. A stale memory, a missing passage and a lossy summary each produce a fluent answer with nothing in the wording to mark it, and the isolation failure is the only one of the four that often looks odd on the page.
Silence is the theme of the next page. A context that has grown too long, or picked up a false fact, or been handed eleven overlapping tools, does not return an error and does not stop working. It keeps answering, slightly worse, for as long as nobody measures it.