Context Engineering: The Skill That Replaced Prompting

Context engineering is the work of deciding what the model can see when it answers. It became the more important skill the moment context windows got large enough that "put everything in" stopped being impossible and started being a mistake.

Almost every disappointing result I am asked to debug turns out to be a context problem. The model was not weak. It was given three relevant paragraphs buried in forty pages of material, or it was never told the decision that made the question answerable.

Context engineering versus prompt engineering#

Prompt engineering is about the instruction: how you phrase the request, whether you show examples, how you ask it to reason. That skill still matters and prompt engineering examples covers it.

Context engineering is about everything else in the window: which documents, how much history, which tool outputs, what standing rules, and in what order. On any real system, that is a bigger lever than phrasing, because a perfect instruction applied to the wrong material still produces the wrong answer.

The shift is roughly this: prompting is writing a good question, context engineering is preparing the desk before someone sits down to answer it.

The rules that hold#

Relevance density beats volume. Three paragraphs that answer the question outperform forty pages containing them. Attention is finite and irrelevant material actively competes.

Position matters. Models attend most reliably to the start and the end of the window. Put standing instructions first, reference material in the middle, and the specific task last. Never bury the task.

Label the sections. Explicit markers between instructions, reference and task remove an entire class of confusion where the model treats an example as an instruction.

State the decisions, not just the facts. The most common gap is not missing documents, it is missing history: what was already tried, what was rejected, what constraint is non-negotiable. Without those, you get a confident proposal of something you dismissed last week.

Every token costs twice. Once in money, once in dilution. Claude API pricing covers the money side.

What to put in, what to leave out#

In: the standing rules for this work, the specific task, the material that bears on it, the decisions already made, the output shape you want.

Out: entire documents when a section will do, conversation turns that resolved to nothing, tool outputs already summarised, generic background the model already has.

That last one is worth emphasising. Explaining what an API is, or what SEO means, to a model that knows both, costs tokens and adds nothing. Spend the budget on what is specific to you.

Compaction, and why long sessions decay#

A session that runs for hours accumulates. Early turns stop mattering but keep occupying space, and eventually the window is mostly archaeology.

The fix is deliberate compaction: replace older turns with a summary and continue. The quality of that summary decides whether anything breaks.

A good compaction preserves:

• Decisions made and the reasoning that produced them
• Constraints discovered along the way
• What was tried and failed, so it is not retried
• Current state and the immediate next step

A bad one preserves topics discussed. The difference shows up ten minutes later when the model proposes an approach that was ruled out in hour one.

In Claude Code this is partly automatic, and it is still worth knowing what a summary should contain so you can correct it when it drops something load-bearing.

Where the context should live#

Not in a chat message you retype.

Standing project context belongs in a file the tool reads every session. CLAUDE.md is exactly this: conventions, commands, architecture, what not to touch. Written once, applied always.

Repeatable procedures belong in Claude Skills, which load when relevant rather than sitting in every window.

Wide exploration belongs in subagents, so the twenty files they read never enter your window at all. This is the clearest example of context engineering as architecture rather than as writing.

Live company knowledge belongs behind retrieval, not pasted in. RAG vs fine tuning covers that choice.

The tool output problem#

Agentic workflows create a specific pressure that ordinary chat does not: tool results pile up fast, and most of them stop being relevant within a few steps.

A search returns forty results and two mattered. A file was read in full and one function was the point. A command printed two hundred lines of build output that ended in success. All of it sits in the window, competing for attention with the actual task.

Three fixes, in order of how much they help:

Summarise at the boundary. Have the step that produced the output reduce it before it enters the main context. A subagent that returns six lines instead of twenty files is this pattern applied at scale.

Set output limits. Truncate long tool results deliberately, with a note saying they were truncated, rather than letting them consume the budget silently.

Drop what resolved. Once a search has led you to the file, the search results are archaeology. Remove them.

Teams that skip this find that their agent works well for twenty minutes and then starts making mistakes it was not making earlier. Nothing changed about the model; the signal-to-noise ratio in its window collapsed.

Diagnosing a context failure#

When output is wrong, check these before blaming the model:

1. Was the necessary information present? Half of all failures end here.
2. Was it findable? Present but buried in the middle of a long document is nearly the same as absent.
3. Was there contradictory material? Two versions of a policy in the window produces a coin flip.
4. Were the decisions included? Missing history produces relitigation.
5. Was the task at the end? Instructions followed by three pages of reference get half-forgotten.

Run that list before rewriting the prompt. It resolves more than rephrasing does.

The short version#

Assemble the window deliberately: rules first, reference next, task last. Retrieve what is relevant rather than attaching everything. Include the decisions, not only the facts. Compact long sessions on purpose, preserving decisions rather than topics. Move standing context into files and wide reading into subagents.

If you want this built into a workflow you use daily, how to use Claude Code covers the fundamentals and my Claude Code course covers the full setup.