The Four Pillars of Context Engineering: Write, Select, Compress, Isolate

Everyone agrees context engineering replaced prompt engineering. Almost nobody agrees on what it actually is.

Search the term and you will find a framework with four pillars, another with five, and one ambitious post claiming six. KeyValue lists data flow, tool integration, memory architecture, and format optimization. Weaviate counts six. Anthropic's own guidance frames it as curating the optimal set of tokens during inference. The phrase is everywhere and the definition is a moving target.

That is a problem if you are trying to actually get better at it. You cannot practice a discipline whose vocabulary changes per blog post.

So this post does one thing: it takes the framing that has the most staying power, the one LangChain popularized and that practitioners keep coming back to, and explains the four pillars in terms a builder can use on their next session. Write, Select, Compress, Isolate. Then it names the pillar that every one of these frameworks quietly leaves out, the one that decides whether all the context work was worth anything.

#What Context Engineering Actually Is

Start with the definition that holds up. Context engineering is the art of filling the model's context window with just the right information at each step, and nothing else.

That last part is what people miss. Context engineering is not "give the agent more." A model has a finite attention budget, and every token you add competes for it. Anthropic's guidance puts a name to the failure mode: as context grows, models suffer distraction, clashing, and poisoning. Stuff the window with everything you have and the agent gets worse, not better. The skill is curation, not accumulation.

Here is the contradiction at the heart of it. The more capable agents become, the more they read on their own: more files, more tool outputs, more history. Left unmanaged, a more powerful agent fills its own context with more noise faster. Capability raises the ceiling and the risk at the same time. Which is exactly why context engineering became a discipline the moment agents started running loops instead of answering single prompts.

The four pillars are four ways to manage that finite window. Think of them as the verbs of the job.

#Pillar One: Write

Writing context means putting information somewhere outside the context window so it survives.

A model is stateless. Every session starts from nothing, and within a session, anything that scrolls out of the window is gone. Writing context is how you fight that. It is the scratchpad the agent uses to take notes mid-task, the memory file that carries facts across sessions, the plan it writes down before it starts so it does not lose the thread halfway through.

If you use Claude Code or Cursor, you already do a primitive version of this with a CLAUDE.md or AGENTS.md file. That is written context: durable facts about your project that you control, loaded every session so the agent does not start from zero. We covered the durable-context version of this in depth in the state file pattern, and it is the difference between an agent that knows your conventions and one you re-teach every morning.

The trap with Write is rot. Written context that drifts from the truth of your code stops helping and starts actively misleading. One builder on r/vibecoding put the cost plainly:

if at some point this context deviates from the truth of your product, the AI will start getting confused. So basically you are creating debt, you will need to keep maintaining your comments AND your code.

Written context is an asset only as long as it stays true. The moment it lies, it is a liability the agent trusts.

#Pillar Two: Select

Selecting context means pulling in the right information at the right moment, instead of loading everything up front.

This is the retrieval pillar. When an agent reads a file, queries a vector store, calls a tool, or searches your codebase, it is selecting context. The whole game is relevance. An agent that reads the three files it needs makes a good decision. An agent that reads thirty files, twenty-seven of which are irrelevant, has poisoned its own window with noise and will make a worse one.

The same applies to tools. Each tool definition you expose costs tokens and adds a choice the agent has to reason about. Give an agent forty tools when the task needs three, and you have not empowered it, you have distracted it. Select is the discipline of bringing in only what this step requires.

Here is the side-by-side that makes it concrete:

Loading everything: "Here is the entire codebase, all our docs, the full git history, every API endpoint. Build the contact form."

Selecting: "Build the contact form. Relevant files: the existing form component, the validation utils, the contacts API route. Convention: all forms use react-hook-form."

The second agent succeeds more often, costs less, and is easier to review. Not because it knows less, but because nothing it knows is noise.

#Pillar Three: Compress

Compressing context means reducing what is already in the window to the tokens that still matter.

Long agent loops rot from the inside. Old tool outputs, abandoned approaches, and dead-end reasoning pile up turn after turn. Compression is how you keep the signal high: summarizing a long conversation into its conclusions, trimming a giant tool output to the relevant lines, replacing twenty turns of debugging with one line that says what finally worked.

This pillar has a cost most people do not see until the bill arrives. Every turn of a loop re-pays for the whole context window. One builder did the math in a thread on running agent loops:

every loop turn re-pays for your always-on context, a loop that runs 50 turns pays that tax 50 times, the gap between $10 and $40 for the same work.

Compression is not just about staying under the token limit. It is about not paying for the same bloated context fifty times in a single task. Compress well and a long-running agent stays both sharp and affordable. Compress badly, and you are funding the model's confusion.

The trade-off is real: compress too aggressively and you lose the nuance the agent needed. The balance is genuinely hard, which is why it is a pillar and not a checkbox.

#Pillar Four: Isolate

Isolating context means splitting work across separate context windows so they do not contaminate each other.

This is the multi-agent pillar. Instead of one agent holding everything in one window, you give each sub-task its own clean context: a research agent with its own window, a builder agent with another, an orchestrator that hands off between them. Each one stays focused because it is not carrying the others' baggage.

Isolation is what makes parallel agent work possible at all. But it introduces the hardest problem in this whole discipline, and it is the bridge to the pillar nobody names. When you isolate work across separate windows, each agent only knows what you handed it. If what you handed it was vague, the agent fills the gap with a guess, and now you have several agents guessing differently about the same fuzzy target. Isolation multiplies your output and multiplies the ways a vague instruction goes wrong.

#The Pillar Everyone Skips

Write, Select, Compress, Isolate. Four verbs for managing the context window. Master all four and you can keep an agent's attention clean, cheap, and focused.

And the agent will still confidently build the wrong thing.

Here is the gap. Every one of these pillars is about how context flows: where it is stored, what gets pulled in, what gets trimmed, how it is partitioned. None of them is about what the context is supposed to produce. You can engineer a perfectly clean window pointed at a target that was never clearly defined, and the model will hit that fuzzy target with beautiful efficiency. Clean context, wrong outcome.

The missing pillar is the definition of done. Not how information moves through the window, but the specific, checkable description of what the agent is supposed to build and how you will know it succeeded. A circulating line in the agent-building community captures why this matters more as agents get more autonomous: a loop with nothing in it that can say "no" is just the agent agreeing with itself on repeat. Clean context with no acceptance criteria is a faster way to ship a confident mistake.

This is the part that does not live in a CLAUDE.md file or a retrieval system. A state file describes how your project works. Compression keeps the window lean. Isolation keeps agents focused. But none of them says: this feature is done when an unauthenticated user is redirected to /login, when the form rejects an invalid email with a visible error, when the contact is saved and appears in the list. That is a different kind of context, and it is the one that decides whether the other four pillars produced something you can trust.

This is the gap BrainGrid is built to close. You describe what you want to build, and the Planning Agent turns it into a requirement with explicit acceptance criteria, the checkable definition of done that the four pillars never supply on their own. The Builder Agent then builds against that requirement, in a managed sandbox with a live preview or in your own GitHub repo through your coding agent over MCP. And a feature is not finished until every criterion is verified with evidence. The four pillars keep the agent's attention clean. The acceptance criteria make sure that clean attention is pointed at the right thing, and prove it landed there.

#What This Means for You

If you are building with a coding agent right now, here is the concrete implication. The next time your agent confidently produces something subtly wrong, your instinct will be to blame the context: I should have given it more files, a better CLAUDE.md, a cleaner prompt. Sometimes that is right, and the four pillars are how you fix it.

But often the context was fine and the target was vague. The agent did exactly what you asked. You just never wrote down, in checkable terms, what "done" meant. No amount of Write, Select, Compress, or Isolate fixes an undefined outcome. Only a definition of done does.

So treat the four pillars as table stakes, the hygiene that keeps your agent sharp. Then add the fifth thing they leave out: before the agent writes a line, decide how you will know it succeeded. That is the context engineering that actually changes your hit rate.

#FAQ

#What are the 4 pillars of context engineering?

The four most widely cited pillars are Write, Select, Compress, and Isolate, a framing popularized by LangChain. Write means storing context outside the window so it survives (scratchpads, memory files, plans). Select means pulling in the right information at the right moment (file reads, retrieval, tool calls). Compress means reducing what is already in the window to the tokens that still matter (summarizing, trimming). Isolate means splitting work across separate context windows so sub-tasks do not contaminate each other (multi-agent setups). Note that there is no single official standard: other frameworks list different pillars, but these four are the most durable for builders working with coding agents.

#What is an example of context engineering?

A practical example: instead of telling a coding agent "here is the entire codebase, build the contact form," you select only the relevant files (the form component, validation utils, the contacts API route), state the convention it should follow, and write down what done means (an invalid email shows a visible error, the saved contact appears in the list). You are not giving the agent more, you are giving it exactly the right context and a checkable target. That curation, plus a clear definition of done, is context engineering in practice.

#Is context engineering still relevant?

More relevant, not less, as agents get more autonomous. The more an agent does on its own, the more context it pulls in without you watching, and the more a cluttered or poisoned window degrades its decisions. Context engineering is what keeps a long-running agent sharp instead of letting it drown in its own accumulated noise. The one caveat: managing context flow is necessary but not sufficient. A perfectly engineered window still needs a clear definition of done, or the agent just hits the wrong target efficiently.

#What is the difference between context engineering and prompt engineering?

Prompt engineering is about crafting the single instruction you type. Context engineering is about managing everything the model sees: instructions, retrieved files, tool outputs, memory, and conversation history, across an entire agent loop rather than one exchange. Prompt engineering optimizes one message. Context engineering optimizes the whole information environment the agent operates in, which is why it became the dominant framing once agents started running multi-step loops. We unpack this shift further in why context engineering is what you're actually doing.

#Why isn't there one agreed definition of the pillars of context engineering?

Because the field is young and several frameworks emerged in parallel. LangChain's Write, Select, Compress, Isolate is the most cited, but you will also see four-pillar versions built around data flow, tool integration, memory, and format, and six-pillar versions that split things further. They mostly describe the same underlying job, managing a finite context window, with different groupings. The practical move is to pick one framing, get fluent in it, and not get lost arguing taxonomy. What matters more than the exact count is the pillar most of them skip: the definition of done.

BrainGrid turns your idea into a requirement with acceptance criteria your coding agent builds against and is verified by, so a clean context window is always pointed at a target you can trust. Try it at braingrid.ai.