Context Engineering vs. Prompt Engineering: Why Fewer Rules Build Better AI Agents

Context engineering is the discipline of giving an AI model exactly the information, tools and instructions it needs to make a good decision at each step, and nothing more. Prompt engineering asks how to phrase an instruction. Context engineering asks what should end up in the context window at all: the system prompt, tool descriptions, documents, memory and conversation history. For AI agents that work autonomously across many steps, this is what decides the quality of the result.

Anthropic showed how seriously this is now taken in July 2026. The team behind Claude Code cut more than 80% of the system prompt for the Claude 5 generation of models, with no measurable loss on its coding evaluations, according to the company. In this article you will learn:

• what context engineering is and how it differs from prompt engineering,
• what Anthropic removed from Claude Code and why,
• why more rules in a prompt often make agents worse,
• which building blocks make up an AI agent’s context,
• six rules for context engineering in a business, with a check for your own system prompt.

What is context engineering?

The term took hold in June 2025. Shopify CEO Tobi Lütke proposed it as a better name for what teams actually do when they build AI applications, and Andrej Karpathy endorsed it a few days later, describing it, in essence, as the art of filling the context window with just the right information for the next step (Simon Willison).

Anthropic defined it in September 2025 as the set of strategies for curating and maintaining the optimal set of tokens a model sees while it works. The goal is the smallest set of high-signal tokens that maximises the likelihood of the desired outcome (Anthropic).

The difference from a single prompt: an agent that checks an invoice, works a support ticket or builds a report calls tools, reads files and collects intermediate results. Its context grows with every step. Context engineering is therefore not a one-off wording exercise but an ongoing decision about what the model needs to see right now.

Context engineering vs. prompt engineering

Prompt engineering has not become obsolete. It is one part of context engineering. But the weight has shifted:

For simple tasks in a chat, good prompting is enough. As soon as an agent uses tools on its own and works across several steps, the prompt is only a small part of what the model sees.

What Anthropic removed from Claude Code

On 24 July 2026, Thariq Shihipar from the Claude Code team described how Anthropic rebuilt the context of its own coding agent (Claude Blog). The core message: the team had been over-constraining Claude Code, both in the system prompt and in its CLAUDE.md files and skills. For models such as Claude Opus 5 and Claude Fable 5, more than 80% of the system prompt was removed.

One example from the post shows what that looks like. The system prompt used to contain a whole group of rules on code comments: no comments by default, no multi-line docstrings, no planning documents unless asked. Today there is essentially one sentence: write code that reads like the surrounding code, matching its comment density, naming and idiom.

Anthropic sums up the rebuild in six shifts:

For context: the 80% refers to Claude Code’s system prompt for the newest models, not to all instructions. Anthropic has published neither the old prompt nor the evaluation results, so the figure cannot be checked independently, and the change was debated in developer forums. The direction matches what we see in our own agent projects, though: many rules that were necessary a year ago make results worse with newer models.

Why more rules make agents worse

The old prompt engineering reflex goes like this: an error shows up, so a rule gets added. A few months later an agent has a system prompt with dozens of rules, many in capital letters, some duplicated, some contradictory. That has three consequences.

Context is a budget. Language models spread their attention across all tokens in the context. Anthropic calls this an attention budget that shrinks with every additional token. Researchers at Chroma tested 18 current models, including GPT-4.1, Claude 4 and Gemini 2.5, and showed that with the same task, results become less reliable as input length grows (Chroma Research, July 2025). The term for this is context rot.

Rules contradict each other. Anthropic describes cases where the system prompt says “leave documentation as appropriate”, a skill says “DO NOT add comments” and the user wants something else entirely. The model usually resolves the conflict correctly, but it spends reasoning on it that is missing elsewhere.

Rules don’t fit every case. A rule is a trade-off made once for all situations. “Never answer with more than five sentences” helps with the standard ticket and hurts with the complicated complaint. A model with good judgement makes that trade-off better case by case, as long as it knows the goal and the context.

That does not mean rules disappear. It means they belong in the right place.

The building blocks of an AI agent’s context

What an agent sees at each step is assembled from several layers. Each has its own purpose and its typical failure:

Through the Model Context Protocol (MCP), more systems are often added today, each with its own tools and descriptions. The more systems an agent can reach, the more it matters which tool definitions it really needs to see straight away. That is why Claude Code loads some tools only when the agent searches for them.

Six rules for context engineering in a business

1. Goal and context instead of a rulebook

Start the system prompt with its purpose: what is the agent for, who does it work for, what does a good result look like? A customer service agent that knows your customers are trade businesses and that invoice queries are usually urgent does not need ten rules on tone. Where a rule stays, a short reason helps. With the why, the model can apply the rule to cases you did not anticipate.

2. Hard limits belong in code and permissions

“Never delete records” in a prompt is a wish, not a safeguard. What must not happen under any circumstances belongs in the technology: the agent only gets read access, payments require human approval, and calculations run in deterministic code rather than in the language model. In the AI pipeline for RMEP’s portfolio reporting, a fixed QA gate with sum and consistency checks decides whether a report goes out, not an instruction in the prompt. More on this in our article on AI security for businesses.

3. Cut tools cleanly

A tool with clear parameters explains itself. Instead of explaining in the description which status values are allowed, define them as a fixed set. Instead of three similar search tools, build one with a filter parameter. Anthropic offers a simple test: if a human engineer cannot say definitively which tool to use in a given situation, the agent cannot either. More on tool calling and connecting your own systems in our guide to the Model Context Protocol.

4. Load knowledge on demand

Instead of copying the whole manual into the prompt, give the agent a way to find the right part: a search over the documentation, a skill with specialist knowledge, a pointer to the right file. Anthropic calls this progressive disclosure. At RMEP, the checks for completeness, consistency and valuation live in separate agent skills instead of one long master instruction. How to make knowledge retrievable is covered in building a RAG system.

5. Keep the context clean

Long-running agents accumulate ballast: tool outputs, discarded drafts, old error messages. Three techniques help. Summarise when the context fills up. Store notes outside the context window and read them back when needed. And hand sub-tasks to sub-agents that work in a fresh context and return only a short summary. This is the idea behind a multi-agent system.

6. Measure instead of guessing

Whether a removed rule is missed is not something gut feeling can tell you. A test set of real cases can. Build 30 to 100 typical and difficult cases with expected results and run every prompt change against them. That is an evaluation on a small scale, and it is what lets you cut boldly.

How overloaded is your system prompt?

Model upgrades: let your prompts age with them

One point is often overlooked: prompts written for an older model do not automatically suit the new one. Many rules in existing agents compensate for weaknesses the current model no longer has. Swapping only the model version means carrying the old crutches along.

Plan a short context check with every model upgrade:

1. Look at the full context: what does the agent really load at each step?
2. Mark rules that only existed to prevent an earlier failure.
3. Remove those rules on a trial basis and run the test set.
4. Keep what measurably helps and delete the rest.

For Claude Code, Anthropic now ships the claude doctor command, also available as /doctor, which checks CLAUDE.md files and skills for redundant or conflicting instructions. For your own agents outside Claude Code this remains manual work, but it pays off: a shorter context is also cheaper, because each request uses fewer tokens. How to cut costs further through model choice is covered in our article on the advisor and orchestrator patterns.

How we approach it at TAISC

We build AI agents and automations for mid-sized companies, and we run them too. Context engineering is not a separate project phase for us but part of every iteration. We start with a short system prompt that states the goal and context. New rules are only added when a test case calls for them, and they come out again when a new model makes them redundant. Hard limits are set through permissions, approvals and deterministic checks.

With Logify, an AI system for log file analysis in IT support, the agent retrieves the relevant passages from around 500 MB of technical documentation via RAG instead of sending everything along, and returns its results in a fixed, validated format. At RMEP we spread the domain knowledge across individual skills and run all calculations in code.

At TAISC in Karlsruhe, Germany, we support companies from their first agent through to operations, including as forward deployed engineers working directly in the team. You can find the ways we work together under Services.

Frequently asked questions about context engineering

What is context engineering?

Context engineering is the deliberate selection and maintenance of all the information an AI model sees at a given step: the system prompt, tool descriptions, retrieved knowledge, memory and conversation history. The goal is the smallest set of relevant information with which the model solves the task reliably.

What is the difference between context engineering and prompt engineering?

Prompt engineering is about how an instruction is phrased. Context engineering covers everything that enters the context window and is decided again at every step of an agent. Prompt engineering is therefore a part of context engineering.

Is prompt engineering still relevant?

Yes, but differently. Wording tricks and capital letters do little with current models. What still matters is a clear goal, enough context, a defined output format and above all tests with real cases that show whether a prompt holds up in daily use.

What is a system prompt?

The system prompt is the base instruction an AI agent receives with every request, before the actual user question. It sets the role, goal and boundaries. Because it runs with every step, every unnecessary sentence in it affects both quality and cost.

What is context rot?

Context rot describes the observation that language models become less reliable as context length grows, even when the task stays the same. A Chroma study showed this for 18 models in July 2025. The lesson: a large context window is no reason to fill it.

Why did Anthropic shorten the Claude Code system prompt?

According to Anthropic, Claude Code was over-constrained. Many rules dated from weaker models, some contradicted each other and they tended to hold the newer models back. For Claude Opus 5 and Claude Fable 5, more than 80 percent of the system prompt was removed, with no measurable loss on internal coding evaluations, according to Anthropic.

How long should a system prompt be?

As short as possible, as long as necessary. There is no fixed number. A good rule of thumb: everything needed on every request belongs in it. Everything only relevant in specific cases should be loaded on demand, for example through skills, tool descriptions or retrieval from a knowledge base.

Conclusion

The best AI agents do not have the longest prompts, they have the most fitting context. With current models, the work shifts from writing rules to designing tools, knowledge access and checks. Anthropic demonstrated this with its rebuild of Claude Code: fewer rules, more judgement, knowledge only when needed, and hard limits in the technology rather than in the text.

For businesses this means taking a fresh look at the prompts of existing agents, especially after a model upgrade. A lot of it can go. Want to know where your agents are carrying ballast, or how to set up your first agent cleanly? Book a no-obligation initial call.