I have a few prompts that survived far longer than I expected. They worked when I wrote them, so I kept adding to them. If an answer wandered, I added “think step by step.” If the format slipped, I added a longer example and a more detailed procedure. Each line felt like insurance.
Then the insurance started getting in the way. The answers were not obviously wrong, but they became longer and more ceremonial. A small change would begin with a plan. The model repeated information that the tools could already inspect. The useful judgement was buried beneath instructions written for an older setup.
I blamed the model first. On a fresh thread, I made the same request in four plain sentences. The result was easier to check and closer to the action I needed. That was the clue: age was not the problem. The prompt was still doing jobs that had moved elsewhere.
I thought the model had regressed
The job was ordinary: read an incident log, narrow the likely causes, and leave the next diagnostic command. My old prompt ran past 40 lines. It assigned a role, dictated a reasoning sequence, specified the output, and included examples for tools that the agent could already call.
The response looked thorough. It was also awkward to review. Observed facts and speculation sat inside the same long explanation, and the model proposed tools it had not used. I kept the same log but removed everything except the purpose, evidence boundary, and finish line. The second response offered fewer causes and better commands. What mattered was not elegance. The operator could decide what to do next more quickly.
One comparison is not a method, so I repeated it on document review, fault diagnosis, and spreadsheet checking. I removed only the rules that consistently added review time without improving the result.
“Old” usually means that responsibilities overlap
I now review prompts by responsibility rather than by sentence.
Prompt states the purpose and boundaries. Context supplies the material required for this job. Harness runs and verifies repeatable work. When one document tries to do all three, both the prompt and the diagnosis become harder.
The Prompt holds the purpose, constraints, standard of evidence, and definition of done. Context is the live material: files, project rules, and current evidence. The Harness handles planning, tool calls, tests, retries, and the conditions that require a human decision.
Many prompts written for early assistants contain all three layers. When the result fails, everything looks like a prompt problem. It may actually be stale material or a test that never ran. Separating the layers gives the failure somewhere specific to live.
The lines I removed first
I started with role-play that did not change behaviour. “Act as a senior expert” says little unless it names the risks, evidence, and decision standard. I now write what should be protected and when the work must return to a person.
Next went requests for a narrated chain of thought. I do not need a broadcast of hidden reasoning. I need claims tied to logs, source text, or test results, with uncertainty marked clearly.
I also removed repeated tool tutorials where the system already provided the tool definition and schema. Examples stay only when they constrain a behaviour that otherwise drifts.
Hard-coded dates were another easy deletion. “Today is August 2025” turns into debt as soon as the prompt is copied. For time-sensitive research I inject the current date and record the publication and review dates of the sources.
Finally, I cut procedures and schemas that existed only to feel safe. A fixed schema remains when another system must parse it. A mandatory route remains when policy requires it. Otherwise I leave the agent room to choose the route and judge the delivered result.
Some lines must stay
A stronger model still cannot infer private operating facts:
- the cost of sending a wrong answer to a customer
- which actions may run automatically and which require approval
- the metric that counts as success and the condition that stops the run
- contractual or internal rules that must not be guessed
- the shape required by the next system in the handoff
These are not prompt tricks. They are knowledge about the work. Editing an old prompt should make that knowledge clearer, not remove it in the name of brevity.
Tools have taken over part of the old prompt
OpenAI’s Harness Engineering article argues against turning AGENTS.md into a thousand-page manual. It recommends a short map that points agents toward the relevant material, with tests and tooling enforcing rules that prose cannot reliably police.
Source: OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 February 2026. The article covers concise guidance, progressive disclosure, and constraints enforced by the environment.
This is more than tidying documentation. “Run the tests,” “fix failures,” and “do not import this dependency” are weak requests when they appear only as prose. A harness can actually run the check and stop the job. The prompt asks. The harness enforces.
My working rule is simple. If a human repeats the same check across several runs, I ask whether it belongs in a test, script, permission boundary, or checklist. If it does, I remove the repeated plea from the prompt.
I also stopped treating more context as automatically better
Loading every policy, meeting note, and previous conversation feels thorough. It can also blur the current task. Anthropic describes context as a finite resource and warns about context rot: as the context grows, the value a model extracts from each additional token can decline.
Source: Anthropic, Effective context engineering for AI agents, 29 September 2025. It treats system instructions, tools, external data, and history as a context-management problem.
I split permanent context from material that can be fetched. The permanent file contains the project goal, non-negotiable rules, and pointers to evidence. Detailed policies, retrospectives, and tool notes stay in separate files and are loaded for the jobs that need them. Nothing is thrown away; it is made findable.
One prompt, before and after
The old version read like this:
You are a senior expert with ten years of experience. Think step by step and explain each stage of your reasoning. Write a plan first, wait for approval, and then begin the work.
It sounds responsible, but the work itself is missing. There is no named input, no evidence rule, and no finish line. I replaced it with this:
Review the attached incident record and list the most likely causes in descending order, with evidence for each. Do not assert a cause that the logs cannot support. The task is complete when the operator has the next diagnostic command ready to run.
The second prompt does not prescribe a style of thinking. It names the material, the evidence boundary, and the state that counts as done. If planning is useful, the agent can plan. If approval is mandatory, the harness stops at the approval gate.
How I review a prompt when the model changes
I do not rewrite the library every time a model ships. I take three representative jobs and run the current prompt against a shorter candidate under the same conditions. Then I check:
- Did the user-facing result improve?
- Did unsupported claims decrease?
- Did human review take less time?
- Did the number of correction requests fall?
- Can I locate a failure in Prompt, Context, or Harness?
I mix easy and awkward inputs. A document review includes documents of different lengths. A data check includes missing values and malformed formats. If removing a rule hurts one class of work, the rule returns with a narrower condition. Deletion needs version control too.
What it means to retire an old prompt
Not every year-old instruction is bad. A customer promise or a hard failure threshold may still be the most valuable line in the file. What no longer makes sense is forcing the prompt to carry behaviour the model already supplies, checks a tool can enforce, and reference material that can be retrieved when needed.
I keep four things visible: the intended result, the lines that must not be crossed, the evidence that counts, and the finish line. Context is fetched for the job. The harness runs what can be made repeatable.
The biggest improvement was not a nicer tone. It was being able to tell what to repair after a failure: the request, the material, or the execution environment. That distinction has saved me more time than any new prompting phrase.
