Context engineering is the most important idea in agentic software, and it has been mis-sold. The pitch you have heard treats it as a better way to write a prompt: trim the system message, retrieve the right snippet, remember to add an example. All useful, all beside the point. Run software delivery as a factory of agents rather than a single chat, and context engineering stops being a knob you tune. It becomes the machine you build.
The definitions are worth borrowing before we leave them behind. Anthropic frames context engineering as managing a finite resource: an agent's attention degrades as its context grows, so the job is to find the smallest set of high-signal tokens that produces the outcome you want. Gartner frames it as an enterprise discipline and warns that roughly two in five agentic AI projects will be cancelled by 2027, most of them on foundational gaps rather than model quality. Both are right. Neither tells an operator what to actually build. Here is what building it teaches you.
The god-context fallacy
The instinct when an agent underperforms is to give it more. More instructions, more files, more history. This is exactly backwards. A window stuffed with everything a task might touch is a window in which the model can find nothing, because attention is the scarce input and you just spent it on noise. The finite-resource framing has a blunt corollary: every token you add to buy coverage, you pay for in focus.
So the first design decision in a code factory is not which model. It is how many windows. A single agent asked to carry an issue from idea to merged code holds the whole world in one context and degrades across all of it. Split that work into stages — understand the issue, design the change, plan it, build it, review it, verify it — and each stage gets a window sized to one job. The design stage never sees the test logs. The verify stage never re-reads the brainstorm. Each hands the next a deliberately narrow artifact instead of its entire transcript, and each loads what it needs at the moment it needs it: the plan arrives when you implement, the diff arrives when you review. Nothing carries context it will not use.
That is context engineering as architecture. The pipeline exists to control what each model sees.
A factory is a sequence of engineered windows
Once the work is staged, two levers open up that a single prompt never had.
The first is which mind reads each window. Not every stage deserves the same model or the same care. The stages where a wrong call is expensive — the design, the review — get the strongest model at maximum effort. The mechanical stages — a pass/fail check, a triage — get a small, fast, cheap one. Matching model to the stakes of the window is itself a context decision. You are engineering not only what is read, but who reads it and how hard they think.
The second is isolation. When you want an adversarial review, the worst thing you can do is let two reviewers share a context. They converge, and you get one opinion wearing two hats. So the factory runs them as separate agents in separate processes, each blind to the other, and merges their findings only afterward. The same move keeps a deep-diving sub-agent from polluting the main line of work: it goes deep on one file and returns a paragraph, not its scrollback. Independence and cleanliness turn out to be the same discipline. You engineer the boundaries between contexts as deliberately as the contexts themselves.
The single biggest lever on what an agent ships is not the model. It is what the model is allowed to see. In a factory, that is a thing you design, not a thing you prompt.
Who holds the pen
The coding-agent literature asks a sharper question than most: who decides what goes into the context — the model, the human, or the software? A factory's answer is all three, on purpose, at different boundaries.
The deterministic layer decides the non-negotiables: what is in scope, which gates must pass, when to stop. You do not want a model improvising on merge protection. The orchestrator, itself a model, decides the judgment calls: which specialists this particular issue needs and how much effort to spend, chosen within a fixed budget and falling back to a safe default roster if it returns nonsense. And humans hold the two boundaries that anchor everything — the design going in and the merge decision coming out.
Deciding who controls each context boundary is the actual work. It is not a prompt. It is an operating model with the roles written down.
You can't title your way out of it
Which is where the standard enterprise advice goes soft. Told that context engineering matters, the reflex is to appoint a context-engineering lead and stand up a function. That produces a person who is responsible for context and a pipeline that still enforces none. The discipline has to live in the machine: the stages that keep windows small, the gates that fire on every run, the model map that spends attention where defects are costly. A title reminds people. Architecture makes forgetting impossible.
And you find out whether any of this curation works the only honest way, by measuring it. Run a corpus of known-bad changes through the factory and score how many each configuration catches. That turns "better context" from a belief into a number, and it forces every change to how you shape a window to earn its place against the version before it.
So the move for anyone running or funding agentic delivery is not to shop for a model that will rescue an unstructured pipeline. The model is rarely the ceiling. The ceiling is what you feed it, stage by stage, and whether the boundaries between those stages were designed or left to accident. The projects that get cancelled will not die of weak models. They will die because context was treated as a prompt-time afterthought instead of the first thing the system was built to control.
Context engineering is not a better prompt. It is the shape of the factory. Build the windows, decide who fills each one, and measure whether it holds. That is the work, and it is architecture, not housekeeping.