The Core Principles of Context Engineering

These four principles, write, select, compress, and isolate, give you a complete vocabulary for the techniques of context engineering. Almost every concrete method, from summarizing a chat history to spawning sub-agents, is one of these four applied to a particular part of the window. Naming them makes it possible to diagnose a context problem and reach for the right tool instead of guessing.

Write: Move Information Out of the Window

Writing context means storing information outside the window so it can be brought back later, rather than trying to hold everything in the window at once. The window is small and expensive, and most of what a system knows does not need to be present for any given request. Writing it out, to a scratchpad during a task or to long-term memory across sessions, is what lets a system operate over far more information than fits in a single context.

There are two common forms. The first is a scratchpad: during a long or multi-step task, the model writes notes, intermediate results, or a plan to an external store, then clears them from the active window and reads them back when relevant. This keeps the working window lean while preserving the work. The second is persistent memory: at the end of a session, the system writes durable facts about the user or the task to a memory store, so a future session can recall them. Both forms share the same logic, do not keep in the window what you can store and retrieve on demand. Writing is the principle that makes the other three possible, because you cannot select, compress, or isolate information you never persisted.

Select: Bring the Right Part Back In

Selecting context means choosing what to pull into the window for the current request. This is the retrieval step, and it is where most context quality is won or lost. Selection covers semantic search over a knowledge base, querying a memory store for relevant facts, fetching the right rows from a database, choosing which earlier conversation turns to include, and even deciding which tool definitions to expose for this request rather than all of them.

The art of selection is precision. Bringing in the right three passages and excluding the irrelevant fifty produces a grounded answer, while bringing in all fifty-three produces a diluted one even though the answer is technically present. Good selection ranks candidates by relevance and includes only the top ones that fit the budget, rather than including everything that is plausibly related. It also accounts for freshness and reliability, preferring a current, well-supported fact over a stale or contradicted one. The dedicated guide on retrieving the right context covers the techniques, and selection over accumulated facts is exactly what a memory layer provides.

Compress: Fit More Signal Into Fewer Tokens

Compressing context means reducing information so it occupies fewer tokens while keeping what matters. The most common form is summarizing a long conversation history into a short recap that preserves the facts still in play and drops the rest. Other forms include trimming a retrieved document to the relevant span instead of including the whole thing, deduplicating repeated information, and replacing verbose tool output with its essential result.

Compression is a trade-off that has to be made carefully, because aggressive summarization can discard a detail that turns out to matter later. The safe pattern is to compress the parts of the window least likely to be needed in full, old history rather than the current turn, and to preserve the specific facts, names, numbers, and decisions that downstream requests might depend on. Done well, compression buys window space without losing the information that earns its place. The guide to compressing context covers when summarization helps and how to avoid losing critical detail.

Isolate: Give Each Call Only What It Needs

Isolating context means splitting it across boundaries so that any single model call sees only the part relevant to its task. The clearest example is a multi-agent system: instead of running an entire complex task through one bloated window, you give each sub-agent its own focused window for its sub-task. Each window stays small and on-task, which keeps relevance density high for every call. Sandboxing tool execution so its full state does not flow into the model's window, and keeping certain system state out of the context entirely, are also forms of isolation.

Isolation is the principle that scales context engineering to large tasks. A single window has a hard ceiling, and even below that ceiling it degrades as it fills. By partitioning a task across multiple focused contexts, you sidestep both limits: no single window has to hold everything, and each one stays in the range where the model performs best. The cost is coordination, you now have to manage how the isolated contexts share results, which is itself a context engineering problem solved by writing intermediate results to a shared store. The patterns are covered in context engineering for AI agents.

How the Principles Combine

The four principles are not alternatives, they are layers of one system. A capable context pipeline writes durable facts and intermediate results out of the window, selects the relevant ones back in for each request, compresses history and long documents to fit the budget, and isolates distinct sub-tasks into their own focused windows. Remove any one and the system strains: without writing, nothing persists across sessions; without selection, the window fills with noise; without compression, long conversations overflow; without isolation, complex tasks hit the window ceiling.

Seen together, the principles all serve the one objective of context engineering, maximizing the share of the window that actually matters for the request. Write makes information available without occupying the window, select raises the relevant fraction directly, compress raises it by shrinking the low-value parts, and isolate raises it by keeping each window small. When you can name which principle a given technique belongs to, you can look at an underperforming system and identify which layer is weak rather than tuning at random. That diagnostic ability is what the principles are for.

Diagnosing a System by Principle

The practical value of the four principles is as a diagnostic checklist when a system underperforms. Each common symptom maps to a weak principle. If the model gives confident answers that miss information the system actually has, selection is weak, the right content is not being retrieved into the window. If quality degrades over a long conversation or a long task, compression is weak, accumulated content is bloating the window into context rot. If the system forgets things between sessions, the write principle is missing, nothing is being persisted. If a complex task overflows the window or loses coherence, isolation is missing, everything is being forced through one context instead of partitioned.

Running through the four in order, is the right content selected, is old content compressed, is durable information written out, is the task isolated, turns a vague complaint that the AI is not working well into a specific hypothesis you can test. It also prevents the common error of fixing the wrong layer, such as rewording the prompt when the real problem is that retrieval never surfaced the needed document. Most production context problems are a deficiency in exactly one of the four principles, which is what makes this checklist effective.

Where the Principles Come From

The four-strategy framing did not appear arbitrarily, it emerged from practitioners trying to name what actually works when building systems around the context window. The underlying insight is that the window is a scarce, shared resource, and there are only so many things you can do with a scarce resource: keep things out of it and bring them back on demand, choose what to put in, shrink what you put in, and partition it. Write, select, compress, and isolate are those four moves. This is why the framing is stable even as tools change, because it describes the irreducible options for managing a fixed-size context, not any particular implementation.

Treating the principles as a complete set is useful because it tells you when you have considered all your options. Facing a context problem, you can ask which of the four you have not yet applied, confident that there is not a fifth strategy you are missing. A system that selects and compresses but never writes or isolates has two unused levers, and naming them is often enough to suggest the fix. The principles are a map of the whole solution space for context management, which is what makes them worth learning as a set rather than as isolated tricks.