Context engineering is real work. Here's the loop that runs it.

An agent has been triaging support tickets since nine in the morning. By two in the afternoon it asks a customer for their account tier, information the customer typed into the first message, six hours and forty tool calls ago. Nothing crashed. No error fired. The model is exactly as capable at two as it was at nine. What changed is what it could see.

That is not a prompt problem. It’s the gap the field now calls context engineering vs prompt engineering, and once agents stopped answering one question and started running for hours, the second discipline quietly became the entire job.

Context engineering is the discipline of curating exactly which tokens a model sees at each step of a long-horizon run, and it is where quality is won or lost, not in the model. This post defends that sentence: why the naive read (write one clever prompt, let the model handle the rest) collapses the moment a run gets long, what the field’s own numbers say is actually breaking, and the four moves, write, select, compress, isolate, that treat context as the finite, competing resource it always was — and, further down, where those four moves have to live: not a habit engineers remember to apply by hand, but a loop something runs on every step, the shape Apollo’s own agents are built around.

Context engineering vs prompt engineering: two different jobs

The naive move is to treat prompt engineering as the whole craft: write the system prompt carefully, tune the phrasing, ship it, assume the agent is handled. That instinct made sense for years, because for years an LLM call was one shot, one input, one output, done, and getting the wording right was most of the job.

It fails the moment an agent stops being one call and starts being a run. Anthropic’s own engineering team draws the line directly: prompt engineering “refers to methods for writing and organizing LLM instructions for optimal outcomes,” while context engineering “refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts,” across every turn, not just the first one. Andrej Karpathy put the same idea more bluntly: context engineering is “the delicate art and science of filling the context window with just the right information for the next step.” Neither definition mentions writing a better sentence; both describe a budget that changes shape at every step of the run.

The mechanism is simple once you see it. A prompt is static, you write it once. A context window on turn forty is not: it’s the system prompt plus every tool’s schema plus the accumulated history plus whatever got retrieved for this step, all competing for the same fixed number of tokens, and optimizing the wording of the system prompt does nothing about the other three tenants crowding that space.

The naive move that only works for an afternoon

So the next naive instinct, once someone notices the window is what actually matters, is to just put everything in it. The window is enormous now, hundreds of thousands of tokens. Every turn, paste back the full history, every tool’s complete spec, every document the agent touched. For an afternoon, this works beautifully. The agent seems to remember everything.

It fails because a context window is not neutral capacity, it’s contested space, and every tenant crammed in has an opportunity cost. Anthropic describes the resulting effect as “context rot”: recall degrades as the token count climbs, because attention is a finite resource spread across every token that’s present, not just the ones that matter. Multi-agent designs compound the cost again, coordinating sub-agents can run up to 15 times the token volume of a single agent, as Anthropic itself has reported, because every hand-off re-serializes context a cleaner design would have left behind. The window fills, the signal that mattered six hours ago gets buried under everything since, and the agent asking for the account tier again isn’t confused, it’s just looking at a window where that fact no longer fits.

This is a different failure than the one that shows up when an agent has no durable memory at all, which is why the window is not the same thing as memory in the first place. That earlier problem is about persistence: nothing survives between runs unless you deliberately write it to disk. This one shows up even with a perfect memory store sitting right there, because persistence only answers what’s saved, not what rides in the window on this specific turn, competing against the tool specs and the history still accumulating live. You can solve memory completely and still lose the afternoon, because context engineering is a live, per-step decision, not a one-time write.

A context window is not a bigger desk. It’s the same desk, and everything you don’t clear off it is still taking up room.

The four verbs: write, select, compress, isolate

The naive fix for an overflowing window is usually one move: add retrieval, and call it solved. Retrieval genuinely helps, recent research has found that applying it just to tool descriptions improves tool-selection accuracy roughly threefold, because the model stops choosing from every tool schema in the system and starts choosing only from the ones relevant to this step, say, forty tools down to five. But retrieval alone only answers select. It says nothing about the history that keeps growing turn over turn, or the subtask that’s about to dump its entire working trace back into the main run.

That’s why LangChain frames context engineering as four separate levers, not one: write, save state outside the window entirely, a scratchpad or one of the several kinds of memory store an agent actually needs, so it doesn’t have to live in every turn’s token budget. Select, pull back only the slice relevant to the current step, the retrieval move. Compress, summarize what’s accumulated so history stops growing without bound, the same discipline Claude Code applies when it triggers compaction and keeps only what’s still load-bearing rather than the full transcript. Isolate, hand a subtask to a sub-agent that runs in its own clean window and returns a short result instead of its entire working trace. Cognition AI’s framing is worth stating plainly: context engineering is “effectively the #1 job of engineers building AI agents,” and the four verbs are the closest thing the field has to a shared answer for what that job consists of.

Retrieval alone only ever answers select. It says nothing about the history still accumulating, or the subtask about to dump its full trace back into the run.

Applied together, not picked as a favorite, they stop tokens from ever piling up in one place: something is always either leaving the window, through write or compress, or returning smaller than it left, through isolate.

Naming four verbs is a description, not a runtime: someone still has to build the thing that writes, selects, compresses, and isolates, on every turn, without a human remembering to wire it in each time. That’s the layer a16z named system of intelligence, the reasoning layer over a company’s facts, and the layer Bessemer Venture Partners named system of action, software that executes and writes the outcome back rather than just recommending. Apollo’s agent loop is built to run the four verbs across exactly those layers, not as four separate habits. The System of Record, Apollo’s memory layer, is built to be the write target: an account tier or a stated preference is meant to be written there the moment it’s said, outside any single turn’s budget, so it’s still there on hour six. The System of Intelligence performs select and compress: an agent is designed to query that record for the slice this task needs, not replay the org’s whole history, and to fold what’s accumulated into a summary before the next turn. The System of Action is where isolate lives: a subtask is designed to run its own clean pass so only its short, structured result crosses back, written the same way the layers above it are, never the sub-agent’s full trace. Apollo isn’t claiming the terms, a16z and Bessemer did, or the verbs, LangChain did; what it’s built to own is the connective tissue, record to intelligence to action closing one loop instead of three vendors never designed to hand off to each other.

Context engineering is the discipline of curating exactly which tokens a model sees at each step of a long-horizon run, and it is where quality is won or lost, not in the model. The four verbs are not four options to pick from, they’re four separate ways of enforcing that discipline on every turn.

Where quality actually breaks, by the field’s own numbers

The last naive belief is the most expensive one: that a quality problem in production means you need a smarter model. Upgrade to the next frontier release, the thinking goes, and the agent that repeats itself or drops a detail will stop doing that.

It fails because the data says otherwise. LangChain’s own State of AI Agents survey, more than 1,300 practitioners, found that 57% of organizations already have agents running in production, and 32% still name quality, not capability, as the single biggest barrier to deploying further, essentially unchanged from the year prior. That’s not a benchmark gap; model releases happened in that window, and the barrier didn’t move because it was never really about what the model could reason through, but what it could see when it needed to reason. Swap in a better model and hand it the same overflowing, badly curated context, and you get the same wrong answer, delivered more fluently.

Once quality is understood as a context problem rather than a capability one, the fix isn’t a model upgrade, it’s budgeting the context pipeline the way you’d budget latency or cost, and verifying it the same way you’d verify any other part of the system, the same discipline behind treating a prompt itself as versioned code instead of a text box you edit on instinct.

What this costs, honestly

None of this is free, and pretending otherwise is its own failure mode. Write needs a real external store, and every store needs a decision about what’s worth persisting, get that wrong and it’s a landfill nobody can retrieve from. Compress is a bet: every summary risks discarding the one detail that mattered, and unlike a crash, a bad compression doesn’t announce itself, it just quietly removes the fact the next step needed. Isolate adds coordination, a sub-agent boundary is real latency and its own token overhead, exactly why multi-agent designs can cost several times a single agent’s tokens if the isolation isn’t earning its keep. Context engineering trades one obvious problem for several subtler ones, each requiring ongoing judgment rather than a one-time fix.

It’s worth the cost anyway, because the alternative isn’t cheaper, it’s deferred. An unmanaged window guarantees the failure eventually, it’s a question of which turn, not whether. An engineered pipeline degrades predictably instead: you can see compression getting lossy, measure retrieval precision, budget isolation’s overhead against what it saves. Predictable and tunable beats free and eventual, every time a run gets long enough to matter.

The turn

Strip away the pipeline language and what’s actually happening is an old, human kind of judgment, moved somewhere new. Deciding what a sub-agent hands back, what gets compressed away, what earns a place in the next turn’s window, is the same call a good editor makes about a draft: not everything the writer produced belongs in front of the reader, only what the reader needs next. The context window is standing in for the reader here, and the model is the one who has to work with whatever made it through.

That judgment doesn’t get automated away as models get smarter, it gets more important, because a smarter model given a worse-curated context still reasons over the wrong slice of the world, just more persuasively. The skill was never really about talking to the model. It was about deciding, moment to moment, what the model gets to see, a discipline a company builds and keeps, the same way it builds and keeps the structured memory an agent needs to reason across its own history or the broader practice of engineering an agent’s behavior on purpose rather than by accident.

Context engineering is the discipline of curating exactly which tokens a model sees at each step of a long-horizon run, and it is where quality is won or lost, not in the model. That’s the sentence worth remembering the next time a model upgrade ships and the same six-hour bug is still sitting there, unfixed.

---

Curation, not accumulation, is the default this whole post has been arguing for, and it’s the one Apollo’s agent loop is built to run on purpose rather than rediscover the hard way, record, intelligence, and action, on every step. The next time an agent asks a customer something it was already told six hours ago, the bug isn’t in the model that answered. It’s in whatever decided, quietly, what that model was allowed to see.