An agent hallucinates a function signature, forgets a decision from three turns ago, or calls the wrong tool out of a dozen similar ones. The instinct is to rewrite the prompt. That rarely works, because the prompt was rarely the problem. The real issue is what the agent had to work with: which files it could see, how much of the conversation history survived, which tools were on offer, and how much of the context window was already burned on noise before the model made its decision.
That is context engineering, and it has become an increasingly decisive discipline. Prompt engineering asks how to phrase an instruction. Context engineering asks what the agent knows, sees, and remembers at the moment it acts, covering retrieval, memory, token budget, tool scoping, and state across turns. Anthropic’s applied research team defines it plainly: context engineering is “the set of strategies for curating and maintaining the optimal set of tokens during LLM inference,” a broader and more architectural job than crafting a good instruction (Anthropic, Effective context engineering for AI agents).
This matters to anyone building or operating agentic systems, not just prompt writers. A well-worded system prompt cannot compensate for an agent that has the wrong file loaded, a tool set it cannot distinguish between, or a context window clogged with a thousand lines of dead conversation history. This piece covers what context engineering involves day to day, where the Model Context Protocol (MCP) fits, and how persistent context files like CLAUDE.md operationalise the discipline for coding agents specifically, using Claude Code, built on Claude, powered by Anthropic, as a worked example throughout.
Why prompt engineering stopped being the whole job
Prompt engineering treats the interaction with an LLM as a single, self-contained exchange: get the wording right, and the output follows. That model holds up for one-shot completions. It breaks down for agents, which operate over many turns, call tools, accumulate history, and make decisions based on whatever state happens to be in the context window at that point in the run.
BigDataBoutique’s engineering team frames the shift directly: teams are moving from prompt engineering to context engineering because “most quality failures trace back not to model capability but to poor context management, the model had the wrong information, too much information, or stale information when it needed to make a decision”. The failure mode is architectural, not linguistic. No amount of prompt polish fixes a context window that is stale, bloated, or missing the one fact the agent needed.
This does not make prompt engineering obsolete. Anthropic’s own framing is that the two are complementary rather than competing: prompt engineering shapes how you instruct the model, and context engineering shapes what the model has to work with when that instruction runs. Get the context wrong, and the best-worded prompt in the world is answering the wrong question.
What context engineering actually involves
Context engineering is not a single technique. It is a set of ongoing decisions about what enters the context window, what stays, and what gets discarded. In practice, five areas dominate the day-to-day work.
Retrieval design
The naive approach to giving an agent knowledge is to load everything relevant upfront: every file, every document, every prior message. This scales badly and degrades the model’s ability to attend to what actually matters, a phenomenon known as ‘context rot’, a term from Chroma’s 2025 research on long-context degradation, and discussed in Anthropic’s context-engineering guidance (Anthropic, Effective context engineering for AI agents).
The alternative is “just in time” retrieval: the agent keeps lightweight references (file paths, identifiers, query hooks) and pulls the actual content only when it needs it, via a tool call, rather than pre-loading it. This mirrors how a competent engineer works through an unfamiliar codebase: not by reading every file first, but by following references as questions come up. For latency-sensitive cases, a hybrid works better: retrieve the most likely-needed data upfront, and let the agent explore further only if that is not enough.
Token budget management
Context is a finite, shared resource, and every token spent on irrelevant history is a token unavailable for the task at hand. Anthropic’s guidance is to “find the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome,” rather than treating a large context window as permission to include everything.
This applies to system prompts as much as retrieved content. A system prompt should sit at the “right altitude”: specific enough to steer behaviour, but not so prescriptive that it hardcodes brittle logic for cases the agent will meet in slightly different forms. Vague instructions fail because they assume shared context the model doesn’t have; over-specified ones fail because they cannot anticipate every variation.
Tool scoping
Every tool exposed to an agent is a decision point it has to reason about before it reasons about the task. A dozen overlapping tools with unclear boundaries do not add capability, they add ambiguity.
Anthropic’s test for whether a tool set is well scoped: “If a human engineer can’t definitively say which tool should be used in a given situation, an AI agent can’t be expected to do better.”
Tools should be self-contained, robust to malformed input, and unambiguous about when to use them. Cutting a tool set down is usually a better lever for reliability than adding a smarter prompt around a bloated one.
Memory and state across turns
Agentic work often spans more turns than fit comfortably in a single context window. Three techniques handle this without losing what matters:
- Compaction, summarising the conversation so far and re-initiating the session with the distilled summary in place of the full history.
- Structured note-taking, where the agent writes persistent external notes (a
NOTES.md-style file) that survive a context reset, so state lives outside the window rather than only inside it. - Sub-agent delegation, where a specialised agent handles a focused sub-task in its own context and reports back a condensed summary, rather than the parent agent absorbing every intermediate step.
Each trades some detail for durability. The choice depends on whether the detail being discarded was load-bearing for later decisions or just process noise.
Avoiding context pollution
Not everything that happens in a session deserves to persist. Tool outputs read deep in a session’s history are often redundant by the time a later decision is made; once the agent has acted on that information, the raw output is overhead rather than signal. One of the more reliable techniques is simply clearing old tool results once they have served their purpose, rather than letting the full output of every past command accumulate indefinitely.
Retrieval-augmented generation is one technique inside a bigger discipline
RAG and context engineering are often used interchangeably, and that conflation causes real production problems. RAG is a specific mechanism: given a query, fetch text chunks that resemble it from an external corpus and inject them into the context window before generation. It answers one question well: which documents look similar to this query?
Context engineering asks a harder set of questions on top of that: which sources are authoritative when two disagree, is this data still current or was it superseded, who is allowed to see it, and what does the combination of these sources mean for the specific task the agent is doing right now. As one analysis puts it, RAG “handles the mechanical work at the retrieval layer,” while context engineering additionally covers “memory management, data quality gates, policy enforcement, and agent orchestration” (Context Engineering vs. RAG: Key Differences and Use Cases).
RAG alone is sufficient for simple question-answering over a static, trusted corpus with no compliance requirements. It is not sufficient for an agent operating against live data, maintaining memory across a long task, coordinating with other agents, or working somewhere an audit trail of what the agent knew and when matters. In those cases, retrieval is one component in a larger system that also has to manage memory, enforce access policy, and resolve conflicting sources.
MCP: a standard interface for bringing context and tools to an agent
Every one of the practices above depends on the agent being able to reach external systems: a codebase, a ticketing tool, a database, a design file. Before November 2024, that meant a custom integration per data source per agent framework, the N×M problem Anthropic identified when it introduced the Model Context Protocol: every new source needs its own bespoke connector for every tool that wants to use it (Anthropic, Introducing the Model Context Protocol).
MCP is an open standard that replaces that N×M problem with a common interface. An MCP server exposes three kinds of primitives to a connected agent: tools (functions the agent can call), resources (structured, file-like data the agent can read), and prompts (predefined templates for common interactions). An agent that speaks MCP can connect to any compliant server, whether that server fronts Git, Postgres, Slack, Google Drive, or an internal system, without a bespoke integration for each one (Anthropic, Model Context Protocol documentation).
Adoption since the November 2024 launch has been fast: thousands of community-built servers exist, SDKs are available for all major languages, and the format is now treated as a de facto standard across the agent tooling ecosystem, supported by Claude, and by editors and IDEs including Visual Studio Code and Cursor.
For context engineering specifically, MCP matters because it standardises two of the five areas covered above. Retrieval design becomes a matter of choosing which MCP servers to connect rather than writing custom fetch logic per source. Tool scoping becomes a matter of choosing which MCP servers and which of their tools to expose to a given agent, rather than building and maintaining a bespoke tool interface. It does not replace the judgement calls (what to retrieve, when, and what to expose), but it removes a large amount of the plumbing that used to stand between an agent and its context.
CLAUDE.md: context engineering for coding agents, made durable and versioned
Coding agents face a specific version of the context problem: a codebase carries conventions, constraints, and history that are not recoverable from the code alone. Why does this module call bar() instead of foo()? Which test runner does the team actually use? What is off-limits without a review? An agent without answers to these either asks constantly or guesses, and guessing on a real codebase produces plausible-looking code that violates conventions the team cares about.
Claude Code addresses this with CLAUDE.md, a file the agent reads automatically at the start of every session in a given repository (“Using CLAUDE.md files,” Claude by Anthropic). This is context engineering applied directly to the memory and retrieval problem: rather than retrieving project conventions ad hoc or restating them in every prompt, the team encodes them once, in a file the agent loads automatically and the team maintains under version control.
What makes CLAUDE.md an example of context engineering discipline rather than just documentation is what Anthropic’s own guidance says to leave out as much as what to include. The file works because of token budget management applied to a specific, recurring context need:
- Include: bash commands the agent cannot guess (how to run one test, not the whole suite), code style that deviates from language defaults, repository etiquette like branch naming, architectural decisions specific to the project, and known gotchas.
- Exclude: anything the agent can already infer from reading the code, detailed API documentation that belongs in a link rather than inline text, information that changes often, and standard language conventions the model already knows.
Anthropic is explicit that oversized CLAUDE.md files backfire: “Bloated CLAUDE.md files cause Claude to ignore your actual instructions” (Claude Code, Best practices for Claude Code). This is context rot applied to a persistent file rather than a single conversation: past a certain size, the highest-signal instructions get lost in the noise of lower-value ones, and the fix is the same discipline used for any other part of the context window, prune ruthlessly, and ask of every line whether removing it would actually cause a mistake.
Composition with Claude
CLAUDE.md also supports composition rather than one giant file: it can import other files with @path/to/file syntax, it resolves per directory in a monorepo so a subproject can add its own conventions on top of the root file, and domain knowledge that is only sometimes relevant belongs in a Skill rather than CLAUDE.md, so it loads on demand instead of consuming budget on every single session regardless of whether it’s needed. That is tool and context scoping again, this time applied to which instructions load automatically versus which load only when the task calls for them.
The wider ecosystem has converged on the same pattern under a different name. AGENTS.md, an open format now used across more than 60,000 open-source projects, is stewarded by the Agentic AI Foundation (AAIF) under the Linux Foundation, a body Anthropic co-founded alongside OpenAI and Block and to which it contributed MCP as a founding project alongside AGENTS.md (Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation). AGENTS.md does for OpenAI Codex, Google’s Jules, Cursor, Aider, and other coding agents what CLAUDE.md does for Claude Code: a predictable, versioned location for setup commands, testing workflows, and coding conventions that a codebase’s README was never designed to carry (AGENTS.md; InfoQ, AGENTS.md Emerges as Open Standard for AI Coding Agents). The convergence across competing tools on the same shape of solution, formalised enough that Anthropic, OpenAI, and Block placed their own versions of this pattern under one neutral foundation, is itself evidence that persistent, versioned context files are solving a real engineering problem, not a vendor-specific quirk.
Why this is what separates a toy demo from a working agent on a real codebase
The gap between a coding agent that impresses on a greenfield script and one that holds up on a large, messy, years-old codebase is almost entirely a context engineering gap, not a model capability gap.
On a toy example, there is barely any context to manage. The whole codebase might fit in the window, there is no legacy convention to violate, and a single clear prompt is close to sufficient on its own. On a real codebase, none of that holds. The agent needs to know which of several similar-looking utility functions is the one the team actually wants used, which parts of the code are load-bearing and untouchable versus safe to refactor, how to run just the relevant test rather than a 40-minute full suite, and what to do when its own context starts filling with dead exploration.
This is why Claude Code’s own best-practice guidance leads with context management as the primary constraint, ahead of prompting technique: “Claude’s context window fills up fast, and performance degrades as it fills. The context window is the most important resource to manage” (Claude Code, Best practices for Claude Code). The practical techniques that follow from that constraint are context engineering by another name: using subagents to keep investigation out of the main context, running /clear between unrelated tasks rather than letting irrelevant history accumulate, using MCP servers to reach external systems (a database, a design tool, an issue tracker) instead of copy-pasting content into the prompt, and treating CLAUDE.md as a small, pruned, high-signal file rather than an exhaustive one.
None of that is prompt engineering. It is deciding what the agent is allowed to see, when, and for how long, which is precisely the definition of context engineering. The teams that get reliable results from coding agents on real production codebases are, without necessarily naming it, doing this work deliberately rather than leaving it to chance.
How Zartis helps
Context engineering is now an engineering discipline in its own right, not a writing skill, and most organisations adopting agentic coding tools have not yet built the practice around it. That shows up as agents that work well in a demo and inconsistently in production: no retrieval strategy beyond “load everything,” tool sets that overlap and confuse the agent, no versioned project context file, and no plan for what happens to reliability as a codebase and its history grow.
We work with engineering teams on both sides of that gap: advising on where context engineering discipline is missing (retrieval design, tool scoping, memory strategy, and context file structure) and delivering the implementation, from writing and maintaining CLAUDE.md files that encode real project conventions, to standing up MCP servers that connect agents to a team’s actual systems, to building the guardrails that keep agentic coding reliable as it scales past a single repository. This is advisory and delivery together: Zartis does not hand over a recommendations document and leave, and it does not staff a body of contractors without an underlying engineering point of view. Both halves are done by the same team that understands the codebase.
As a Preferred Services Partner in the Claude Partner Network, Zartis works directly with Claude, powered by Anthropic, and Claude Code as part of this practice, including MCP server design and integration, CLAUDE.md structure for real production codebases, and training engineering teams to treat context, not just prompts, as the thing they are engineering. If your teams are already using agentic coding tools and finding the results inconsistent between projects, that inconsistency is very likely a context engineering gap, and it is a solvable one.
Sources
- Anthropic, Effective context engineering for AI agents
- Anthropic, Introducing the Model Context Protocol
- Anthropic, Model Context Protocol documentation
- Claude Code, Best practices for Claude Code
- Claude by Anthropic, Using CLAUDE.md files: Customizing Claude Code for your codebase
- Neo4j, Why AI teams are moving from prompt engineering to context engineering
- Roadie, Why Conflating RAG with Context Engineering Costs You in Production
- AGENTS.md, official site
- InfoQ, AGENTS.md Emerges as Open Standard for AI Coding Agents
- Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation