From writing good prompts to designing the context window
What you put in front of the model now matters more than what you ask it
The next step after prompt engineering — you design not a single question, but everything the model sees
| Lens | Prompt engineering | Context engineering |
|---|---|---|
| Object | Polishing a single prompt | Designing everything that goes in the window |
| Scope | Instructions, examples, role | Instructions + retrieval + tool output + history + memory |
| Core question | "How do I ask?" | "What goes in, what stays out, when do I clear it?" |
| Main enemy | Vague instructions | Over-stuffed context · context rot |
The more tokens you stuff in, the worse the model recalls the information it needs
As context grows, the model's ability to pull out exactly the information it needs declines — especially for facts buried in the middle (lost in the middle). "Throw it all in, just in case" cuts accuracy and only inflates cost and latency. Window capacity is a ceiling, not a target.
Include enough of what the answer truly needs, and shed everything beyond that. Put critical instructions where the model attends most — the start or the end of the window. It's the same principle as a trustworthy RAG that "judges whether the context is sufficient and abstains when it isn't."
The standing project context you hand an agent — structure is quality
CLAUDE.md), but the role is the same — "a one-page briefing you hand a colleague seeing this project for the first time."
Let the model orient first. Purpose, domain, primary users. It doesn't need to be long.
Tell it "where things are" and it won't rummage through the wrong files. Key paths, not the whole tree.
Codify "write like the surrounding code." Don't make the model guess your team's habits.
The starting point for the model verifying its own code. State the framework, the run scope, and expectations.
The highest-ROI item (Anthropic). Write down the commands the model used to guess, and it'll run build/test/lint on its own, forming a self-verification loop. Fill this in first.
Spell out the model's recurring mistakes ("don't use this library," "don't touch this directory"). Preventing up front is cheaper than correcting after.
Keeping the window clean across long tasks and long conversations
As a conversation grows, don't keep old turns verbatim — replace them with a summary of just the essentials. Keep "what we've decided and how far we've gotten" as a compacted record, and you shrink thousands of tokens to hundreds while preserving context. A staple of long agent sessions.
Search results, file dumps, logs — tool output you use once and no longer need is the main thing eating your window. Once you've extracted the conclusion, clear the raw output and keep only the summary. It's the fastest way to reclaim tokens.
Facts, decisions, and preferences you don't need to carry every turn belong in storage outside the window (a file, DB, or memory tool), fetched only when needed. The window is the workbench; memory is the drawer. The longer the task, the more this separation matters.
The most common ways to wreck your context
Cramming everything into one file on the theory that "more is better." The instructions that matter get buried, and you burn tokens on every request.
Attaching every doc that might be relevant. Context rot drops accuracy and only raises cost.
Skipping the highest-ROI item. The model keeps guessing build/test commands and gets them wrong.
Never clearing search results or file dumps you've already used, so the window slowly clogs.
Forgetting a model reads it, you fill it with decoration, duplication, and context-free acronyms. The model misses the intent.