Key takeaways
- Context engineering is the new prompt engineering. Prompt engineering crafts one message; context engineering curates the whole context window across an entire agent session.
- The levers are rules files, skills, memory, MCP, and the context window itself. Each one decides what the agent knows — and what it’s distracted by.
- When an agent ignores your instructions, the cause is usually mechanical: not loaded, drowned out, vaguely described, or contradicted by a bloated file.
- In practice, good context engineering is good rules files kept in sync — undone the moment your standards scatter across tools and start drifting.
Context engineering vs prompt engineering
For two years the craft was prompt engineering: finding the wording, the examples, and the system message that coaxed a good answer out of a single model call. It still matters. But it assumes a world where you send one message and read one reply.
Coding agents don’t live in that world. A Claude Code or Cursor session runs for dozens of turns, reads files, runs commands, calls tools, and accumulates history. By turn fifteen, the original prompt is a rounding error in a context window stuffed with rules files, file contents, diffs, tool output, and memory. The thing that determines whether the agent does the right thing isn’t the last message — it’s everything that’s currently in the window.
That’s why the field has been quietly renaming the discipline. Context engineeringis the practice of curating the entire context window — rules, memory, files, tools, history — so the agent has exactly what it needs and nothing it doesn’t. Prompt engineering is now a subset: the agent still consumes a prompt, but the prompt is one input among many.
| Prompt engineering | Context engineering | |
|---|---|---|
| Unit of work | One message | The whole context window |
| Time horizon | A single turn | An entire agent session |
| What you control | Wording, examples, format | Rules, memory, files, tools, what to exclude |
| Main failure | Vague or under-specified ask | Wrong, missing, or bloated context |
The reframing isn’t cosmetic. It changes where you spend effort: less time wordsmithing a single instruction, more time deciding which instructions are always present, which load on demand, and which data the agent can reach.
The levers of context engineering
Context isn’t one thing you tune — it’s five distinct levers, each loading at a different time and costing a different amount. Pull them deliberately and the window stays sharp; pull them carelessly and you get an agent that’s confused, expensive, or both.
| Lever | What it is | When it loads |
|---|---|---|
| Rules / instructions | .cursor/rules, CLAUDE.md, AGENTS.md, copilot-instructions.md | Always on (or path-scoped) |
| Skills | On-demand procedures in a SKILL.md folder | When the description matches |
| Memory | Always-on facts vs auto-generated memories | Every turn / when recalled |
| MCP | Connectivity to external data and tools | On tool call |
| Context window | The token budget everything competes for | The constraint on all of the above |
Rules and instruction files
Rules files are the always-on layer: the conventions, constraints, and non-negotiables the agent should respect on every turn. Each tool has its own format — Cursor’s .cursor/rules with glob-scoped activation, Claude Code’s CLAUDE.md, the cross-tool AGENTS.md standard, and Copilot’s copilot-instructions.md. They differ on scope, activation, and portability, which is exactly why running more than one tool gets painful (full format-by-format comparison here).
The context-engineering discipline for rules files is restraint. Because they’re always loaded, every line is a recurring tax on the window and a chance to contradict something else. Keep them to facts and hard constraints; push anything that reads like a step-by-step procedure out into a skill.
Skills: on-demand procedures
Skills are the answer to “I have a long procedure but I don’t want it eating my context window every turn.” A skill is a folder with a SKILL.md that loads only when its description matches the request — see the complete guide to Claude Code skills. The mechanism that makes them context-friendly is progressive disclosure: only the ~100-token description is always in the window, the body loads when triggered, and bundled reference files or scripts cost nothing until the moment they’re used.
That’s the whole game in miniature. You can carry dozens of detailed procedures and keep the always-on footprint tiny — the opposite of stuffing every procedure into an always-on rules file and watching the signal degrade.
Memory: facts vs auto-generated
Memory is the persistent layer, and it comes in two flavors that behave very differently. Always-on memory — a CLAUDE.md at the repo root — is loaded every turn and should hold only durable facts: the stack, the architecture, the rules that never change. Auto-generated memories— Cursor generates these from your chats per project — are recalled situationally. The engineering decision is what deserves a permanent slot in the window versus what can be summoned on demand. When in doubt, a fact that’s true in every session belongs in always-on memory; a fact that’s true sometimes does not.
MCP: connectivity
MCP (the Model Context Protocol) is how the agent reaches data and tools it doesn’t already have — a database, an issue tracker, your docs, an internal API. Anthropic’s framing is the clean dividing line: MCP is for connectivity, skills are for procedural knowledge. From a context-engineering angle MCP matters because it lets you pull data on demand instead of pasting it into the window up front. A tool that fetches the right three rows beats a prompt that inlines the whole table and hopes the relevant rows survive.
The context window itself
The last lever is the budget every other lever spends. A 200k-token window sounds infinite until you’ve loaded a rules file, a memory file, ten source files, and a few rounds of tool output — and then watched quality sag as the useful signal gets buried. Context engineering is, at bottom, deciding what earns a place in that budget. Include what changes the answer; exclude what merely could be relevant. More context is not more help past the point where the important tokens stop standing out.
Why your agent ignores your instructions
“Why does my AI agent ignore my instructions?” is the most common complaint in AI pair programming, and it’s almost never the model being stubborn. It’s a context-engineering bug. Four causes cover nearly all of them.
Cause 1 — it was never loaded
The instructions aren’t in the window at all. Wrong filename, wrong path, wrong tool. Copilot’s repo-wide instructions only work at the exact path .github/copilot-instructions.md; a plain .mddropped in Cursor’s rules folder is ignored because it has no frontmatter; Claude Code doesn’t read AGENTS.md natively. Fix: confirm the file is actually loaded for your tool before blaming the model.
Cause 2 — too much always-on context
The rule is loaded, but it’s one line in a 600-line always-on file, competing with everything else for attention. As the window fills, individual instructions stop standing out. Fix: shrink the always-on layer. Move procedures into skills, keep rules files to facts and hard constraints, and let progressive disclosure carry the detail.
Cause 3 — vague descriptions
A skill or rule that should trigger doesn’t, because its description is too generic to match the request. “Helps with code” matches nothing in particular. Auto-invocation works by matching the request against descriptions. Fix: write specific, third-person descriptions that say what the rule does and when to use it, including the words a user would actually say.
Cause 4 — contradictions in a bloated file
A rules file that grew for a year now says “always use tabs” on line 40 and “use two-space indentation” on line 380. The agent can only obey one, and you can’t predict which. Fix: treat the rules file like code — review it, delete dead rules, and resolve conflicts instead of stacking new lines on top of old ones.
Notice the pattern: none of these are fixed by a better prompt. They’re fixed by engineering the context — what loads, how much, how it’s described, and whether it’s internally consistent.
Context engineering in practice = good rules files, kept in sync
Here’s the part the term “context engineering” tends to obscure. It sounds like a sophisticated, model-level craft. In day-to-day practice, for a working engineer, it collapses into something far more mundane: your rules and skills files are good, and they stay in sync across every tool you use.
That second clause is where most teams quietly lose. You can write a beautifully lean CLAUDE.md, factor your procedures into crisp skills, and write trigger descriptions a model can’t miss — and then undo all of it the moment the same standards have to live in .cursor/rules, copilot-instructions.md, and a teammate’s machine too. The files drift. A fix you made in one tool after a painful bug never reaches the others. Six months later the same mistake comes back through a different agent, because its context never got the memo.
The real failure mode
Drift is a context-engineering failure with a delay on it. The bug isn’t that any one file is wrong — it’s that the files disagree, and the agent you happen to be using loads the stale one. There’s no npm audit for prompts and no diff that tells you which file is authoritative.
The durable fix is structural: keep one canonical library of rules and skills, version it once, and compile it out to each tool’s native format so every agent sees the same context. That’s the approach Skillwright is built around — author your rules and skills in one place, deploy them to Cursor, Claude Code, Windsurf, and Copilot, and surface drift instead of discovering it in a regression. For the full playbook, see how to manage AI coding rules across tools and the comparison of every rules-file format. If you’d rather start from something proven, the templates library has MIT-licensed rules and skills you can adopt today.
A context engineering checklist
Run this against any agent setup. If you can’t check a box, you have a concrete thing to fix.
- Confirm what’s actually loaded. Verify your rules file is at the exact path your tool reads, for every tool you run.
- Keep the always-on layer lean. Rules and memory hold durable facts and hard constraints — nothing that reads like a procedure.
- Push procedures into skills. Anything multi-step belongs in an on-demand
SKILL.md, not an always-on file. - Write descriptions that trigger. Specific, third-person, with the words a user would actually say.
- Pull data, don’t paste it. Connect external sources via MCP instead of inlining large blobs into the window.
- Hunt for contradictions. Review rules files like code; delete dead rules and resolve conflicts.
- Budget the window.Include what changes the answer; exclude what’s merely plausibly relevant.
- Keep one canonical source. Author rules and skills once and compile to every tool so contexts never drift.
Context engineering isn’t a new model trick — it’s the engineering discipline of curating what your agent sees. Get the levers right, keep the window honest, and keep your rules in sync, and the agent stops ignoring you. For the operational side of that last point, Skillwrightexists precisely so good context engineering doesn’t decay into copy-paste maintenance across five tools.
Frequently asked questions
What is context engineering?
Context engineering is the practice of curating everything an AI coding agent sees in its context window — rules files, memory, the files it reads, tool outputs, and conversation history — so the model has exactly what it needs to do the task and nothing that distracts it. It's the agentic successor to prompt engineering: you're designing the whole context, not just one message.
What's the difference between context engineering and prompt engineering?
Prompt engineering is crafting one good message to get a good response. Context engineering is curating the entire context window across a whole agent session: which rules load, what memory persists, which files and tool results are present, and what gets excluded. Prompt engineering is a subset — the agent still consumes a prompt — but for coding agents that run for many turns, the prompt is a small part of what determines behavior.
Why does my AI coding agent ignore my rules?
Almost always one of four causes: the rules file isn't actually loaded (wrong path or filename for that tool), too much always-on context is drowning out the signal, the rule or skill description is too vague to trigger, or a bloated rules file contradicts itself. Verify the file is loaded, trim it, make descriptions specific, and remove contradictions.
How do I manage the context window for coding agents?
Treat the context window as a budget. Put always-true facts in always-on memory (CLAUDE.md), move multi-step procedures into on-demand skills that load only when triggered, lean on progressive disclosure so reference material costs nothing until needed, and connect external data through MCP instead of pasting it inline. Audit what's actually loaded and cut anything that isn't earning its tokens.
What are the best practices for AI coding agents?
Keep always-on context lean and factual, push procedures into skills, write specific trigger descriptions, connect data via MCP rather than inlining it, remove contradictions, and keep one canonical source of rules so the same standards reach every tool. Good context engineering is mostly good rules files kept in sync, not clever prompts.