Context Engineering Strategies: Write, Select, Compress, Isolate

Write, select, compress and isolate are four useful strategies for managing LLM context. They describe where information is stored, what enters a call, how it is shortened and when a task receives a separate context.

LangChain groups these strategies in its context engineering article. The grouping is a practical framework, not a claim that every system has exactly four possible operations.

Write information outside the active context

Writing stores information in a file, database, scratchpad or other persistent system. The active context can then carry an identifier and retrieve the details when needed.

For example, an agent can store a long search result under a run specific reference and keep a short description in context. The result remains accessible without being repeated in every call.

Storage needs ownership, access rules and a lifetime. Distinguish an observed fact from a model generated hypothesis. A note saying “the customer qualifies” should retain the evidence and rule behind that conclusion. Otherwise, a later call may treat an earlier guess as established fact.

Select the material needed for the current step

Selection applies to documents, memories, history and tools. A read only policy question may need a policy search tool but no refund tool. A shipping question may need one order record and no account wide purchase history.

Select within the user's permissions. Similarity ranking must not make an unauthorised document eligible for the model.

Selection also needs coverage tests. A short set containing the main rule but omitting its exception can be worse than a longer set. Measure whether all evidence required for the answer survives, including linked clauses and table headings.

Compress without hiding uncertainty

Compression reduces the representation of retained information. It can use ordinary code to remove unused fields or an LLM to summarise text. Model based summarisation is lossy and can introduce errors.

A task specific handover prompt is more useful than a general request to summarise:

Create a handover note for the next support step.

Preserve:
- the customer's current goal
- exact order and case identifiers
- relevant dates and amounts with their units
- commitments and their status
- corrections, including which earlier value was superseded
- unresolved questions and conflicting evidence
- source references for factual statements

Omit greetings and repeated explanations.
Do not invent a missing value or resolve an unresolved conflict.
Aim for 250 tokens. Mark any required detail that does not fit.

The token target is approximate until measured. If essential details do not fit, use structured state or a larger budget rather than forcing a misleading summary.

Record an explicit correction with its provenance, such as “Delivery date changed from March 3 to March 5 in turn 9.” A summariser should preserve that relationship. Two sources disagreeing without a resolution should remain marked as a conflict.

Isolate a subtask in its own context

Isolation gives a bounded task only the material it needs. A document review call might receive one contract, a specific question and relevant customer constraints. It returns findings with source locations.

A useful result includes the answer, supporting evidence, uncertainty and unresolved issues. A bare paragraph is difficult to verify when the caller cannot inspect how it was produced.

A separate context is not automatically a security boundary. The worker's permissions, tool access and output handling require independent controls. Isolation can reduce irrelevant context while also introducing handoff errors.

Combine the strategies deliberately

A support workflow might store the complete transcript, select current policy clauses, compress older discussion and isolate a lengthy attachment review. These operations can be combined without building a complex multi agent system.

Selection before compression is often a sensible default because there is little value in summarising irrelevant documents. Some systems also create summaries during indexing to help later selection, so the order depends on the stage and purpose.

Test the combined process with a case that depends on an older correction and a policy exception. Check whether both survive to the final decision. Token savings matter only after that requirement is met.