The instinct that quietly makes agents worse
When an agent does something you didn't want, the reflex is immediate. You add a rule. "Never do X." "Always confirm before Y." "Do not write comments." It feels like control, and in the moment it usually works.
Do that for a few months and you end up somewhere strange. The agent has a page of rules, half of them written for a problem that no longer exists, several of them quietly contradicting each other. And the agent gets worse, not better, in ways that are hard to trace back to any single line you wrote.
We know this because we did it. So did the team that builds Claude Code.
What Anthropic found
There is a name for the thing we were all doing badly. Anthropic calls it context engineering, and it covers everything that reaches the model besides your actual message: the system prompt, the instruction files, the skills, the memory, the tool definitions. Your prompt is a small slice of what the agent is actually reading.
This week Thariq Shihipar, who works on Claude Code at Anthropic, published what his team learned rebuilding that context for the newest generation of Claude models. The headline is startling: they removed more than 80% of Claude Code's system prompt, with no measurable loss on their coding evaluations.
Not a trim. Most of it, gone, and the results held.
The reason is worth sitting with. Reading their own internal transcripts, they kept finding conflicting instructions arriving in a single request. The system prompt said one thing, a skill said something slightly different, the user asked for a third. Thariq's example is a system prompt that says "DO NOT add comments" colliding with guidance elsewhere to "leave documentation as appropriate." A capable model can usually work out what you actually meant. But it has to spend effort doing it, and that effort comes out of the work you asked for.
Their conclusion was not "write better rules." It was that many of those rules existed to stop older, weaker models from doing something dumb, and the newer models simply do not need the guardrail. What replaced a paragraph telling Claude never to write comments was a single line: write code that reads like the surrounding code.
That is the whole shift. Stop legislating. Give context and let judgement do the rest.
The part that matched our experience
Thariq frames the rest as a set of then-and-now pairs, old best practices that quietly became myths. A few of them landed uncomfortably close to home.
Examples constrain more than they teach. The old rule was to show an agent worked examples of every tool. It turns out that examples fence the agent into the shape of the example. The better investment is the tool itself: clear parameters, honest names, a design that makes the right usage obvious. If your tool needs three paragraphs of explanation, the tool is the problem.
Loading everything upfront is a tax on every single request. The temptation with any instruction file is to make it the one place that holds everything, on the theory that the agent will never find it otherwise. Modern agents are good at going and getting what they need. A short file that points to deeper ones beats a long file that carries all of it into every conversation, most of which will never need it.
Repeating yourself does not add emphasis. It adds noise, and something to conflict with later.
Rich references beat descriptions. An actual HTML mockup produces better results than a paragraph describing the design. A test suite is a better spec than a document about the spec. Give an agent the real artifact, in a language it already reads fluently, rather than your summary of it.
What we got wrong, specifically
Here is the one we paid for.
We had a theory that our agents were slowing down because they were carrying too many tool definitions into every turn. It was a reasonable theory, it matched the advice we had absorbed, and we built the fix. Then we measured it against real traffic and the effect was essentially zero. The tool definitions were a rounding error against the window we actually had.
The real cost was somewhere else entirely: what came back from the tools during a turn, and a loop the agent was getting stuck in. We reverted our clever fix and went and dealt with the actual problem.
The lesson was not about tools. It was that we had optimized from a belief instead of a measurement, and the belief came from advice that was true a generation of models ago. That is the trap in all of this. Best practices in AI have a shelf life measured in months, and nobody sends you a notice when yours expires.
What this means if you are building your own agent
If you maintain instructions for an agent, whether that is a CLAUDE.md, a system prompt, or a folder of internal guidance, the useful exercise is subtraction.
Go through it and ask, for each rule, whether it exists because the model genuinely cannot work this out, or because it got something wrong once in early 2026 and you patched it. Most instructions are the second kind. Delete those and see what actually breaks. Usually less than you fear.
Then keep what is left small and specific. Anthropic's guidance for repository instructions is a good template for any agent: briefly say what this thing is, then spend most of your words on the gotchas that are genuinely not discoverable. Skip the obvious. The agent can look. What it cannot know is that your team keeps every type in one file, or that the staging database lies about one particular field.
Anything longer than that should be something the agent goes and fetches when the moment calls for it, not something it carries everywhere. Anthropic shipped a /doctor command in Claude Code that will walk your instruction files and skills and tell you what to cut, which is a reasonable place to start if you would rather not do it by hand.
Why we think you should not have to do any of this
We find this genuinely interesting, and if you build agents for a living, it is worth an afternoon of your time.
But it is also exactly the kind of work we started Praxic to absorb. If you run a business and you want an agent handling your support queue or chasing your leads, none of this should ever reach you. You should not be auditing instructions for internal contradictions. You should not be reading model release notes to find out that the advice you followed six months ago is now making your agent worse.
That is our job. We keep up with it, we measure it against real usage rather than folklore, and we change what we built when the ground moves. You describe the work you want done, and it gets done.
The agents keep getting more capable. Most of what we build for them should keep getting simpler. That is a strange and very good problem to have.
If you want an agent doing real work in your business without any of this landing on your desk, join the waitlist. We would love to build your first one with you.
Branson