Context engineering, explained: the skill that replaced prompting

A year ago the advice was: get better at prompting. Learn the magic phrasing, the role-play opener, the chain-of-thought trick. It worked, for a while. Then the models got good enough that the phrasing stopped being the problem — and a different skill started separating the people who ship from the people who fight their agent all day.

That skill is context engineering. It's the discipline of curating what your AI agent knows before it acts, rather than fussing over how you ask. And for anyone building software with agents, it's where the leverage moved.

Why prompting stopped scaling

Prompt engineering is the craft of one message — composing a single input that gets a good answer. It's real, and it still matters. But it has a ceiling, and you hit it fast when you're building something bigger than a one-off.

Here's the ceiling: a perfect prompt over thin context still guesses. Ask the sharpest possible question about your auth flow, and if the agent doesn't know how your auth actually works, it invents something plausible. Plausible is the trap — it looks right, it compiles, and it's quietly wrong. No amount of prompt polish fixes a knowledge gap.

So the question stopped being how do I phrase this? and became what does the agent need to know to get this right? That second question is context engineering.

What context engineering actually is

Context engineering is curating the information environment the agent reasons over — the relevant code, the decisions already made, the patterns to follow, the history of what's been tried. One useful way to see it is as three nested layers, each containing the last:

• Prompt engineering — the message. The single composed input.
• Context engineering — the memory. What a curator keeps or drops in a finite window.
• Harness engineering — the machine. The gather-act-verify loop the agent runs, retrying on failure.

Martin Fowler's team makes the same point from the practitioner's chair: the real work of harness engineering for coding agents is managing what the agent sees, not crafting one clever prompt. Context engineering is the middle layer — and most of the day-to-day skill lives there.

Stuart Leo

Prompt engineering controls how you ask. Context engineering controls what the agent knows when it answers. As the models got good, the second one started to matter far more than the first.

The smallest high-signal set

The instinct, when you realise context is the lever, is to give the agent everything. Paste the whole codebase. Dump every doc. More context, better answers, surely.

It's the opposite. The craft of context engineering is curating the smallest high-signal set — the least the agent needs to act well, and no more. A model handed a wall of marginally-relevant material doesn't get smarter. It gets distracted, and it gets expensive.

Good context is curated like a good brief: the relevant decisions, the patterns that apply here, the one gotcha that bites this exact task. Structure helps the agent navigate — clear headers turn a document into addressable units it can jump around, where the same text as an undifferentiated wall gets skimmed. You're not feeding the agent. You're orienting it.

Context rot and the finite window

There's a hard physical limit underneath all of this: the context window — the finite amount a model can hold at once. And every frontier model degrades as that window fills. The phenomenon has a name now: context rot. Past a certain fill level, the agent starts dropping details, losing the thread, and producing output that's confident and wrong.

This is why "just paste more" backfires twice over — it costs more and it rots faster. Context engineering treats the window as a budget. The move that works is to think in fill percentage, not raw token count: keep the original intent and the last couple of steps, summarise what's gone stale, and drop what no longer matters — before the agent starts guessing. Keeping the working set lean is half the discipline.

Where context should live

Here's the gap in most context-engineering advice: it treats context as something you assemble fresh each time. Retrieve the right files, build the right window, run the task, move on. The context is delivery — loaded to do a job, then gone.

That's a missed opportunity, because the most valuable context is the same every session: how this project is built, what's been decided, what traps you've already hit. Re-assembling it each time is the tax all over again.

The fix is to make context durable. Write the high-signal stuff down once — decisions, patterns, gotchas, a short note at the end of each session — and commit it to git so the agent reads it before it acts. Now context engineering isn't a thing you redo every morning. It's an asset that accrues. That durable, version-controlled form of context engineering is exactly what C² calls a contextbase: context as an investment that compounds, not delivery you reload.

Your first move

You don't need a framework to start. Notice the three things your agent keeps re-asking for — almost always how the project is structured, what's already been decided, and what's already gone wrong. Write each down in a markdown file. Commit them. Point the agent at them.

That's context engineering, made durable. The model is not the bottleneck — the context you give it is, and that's an engineering problem you can own.

Go deeper: see where C² sits across prompt, context and harness engineering, the head-to-head on prompt vs context engineering, or read the method it's built on.