Protecting Context

Context engineering is the delicate art and science of filling the context window with just the right information for the next step.

-Andrej Karpathy

This is the second post in Product Engineering, short notes for the people building software, regardless of title. The first was six Claude Code quick wins. This one picks up where my own workflow stalled: for a long time I figured the bottleneck wasn't the model, it was you, the human driving one Claude at a time.

That was true right up until I automated myself out of the way. Once starting a new agent is one keystroke and three of them are running at once, you stop being the constraint. So what is?

It's the context window. And once I understood that, a bunch of features that felt like separate toys (subagents, skills, plan mode) turned out to be the same move wearing different hats.

The dumb zone

Here's the thing nobody tells you: an agent is only as smart as what's in its context window, and it gets dumber as that window fills.

Not at the very end, when it overflows, but well before that. In my experience the rot sets in around the halfway mark. Past ~50% full, Claude starts losing the thread: forgetting a decision you made twenty messages ago, re-reading a file it already read, confidently contradicting itself. I think of everything past that line as the dumb zone. The model didn't get worse. Its working memory got crowded.

So the whole game, past the basics, is this: keep each agent's context full of only the things that matter for the step it's on. Everything else is a tax.

There are really only four moves you have:

• Select: put only the relevant stuff in.
• Compress: summarize what's there when it gets heavy.
• Persist: push state out of the window (a file, a plan, a CLAUDE.md) and pull it back when needed.
• Isolate: do noisy work somewhere else entirely and bring back only the answer.

That last one is the one I slept on. It's what subagents are for.

What "protecting context" actually means

When I first wrote down "subagents are to protect context," I had a note next to it: don't fully understand this. Here's what finally made it click.

A subagent is a fresh Claude with its own clean context window. You hand it a job, it goes off and burns through whatever mess that job requires (reading ten files, grepping the codebase, fetching docs) and then it hands you back a single tidy answer. All the noise it generated to get there stays in its window, not yours.

Say I need to find how auth works across a sprawling codebase before planning a change. Done inline, that's twenty tool calls and a few thousand tokens of file dumps clogging my main session. I'm in the dumb zone before I've written a line. Done as a subagent, a "codebase explorer" goes and does all that reading in a throwaway context and comes back with: "auth lives in these three files, here's the flow, here's the gotcha." My main context stays clean. I paid the tokens; I didn't pay the clutter.

That's the whole idea. A subagent is a way to spend context you don't have to keep. Fan-out searches, doc lookups, "go read this and summarize it": anything noisy and conclusion-shaped is a candidate.

Skills are the same move, one level up

If subagents isolate work during a session, skills isolate instructions until you need them.

A skill is a folder with instructions (and maybe scripts) that Claude loads on demand. The key word is on demand. The full instructions for some fiddly workflow (how you cut a release, how your tests are wired, your exact PR format) don't sit in the context window costing you tokens on every turn. They load only when the task actually comes up, do their job, and get out of the way.

This is why, given the choice between standing up a fleet of subagents and writing a few good skills, I lean toward one main agent plus a handful of skills. It's simpler, it's easier to reason about, and it keeps the default context lean. Reach for subagents when a specific subtask is noisy enough to quarantine; reach for skills when a workflow is repeatable enough to name.

The most useful subagent I've built

Concretely: a plan reviewer.

I write a plan in plan mode, then before I let anything execute, I hand it to a subagent whose entire job is to poke holes in it. "An engineer wrote this plan. It touches these files. Tell me what's wrong with it."

The non-obvious part is that the reviewer needs context on the codebase before it runs. A plan review with no knowledge of the actual code is just vibes. So it reads the relevant files first (in its own window, naturally), then critiques. What comes back is a clean list of holes, and my main session never had to hold the whole codebase to get it.

It's the same trick as the explorer: noisy work in an isolated window, one useful answer back.

The shape it all settles into

When I put it together, my default loop is boring on purpose: research → plan → implement.

Research goes to a subagent, so the file-reading mess never touches my main window. The plan lives in a file (persisted, out of context, pulled back when needed) and gets a review pass before anything runs. Implementation happens in the clean session that's left, with a skill or two loading on demand for the repeatable parts. And at the end, the agent verifies its own work, because an agent that can't check itself will cheerfully lie to you.

None of this is exotic. It's the same instinct as keeping a clean desk: the work goes faster not because you got smarter, but because you stopped making yourself dig through clutter to find the one thing you needed.

Pick the noisiest thing your agent does this week, the big search, the doc dive, the plan you never review, and move it off your main desk.

See you in the next one, Caden