Why Your Agent Got Worse After the Model Got Better

Every model upgrade is a migration. Treat it like one and your agents keep working; treat it like a free lunch and they quietly rot.

There’s a pattern I keep seeing in small teams that ship real work with AI agents. The team upgrades to the newest frontier model — the launch post promises better reasoning, longer context, sharper instruction following — and instead of everything getting better for free, their carefully tuned workflows get weirder. Long outputs where they used to get short ones. Ignored instructions that used to work. Tool calls in odd orders. Agents that wander off the plan halfway through a task and come back with something adjacent but not what was asked.

The reflex is to blame the model. “New one is worse.” “They dumbed it down.” “Regression on release.” Sometimes that’s true at the margins. Usually it isn’t. What actually happened is much less dramatic and much more uncomfortable: the rules changed, nobody sent you the memo, and every prompt you wrote against last year’s model is now carrying assumptions that stopped being true.

Anthropic quietly made this concrete on July 25 when they published updated guidance on context engineering for the Claude 5-generation models, a day after Opus 5 launched. It’s about ten days old as I write this. Buried inside a document that reads like a routine developer post is a plainly awkward message for anyone with agents in production: a lot of the prompt-engineering folk wisdom from 2024 and early 2025 is now dead weight, and some of it is actively hurting your outputs.

This piece is the practical catch-up. What actually changed, what to delete from your prompts today, what to adopt in its place, and a one-hour audit you can run against your existing agents before the next upgrade lands and confuses you again.

The symptom, before we get to the cause

Before diagnosing, let’s name what “your agent got worse” usually looks like in the wild, because the specifics matter for the fix.

The most common report is instruction drift: a prompt that used to end with “respond in fewer than 150 words” now gets you 400 words, cheerfully written and confidently wrong about the constraint. The model didn’t forget the instruction — it read it, weighed it against everything else in the context, and decided the everything-else won.

The second most common is tool-use weirdness: an agent that used to reliably call the search tool before answering now answers from its own head, or calls the tool three times when once would do, or calls a tool you removed from its schema two versions ago. The tool definitions haven’t changed. The way the model reasons about when to reach for them has.

The third is format collapse: JSON responses that used to be clean now come wrapped in prose, or code blocks that used to render in Markdown now come as inline text, or the structured output you asked for arrives with an extra key you didn’t request and can’t parse. The schema is fine. The model is exercising newly expanded judgment about how to be helpful, and helpful in its current definition includes “add context you didn’t ask for.”

Fourth, and most damaging in production: quiet quality regression on evals you don’t run. You upgrade, you spot-check three tasks, they look fine, you ship. A week later a customer complains about an edge case you always used to handle. That edge case wasn’t in your spot-check. It was in the tail of your workload, and the tail is where the reasoning changes show up first.

If any of that sounds familiar, welcome. You’re not imagining it, and you didn’t do anything wrong. You’re just running a 2024 playbook against a 2026 engine.

What actually changed

To fix it, you have to understand what “context engineering” replaced prompt engineering with. The short version is that the frontier models have gotten dramatically better at reading intent from the shape of your input — which sounds nice, but it means the shape is now doing work it wasn’t doing before, and the shape of most legacy prompts is wrong for that.

Three shifts matter in practice.

The context window stopped being a bucket and started being a budget. A Claude 5-generation model with hundreds of thousands of tokens of context is not saying “shove everything in and I’ll figure it out.” It’s saying “everything you put in here will be weighed, and irrelevant material has a cost — not just in latency, but in the model’s attention being pulled away from what actually matters.” The old habit of stuffing every document, every past turn, every possible reference into context “just in case” now dilutes your instructions. Less is more, and targeted is more still.

Tool schemas became first-class citizens. In the older generation, tools were something the model called when your prompt said “you can use these tools.” In the current generation, well-designed tool descriptions carry a huge share of the reasoning load — the model reads them as part of understanding what job it’s on. Vague tool descriptions (“search the web”) produce vague tool use. Specific, purpose-anchored descriptions (“search the customer’s ticket history for prior mentions of the same product”) produce specific, on-target tool use. If your tool schemas are still one-liners inherited from a 2024 project, they’re leaking capability.

Role-play scaffolding became noise. The classic “You are a senior [role] with 20 years of experience in [domain]” opener was a load-bearing prompt technique in 2023, still useful in 2024, and by mid-2026 it is at best neutral and at worst actively distracting. The current models don’t need to be told to take the task seriously. They need to be told what the task is, what “done” looks like, and what specifically to do when they hit ambiguity. The persona preamble buys you nothing and eats tokens that would be better spent on the actual specification.

None of these are secret. They’re all in the July 25 guidance if you read it closely. They’re also all things almost nobody goes back and updates their old prompts for, because prompts don’t fail loudly when they’re merely suboptimal — they fail quietly, and quietly is exactly the failure mode that survives spot-checks.

Old habits to delete

Here’s the tactical version. Every one of these was reasonable advice in 2024. Every one of them is now costing you.

Delete the persona preamble. “You are an expert X” adds nothing to a modern model except tokens. If your prompt genuinely needs a stance — “prefer conservative interpretations when in doubt” — say that plainly as an instruction. Don’t dress it up as a character.

Delete the “think step by step” boilerplate. Chain-of-thought prompting was doing real work when the models needed to be nudged into reasoning. The current models reason by default when it helps and skip it when it doesn’t. Adding “think step by step” now often produces performative reasoning — visible thinking tokens that don’t actually improve the answer, and sometimes drag it off course.

Delete the “under no circumstances” mega-constraints. Long lists of prohibitions (“do not X, do not Y, do not Z”) were how we tried to hem in older models. Modern models handle a small number of clearly stated constraints well and start to weigh a long list of them against each other in ways you can’t predict. If you have more than three hard constraints, you probably need a validator on the output, not more prose in the prompt.

Delete the “just in case” context. Every document, log, or historical example you added because “it might help” is now being read, weighed, and factored in. If it’s not directly relevant to this task, cut it. If you don’t know whether it’s relevant, run the task with and without it and compare — you’ll usually find “without” is at least as good, sometimes better.

Delete the redundant role-play scaffolding around tool calls. “You have access to the following tools. You may use them. When you use them, format your call as…” was necessary once. Now the tool schema itself communicates all of that. The extra framing is duplicated context that gets in the way.

Delete the format examples that no longer match your schema. Every prompt collects fossil examples — “here’s what a good response looks like” — that drift out of sync with your actual schema over time. Every fossil example is teaching the model to produce something you’re not actually validating against anymore. Purge them.

New habits to adopt

Cutting is half the work. The other half is filling the space you freed up with things that pull their weight in the current regime.

Write to a context budget. Pick a target token count for your prompt (including retrieved context) and defend it. If you’re at 8,000 tokens of context to answer a customer support question, ask what the top 2,000 tokens would be and try that first. You’ll usually find the shorter, sharper input produces cleaner outputs and runs faster and cheaper. Budgets force prioritization; unlimited context invites sprawl.

Design tool descriptions like product copy, not stubs. Every tool schema should tell the model three things clearly: what the tool does, when to use it (and when not to), and what a good query into it looks like. “Searches the web” is a stub. “Searches the public web when the user asks about current events, pricing that changes weekly, or when the model’s training-cutoff answer would be more than six months stale. Query should be a specific search phrase, not a natural-language question.” is a description. The second one produces radically better tool use with no other changes.

Let the model ask. One of the underrated shifts in the current generation is that models are much better at asking a clarifying question when they genuinely need one — if your prompt gives them permission. Add an explicit “If the user’s request is ambiguous in a way that would change your answer, ask a single clarifying question before proceeding.” You’ll trade a small amount of round-trip latency for a large amount of avoided wrong answers.

Practice memory hygiene. If your agent has memory or is long-running, curate it. Not everything the agent has ever seen belongs in its future context. A weekly (or per-conversation) memory pass — “summarize and prune anything that is no longer actively guiding this workflow” — keeps the agent focused. Unpruned memory quietly becomes the same problem as unpruned context.

Treat prompts as versioned code. Every prompt should live in your repo, with a version number, next to a small set of eval cases you actually run when you change it. This sounds like overkill for a small team; it stops sounding like overkill the first time a “small tweak” silently degrades production outputs for three days.

Bias toward specification over demonstration. Older prompting leaned heavily on few-shot examples (“here’s how to answer, mimic this”). Current models do better with clear specifications (“your response must include A, B, and C, in that order, with C limited to a single sentence”) than with piles of examples. Examples are still useful for genuinely novel formats. For anything that can be specified, specify.

The one-hour audit

You don’t need a project to catch up. You need an hour and one prompt at a time. Here’s the audit I run.

Minute 0–10 — Inventory. List every prompt and agent you have in production. If it’s more than ten, sort by how much it would hurt if it silently degraded, and start at the top of that list. You are not auditing all of them today. You are auditing the load-bearing ones.

Minute 10–20 — Strip. For the top prompt, open it in one window and open a scratchpad in another. Move to the scratchpad every line that: names a persona, says “think step by step,” lists more than three prohibitions, adds “just in case” context, restates what a tool schema already says, or shows a format example that no longer matches your live schema. Do not delete them yet. Move them.

Minute 20–30 — Rebuild. Rewrite the prompt from what remains, plus (a) a clear statement of the job, (b) a short list of hard constraints (three or fewer), (c) a “if ambiguous, ask one question” clause, and (d) an explicit output specification. Aim for at least a 40% reduction in token count. If you can’t hit 40%, you’re being too gentle.

Minute 30–45 — Compare. Run five representative inputs through both the old prompt and the new one, using the same model. Actually look at the outputs side by side. You are checking two things: is the new one at least as good on your normal cases, and is it better on the edge cases where the old one was drifting? If the new one is worse, add back one deleted piece at a time until you find which one was actually load-bearing. This is how you learn what your specific workflow depends on.

Minute 45–60 — Bank the eval. Save those five inputs and their expected-behavior notes into a prompt-evals/ folder in your repo. Next time the model updates, or you change the prompt, you re-run this five-input battery in ten minutes and know whether you broke anything. This one small step converts every future upgrade from “hope for the best” to “run the tests.”

If you do one prompt a day for a week, you’ll have retuned your entire agent surface for the current generation and given yourself a lightweight test suite in the process. This is the closest thing to a free lunch on offer.

The meta-lesson: upgrades are migrations

The reason “your agent got worse after the model got better” catches teams off guard is that model upgrades don’t look like migrations. There’s no schema change, no breaking API, no version pin to update in your package.json. You just call a new model name and everything keeps working — until it doesn’t, quietly, in ways you don’t notice for a week.

The mental model that actually fits: a model upgrade is a dependency bump on something your entire product depends on, without types to guide you and without a compiler to yell at you. In any other engineering discipline you’d have a test suite. The reason you don’t have one for prompts is historical — prompts felt like content, not code — and it’s the historical accident it’s time to fix.

The teams that will spend the next year quietly out-shipping their peers won’t be the ones with the newest model. They’ll be the ones who treat prompts as versioned code with an eval suite, who cut their context to budget, who write tool schemas like product copy, and who spend an hour a week auditing the prompts that matter most to their business. That’s not glamorous work. Neither is running your CI. Both are how software actually stays working.

If any of your agents got weirder after your last model upgrade, that isn’t the model’s fault and it isn’t your fault. It’s the fault of the fact that nobody thought to hand you a migration guide. Now you have one. Go delete some scaffolding.

Sources

• Anthropic — Claude context engineering guidance for Claude 5-generation models, published July 25, 2026. Primary source for the shifts named above (context as budget, tools as first-class, persona preamble as noise).
• Anthropic — Opus 5 launch announcement, July 24, 2026. Context for the model generation the guidance applies to.
• Anthropic — Claude Cookbook, updated July 24, 2026, for concrete tool-schema and prompt examples aligned with the new guidance.
• Hacker News discussion threads on the guidance and adjacent context-engineering debates, late July – early August 2026, as evidence of the confusion the changes are creating for teams with existing production agents.

Freshness blip: primary guidance cited above is 10 days old as of publication. This is a practical catch-up piece triggered by fresh guidance, not a launch recap. The audit workflow is intended to survive the next several upgrade cycles regardless of which vendor’s model you’re running.