The Future of Humans, AI, and the WebENJA
Menu

Dated 2026-07-26Published 2026-08-04Free

Detailed instructions written for an earlier generation of AI models become harmful on today's models

日本語

Contents of this article

Summary

I made two passes on how to design memory and instructions for AI agents, comparing research papers with the official documentation for frontier models. Instead of taking the first pass’s conclusion as it stood, I audited which generation of model each supporting paper had measured on. Not one of the five main papers measured on a frontier model, and alongside that I confirmed that the official documentation of three companies has been changing in the same direction. My sources were the notes I made reading and checking the papers’ body text myself, together with the original text of each company’s official documentation. I also draw on how that conclusion was worked into the operating rules of a membership platform for a technical blog.

What the official documentation says now

The model providers themselves write in their official documentation that detailed instructions aimed at an earlier generation can lower output quality on today’s models. Anthropic’s official documentation for Claude Fable 5 says that skills built for earlier-generation models can over-instruct and lower output quality, so if the default behavior is better, consider deleting the old instructions. It also says that you can now steer the model with short instructions, without naming and listing each behavior one at a time. Technical staff at the same provider reported that cutting more than 80 percent of the system prompt for a coding tool produced no measurable drop in their evaluations, and they characterized what they cut as constraints that had been needed to guard against the worst behavior of older models.

OpenAI points the same way. The official documentation for GPT-5.6 has a section telling you to keep instructions lean, and it gives numbers: cutting repeated instructions and examples and making tool descriptions concise raised internal evaluation scores by roughly 10 to 15 percent and cut total tokens by 41 to 66 percent. Google’s developer guide says that verbose or overly complex prompting techniques written for older models can be over-analyzed, so write concisely. Only two of the three give numbers, and both are the provider’s own report rather than an independent measurement, but the fact remains that all three point their guidance the same way. An instruction document that has been built up over time can, if left alone, start dragging output quality down on a newer generation of models.

Which generation of model the supporting papers measured

Let me stop here for a moment. A little while back, when I surveyed research on agent memory broadly, the first pass’s conclusion leaned the other way. On the strength of papers finding that memory can degrade if you keep updating it with distilled lessons alone, and that keeping raw fragments of the conversation as memory beats processed memory, I read it as raw logs beating distillation. Before locking that conclusion into the design, I questioned a premise, namely whether that research still holds on today’s models, and ran a second audit pass.

The result was clear. Of the five main papers I had leaned on, not one measures on a frontier model. The paper claiming that consolidation degrades memory uses the strongest model for its experiments, but that model, too, was from the earlier generation. The paper where raw fragments win measured only on 2024-generation models, and its authors write in their own limitations section that personalization and writing-style uses are unverified. The study showing limits on reproducing writing style measured only on two 32B open models. On top of that, the consolidation paper’s numbers disagree between its abstract and its body. The abstract reads as though it fails 54 percent of the time, while the body and the figures show 54 percent as the success rate that remains. My first pass had drawn on the abstract’s side. A paper’s conclusion circulates through its abstract, but you cannot see the experimental setup and the limitations without reading the body.

For the record, that no one has remeasured on frontier models does not mean the papers are wrong. It states where things stand: I do not yet know whether they still hold. If that distinction is not kept, then it is my side that ends up throwing research away without grounds.

Two axes that had been mixed together

The audit showed one more thing. The very axis of the first pass, raw logs against distillation, had mixed two separate questions together. What the papers measure is the question of what to store as memory and retrieve later, while the discussion of instruction documents deals with the question of what to hand over as instructions right now. They are different questions, so they do not contradict each other. And the only layer both bodies of primary material agree in rejecting is the middle one: a normative enumeration of steps, cut loose from context and set out as bullet points. The papers say that if you keep having a machine regenerate that enumeration of steps, the process breaks down over the long run, and the providers say that layer can be cut back heavily. What neither side rejects is the record of the exchanges that actually happened, and the purpose of the work itself. This is not spelled out in any outside document. I arrived at it by comparing the papers with the official documentation.

Instructions to cut and instructions to keep

Put into practice, the right answer is not that you should make instructions abstract. What works is matching how detailed your instructions are to the generation of model you use.

Here are the kinds of instruction you can cut: instructions that specify each step one at a time, instructions that enumerate each behavior one at a time, instructions that cover every case, instructions that stack the same point in different words, and instructions that give examples on reasoning tasks. There is evidence of a generational shift here: on strong models, adding conventional examples does not raise reasoning performance. Researchers have also identified the mechanism by which fine-grained specification does harm. When domain jargon, lines stating constraints, or identifier names sit in the instruction, the model calls up a wrong answer it holds in memory. Take those out, the explanation goes, and the model has no choice but to reason from the structure of the problem itself. The same measurement also shows that on simple problems, making things vague drops accuracy by 11.8 points, so cutting is not the answer in every situation.

What you keep is the purpose and the domain background, the constraints you cannot give up, the boundary of what needs approval, the conditions that decide success, and the output format. OpenAI’s official documentation, right after writing that you often do not need to prescribe every step, goes on to say that you should still supply domain background, constraints you cannot give up, approval boundaries, and the conditions that decide success. Anthropic’s general guidance still tells you to be specific about the output format and the constraints you want. The same official documentation also carries concrete instructions pointing the other way: for hard tasks, give the full specification at the start, and for narrow tasks, constrain the scope explicitly. One measurement also shows that reproducibility falls apart once even the conditions of judgment are left vague. Models correctly fill in requirements you did not write only about 40 percent of the time, and the spread doubles. Along with this, write the reason for a rule rather than the rule itself, because when the reason is written, the model generalizes from the explanation. And if you want the model to question its premises, abstract instructions will not produce that on their own. Even reasoning models fail to point out somewhere between a quarter and 40 percent of false premises, by one measurement. If you want premises checked, write it explicitly as a pass-or-fail condition on the deliverable, not as a step.

I will add two caveats as well. The claim that stronger models are harmed more by concrete detail is not supported. There is a measurement showing that the effect of granularity does not correlate with model strength. The capacity to follow many instructions at once has also grown a great deal over the past year, so cutting instructions is not about a limit on volume. It narrows where the model puts its attention.

Taking stock as a procedure, not as a rule

On my own platform, I worked this conclusion into the operating rules. I did not write it as a rule saying instructions should be abstract, though. That is because the evidence here is specific to a model version, the recommendation differs from version to version even within one provider, and it will change again with the next version. What I wrote is a procedure. I wrote that I take stock of step-by-step instructions added to cover an old model’s weaknesses, and delete them when the model changes. I also wrote that I remeasure how detailed the instructions are every time the generation changes.

An instruction document is an asset, but part of it is correction for the model’s weaknesses, and those weaknesses fade away with the generations. In the week a model changes, try rereading your own instruction document once. The more lines you can delete, the more that document was written to fit the earlier generation of models.

Research I referred to

I list the research this article rests on, with titles and links. I checked all of them down to the body text as of 2026-07-26. Where a title is not given, I describe the contents instead.

Official documentation is not research, so I list it separately. The quotations in the article are as the documents read on 2026-07-26. This article organizes what public documents state, and it does not represent the views of any of the providers.