Context engineering vs. context design

"Context engineering" has become the term of the moment. It covers retrieval, chunking, window management, memory systems, tool use, the whole plumbing of getting information in front of a model efficiently. It's a real discipline, and it's genuinely hard.

It's also being used to mean two different things at once, and the gap between them is where most AI output actually goes wrong.

Two different jobs, one label

Context engineering is infrastructure. It's the work of getting the right material into a model in the right shape: extracted cleanly, packed to fit, formatted so a parser downstream can actually use it, checked for integrity before it's trusted. It answers "how does this material get to the model, intact, in a form something can act on."

Context design is judgement. It's the work of deciding what that material should actually be in the first place: which facts matter, which exceptions have to survive, what the output is meant to mean, not just contain. It answers "what does the model actually need to know to get this right," which is a different question entirely, and one no amount of clean plumbing answers on its own.

You can solve the first problem completely and still get confidently wrong or blandly generic output, because the material that arrived, intact and well-formatted, was the wrong material.

What that split looks like against real work

A recent piece of production image work makes the distinction concrete rather than abstract. A batch of category images needed generating from a spreadsheet of source data: extracting the right fields, packing them into a workable request, resizing outputs to spec, checking the results were structurally sound before anything shipped. All of that is context engineering. It's necessary, it's exacting, and getting it wrong breaks things visibly, a malformed request fails, a missing field throws an error.

None of it, on its own, decided whether an Oktoberfest glass should have beer in it, or whether a lifestyle shot needed one person or three to read correctly against the rest of the batch. Those were judgement calls: what the image needed to mean, not just what data needed to reach the generator. Get the engineering right and hand it a thin brief, and it'll faithfully produce a technically correct image that's still wrong, because nobody decided what "right" meant before asking for it.

That's the split in miniature. Most of what's marketed as context engineering right now is the first half. Almost nothing is selling the second half, because the second half doesn't look like a product. It looks like judgement, and judgement is harder to package.

Where the split gets expensive

Single-shot, the gap between these two is usually visible. Someone reads a bad output, notices it's wrong, and the engineering-versus-design question becomes obvious in hindsight: was the material missing, or was the wrong material sent in cleanly?

Agents remove that visibility. The Context Stack under agents documents four real failures inside a live multi-agent system, and every one of them was an engineering problem in disguise, a format contract too narrow, a parser silently returning a ceiling value, a routing gap that meant a fix didn't reach every consumer of it. Each one was fixable, and each one was fixed. None of them were failures of design, exactly, they were failures of the plumbing carrying design decisions between agents.

But that's exactly what makes the distinction matter more under agents, not less. When engineering fails, at least it tends to fail loudly eventually, a parser breaks, a score pins to a suspicious ceiling, someone notices. When design fails, the plumbing works perfectly and carries the wrong judgement faithfully from one agent to the next. A model given an incomplete picture of what "right" looks like doesn't pause and ask. It fills the gap with something plausible and moves on, and every agent downstream inherits that plausible-sounding gap as if it were fact. Solid engineering doesn't catch that. It ships it more reliably.

This is the same argument made elsewhere on this site about files and folders versus agentic memory, just one layer up. Down at the infrastructure layer, the debate is genuinely about mechanism, what retrieval method, what storage format. Up here, the debate that actually decides whether the output is any good has already been settled, or ignored, before any of that infrastructure gets touched.

Why this is worth naming

Most of the current AI tooling market is context engineering, and it's being sold, reasonably, as the solution to inconsistent AI output: better retrieval, longer windows, smarter chunking, more sophisticated memory. All of it is real progress on a real problem.

Almost none of it touches the other half. Nobody's shipping a product that decides what a business's exceptions are, which judgement calls have to survive into an output, what "correct" means for a specific case that doesn't show up cleanly in the data. That's not an infrastructure gap. It's a discipline gap, and infrastructure alone doesn't close it, however good the infrastructure gets.

Calling it "context engineering" when what's actually broken is context design isn't just a naming quibble. It sends people looking for the fix in the wrong layer, better tooling, when the thing that was actually missing was a decision someone needed to make and write down.