Minimalist harness: why new models need fewer rules, fewer tools and less prompt

The harness that saved your agent last year is the one getting in its way now.

That IMPORTANT: in all caps. The 40 tools registered "just in case". The three-page few-shot block. The router that forces the agent through five fixed steps before it's allowed to answer. All of it was born to patch a hole in one specific model. The model changed. The patch stayed.

A minimalist harness is the practice of keeping only what the current model actually needs, deleting the rules, tools and prompts that turned into noise with each model upgrade. It's not laziness. It's maintenance. Every model generation turns the previous harness's crutches into dead weight. I'll show what Anthropic and OpenAI themselves tell you to remove when you switch models, what to delete first and, most importantly, how to prove with evals that the removal didn't make anything worse.

TL;DR

• What it is: a minimalist harness means re-auditing prompt, tools and orchestration on every model switch, removing whatever turned into noise.
• What to remove first: ALL-CAPS rules, anti-laziness instructions, redundant tools, giant few-shot blocks and fixed orchestration steps.
• Grounding: the official migration guides from Anthropic and OpenAI, plus Rich Sutton's "The Bitter Lesson".
• Golden rule: nothing leaves without a before/after eval. Nothing comes back without an eval showing it's missed.

The context: harnesses grow by accretion, never by design

If you need a vocabulary refresher, the hub for this topic on the blog is what a harness is in AI: the loop, the tools, the state and the guardrails wrapped around the model. This post is about what happens to that harness over time.

What happens is accretion.

The definition of harness engineering that stuck in the industry, from Mitchell Hashimoto, explains the mechanism without meaning to: every time the agent makes a mistake, you engineer a solution so it never makes that mistake again. We covered this in the post on why harness engineering is not enough. It's real engineering. But notice the detail: the rule goes in when the model fails. Nobody has a process for taking the rule out when the model stops failing.

The result: the harness becomes sediment made of patches. Each layer was written for a model you don't even use anymore.

And here's the problem few people notice. An old patch isn't neutral. It doesn't just sit there, harmless. New models follow instructions more faithfully, and an instruction written to compensate for the old model's inattention becomes overkill on the new one.

That's not my opinion. It's in Anthropic's official guide:

"If your prompts were designed to reduce undertriggering on tools or skills, these models might now overtrigger. The fix is to soften any aggressive language. Where you might have said 'CRITICAL: You MUST use this tool when...,' you can use more normal prompting such as 'Use this tool when...' instead." (Anthropic, Prompting best practices)

And OpenAI, in the GPT-5.5 migration guide, is even more direct: "Begin migration with a fresh baseline instead of carrying over every instruction from an older prompt stack". The reason comes right after: "Legacy prompts often over-specify the process because earlier models needed more help staying on track" (OpenAI, GPT-5.5 guide).

Two competing labs, same advice: delete before you add.

Doing this kind of re-audit on every release is exhausting alone, because the ground shifts every quarter. It's what we do every week in the Clã Beer and Code: production agents on the table, harness, RAG and evals, arguing about what still pays for itself and what already turned into noise.

The Bitter Lesson applied to harnesses

In March 2019, Rich Sutton published a short essay that everyone building agents should reread once a year. The Bitter Lesson opens like this:

"The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin."

Sutton's argument is about research: every time someone encoded human knowledge into the system (chess rules, vision heuristics), it worked in the short term and lost in the long term to general methods that scale with compute. The line that closes the essay is the one that matters here: we want agents that can discover like we can, not agents that contain what we have discovered.

Now swap "AI research" for "your harness".

Every hardcoded rule in the system prompt is human knowledge injected to compensate for a model limitation. It works. Until the next model, trained with more compute, solves that on its own. Then your rule stops helping and starts competing with the model's judgment.

That doesn't mean the harness is dead. The post on harness engineering still holds: loop, state, permissions and observability are infrastructure, not crutches. The bitter lesson separates two things:

• Infrastructure: what gives the model access to the world (well-designed tools, persistent state, sandbox, cost limits). This stays.
• Crutch: what tries to think for the model (procedural rules, ALL-CAPS emphasis, rigid reasoning scripts). This expires.

Minimalist harness in practice: what to remove when you switch models

A practical list, in increasing order of risk. Start at the top.

1. Artificial emphasis: CAPS, "CRITICAL", "NEVER", "ALWAYS"

It's the most common patch and the easiest to remove. It existed because the old model ignored instructions buried in a long prompt. The new model doesn't. So ALWAYS use search turns into a search on every message, including "thanks".

# Antes (escrito pra um modelo que esquecia a tool)
CRITICAL: You MUST ALWAYS call search_docs before answering.
NEVER answer from memory. If in doubt, use search_docs.

# Depois
Use search_docs when the question depends on product documentation
or on details that may have changed. Answer directly when it doesn't.

Notice the "after" isn't just more polite. It gives the criterion, not the order. Anthropic literally names the "If in doubt, use [tool]" pattern as a cause of overtriggering and recommends replacing blanket defaults with targeted instructions (source).

2. Anti-laziness instructions

"Be extremely thorough." "Read every relevant file before answering." "Don't stop until you're absolutely sure." That was a vaccine against models that answered shallowly. On the current model, it becomes excessive exploration, bloated context and a bigger token bill.

Anthropic's migration guide has an item just for this: "If your prompts previously encouraged the model to be more thorough or use tools more aggressively, reduce that guidance". If the model still overdoes it after you remove that, the recommended fix is lowering effort, not writing more rules.

3. Redundant tools

Tools are context. Every tool definition takes up space in the prompt and adds one more decision for the model at every step. A harness that registers get_user, get_user_by_email, get_user_orders, get_user_profile and search_users is asking the model to pick between five doors that open onto the same hallway.

Anthropic itself, in its guide on writing tools for agents, sums it up: "More tools don't always lead to better outcomes". The recommendation is a few tools built for high-impact workflows, consolidating operations that always go together into a single call.

In practice, ask this about each tool:

• Did the model call it in the last N production traces?
• Does it do something another tool already does with one extra parameter?
• Does it exist because the old model couldn't chain two calls?

If the answer is "no, yes, yes", it's a candidate for removal.

4. Giant few-shot blocks

Examples are the strongest form of instruction there is. That's exactly why they're dangerous. Five long examples teach format, tone, length and, as a bonus, the quirks of those five examples. The old model needed them to get the format right. The current model gets the format right with one sentence or with structured outputs.

Try replacing the examples block with a description of the output contract. If the eval holds, you gained context and lost a source of bias.

5. Rigid orchestration

This is the most expensive one to touch and the one that pays off most. It's the fixed pipeline: "first classify, then plan, then search, then validate, then answer", each step a separate call, with the code deciding the order.

It made sense when the model got lost in multi-step tasks. Today, very often, you're paying for five calls to force reasoning the model would do better in one, with the right tools at hand. OpenAI says exactly this: "Reduce or remove detailed step-by-step process guidance" (source).

Careful here: not every fixed step is a crutch. Security gates, output validation and human approval checkpoints are infrastructure (they're the layers of a production harness). What goes is the step that only exists to tell the model how to think.

The oldest advice is still the best. Anthropic, in Building effective agents, was already recommending in 2024 "finding the simplest solution possible, and only increasing complexity when needed". The part everyone forgets is that "when needed" changes with every model.

How to measure whether removal made things worse: before and after evals

This is the difference between a minimalist harness and a sloppy one. Deleting rules on gut feeling is just as irresponsible as adding rules on gut feeling.

The flow:

1. Build a dataset of real cases (30 to 100 already gives you signal), including the cases that motivated each rule you want to remove.
2. Run the current harness on the new model. That's the baseline.
3. Remove one category of crutch at a time.
4. Run again. Compare accuracy, number of tool calls and tokens.
5. If it got worse, the rule comes back, rewritten in a normal tone. If it tied or improved, it dies.

A Python skeleton, using the Anthropic SDK, that compares two system prompts on the same dataset:

import json
import anthropic

client = anthropic.Anthropic()
MODEL = "claude-opus-5-5"

TOOLS = [{
    "name": "search_docs",
    "description": "Search product documentation. Use when the answer depends on docs or recent changes.",
    "input_schema": {
        "type": "object",
        "properties": {"query": {"type": "string"}},
        "required": ["query"],
    },
}]

def run_case(system: str, case: dict) -> dict:
    resp = client.messages.create(
        model=MODEL,
        max_tokens=1024,
        system=system,
        tools=TOOLS,
        messages=[{"role": "user", "content": case["input"]}],
    )
    used_tool = any(b.type == "tool_use" for b in resp.content)
    return {
        "tool_ok": used_tool == case["expects_tool"],
        "tokens": resp.usage.input_tokens + resp.usage.output_tokens,
    }

def evaluate(system: str, cases: list[dict]) -> dict:
    results = [run_case(system, c) for c in cases]
    n = len(results)
    return {
        "tool_accuracy": sum(r["tool_ok"] for r in results) / n,
        "avg_tokens": sum(r["tokens"] for r in results) / n,
    }

cases = [json.loads(line) for line in open("cases.jsonl")]
old_prompt = open("prompts/v1_legacy.txt").read()
new_prompt = open("prompts/v2_minimal.txt").read()

print("legacy :", evaluate(old_prompt, cases))
print("minimal:", evaluate(new_prompt, cases))

And cases.jsonl needs both sides of the problem, not just the cases where the tool should be called:

{"input": "Qual o limite de rate da API no plano Pro?", "expects_tool": true}
{"input": "Valeu, resolveu aqui!", "expects_tool": false}
{"input": "Me explica o que é um webhook em uma frase.", "expects_tool": false}

This example measures a single dimension on purpose (did it call the tool when it should?). In production you'll want a judge for answer quality, but start with what's binary and cheap. Overtriggering shows up exactly there: on the "thanks" case, the legacy prompt tends to call search and the minimal one doesn't.

Two rules so you don't fool yourself:

• Include regression cases. If the ALL-CAPS rule was born from an incident, that incident becomes a case in the dataset. That's what proves whether the rule is still needed.
• Look at cost alongside accuracy. A tie on accuracy with fewer tokens and fewer tool calls is a win. OpenAI uses the same logic for effort: "Increase effort only when evals show a measurable quality gain".

I won't give you a gain number, because it depends on your harness, your model and your dataset. Anyone promising "cut 50% of the prompt and gain 20% accuracy" without showing the eval is selling something else. The number that matters is the one your eval shows.

Limitations and caveats

Minimalism isn't the absence of guardrails. Permissions, sandbox, cost limits, output validation and human approval on destructive actions stay. A smarter model doesn't change the fact that it shouldn't have write access to the production database without checks.

It doesn't apply to every model at once. If you route between a large model and a small one, the small one may still need the crutch the large one doesn't. Prompt per model, eval per model.

The direction changes between versions. OpenAI itself, back in the GPT-5.1 days, advised reinforcing persistence because the model was sometimes too concise. So: today's guidance asks for less, but the right answer is whatever the eval shows for the model you're running, not the trend of the moment.

No eval, no touching. If you don't have any dataset, the first step isn't deleting rules. It's building those 30 cases.

Quick FAQ

What is a minimalist harness? It's keeping only what the current model actually needs in the harness: infrastructure (tools, state, guardrails, observability) yes, old-model crutches (emphatic rules, giant few-shot, rigid pipelines) no. And re-auditing that on every model switch, with evals.

How do I migrate a prompt to a new model without breaking what works? Start from a lean baseline, as OpenAI recommends, and add back only what the eval proves necessary. Remove one category at a time and keep the incident cases in the dataset.

Are fewer tools always better for an agent? Not always. Fewer redundant tools is better. Anthropic recommends a few well-designed tools, consolidated for high-impact workflows, with clear descriptions of when to use each (source).

How do I build a harness with this in mind from day one? Separate infrastructure from behavioral instructions from the start. Version the system prompt, note why each rule exists (which incident it fixes) and keep the eval dataset next to the code. The step by step for a first harness is in the Laravel harness from scratch tutorial.

Conclusion

A harness isn't a monument. It's scaffolding. And a minimalist harness is just the habit of taking down the scaffolding the building no longer uses.

Every rule you wrote was a bet on the limitation of one specific model. When the model changes, the bet needs to be re-evaluated, and Anthropic and OpenAI are saying, in writing, that a good chunk of those bets have turned into noise.

The next step in this story is obvious: harnesses that audit themselves. Google has already open-sourced work in that direction with Harness2. Until that becomes standard, the job is yours: open the system prompt, delete the first CRITICAL and run the eval.