The Model Eats the Harness — But Only the Middle

Two statements landed within weeks of each other this summer, and together they read like an obituary for a whole category of engineering work.

In June, Google DeepMind’s Logan Kilpatrick told Sequoia Capital that the agent harness — the scaffolding everyone is currently building their moat out of — is temporary: “The scaffolding is oftentimes a couple of steps ahead of what is baked directly into the model. And then what ends up happening is the model eats that scaffolding and it becomes part of the native model system.” He put a clock on it: the idea that “the harness is where the alpha is” “perhaps won’t be true, at least in the way that we think of the harness today, in 12 months.”

In July, Anthropic published the receipts on its own product. “We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations,” wrote Thariq Shihipar, a member of Anthropic’s technical staff. The deleted lines were rules like “default to writing no comments. Never write multi-paragraph docstrings” — replaced by a single sentence asking the model to match the surrounding code.

The obvious conclusion — everything you build around a model is dead weight in waiting — is wrong, and wrong in a way that matters if you decide what gets built. The eating is real. It is also confined to exactly one layer of what “harness” means.

”Harness” is four things. Only one is food.

The slogan stays unfalsifiable as long as “harness” means everything between the weights and the outcome. Split it into its actual jobs and it becomes predictive:

Layer	What it is	Why it exists	Fate
Actuation	tools, sandbox, the agentic loop	the model has no hands without it	never eaten
Orchestration	prompt chains, forced workflows, “MUST do X then Y”	compensates for model unreliability	eaten
Context	CLAUDE.md, skills, memory, MCP connections	supplies what the model cannot know	changes form, never dies
Governance	permissions, gates, audit, cost controls	humans deciding what it may do	never eaten

Anthropic’s own changelog obeys these boundaries with striking precision. Everything deleted outright from Claude Code’s system prompt was orchestration: behavior-correcting rules, repeated instructions, worked examples — which, the post notes, now actively hurt, because “giving examples actually constrains them to a certain exploration space.” The context layer was not deleted; it was reorganized and invested in — skills, auto-memory, progressive disclosure, richer references. And the tools absorbed mass moving downward: instruction paragraphs became well-designed tool parameters, where an enum of pending, in_progress, completed teaches what a page of prose used to.

Kilpatrick draws the same boundary without being asked. In the same interview that predicts the harness’s death, he exempts search and code execution: “there’s still value in having the external scaffolding in certain cases.” That is the actuation layer. It also dissolves the apparent contradiction in Google’s own behavior — predicting harness commoditization while rebasing every Google product onto its Antigravity harness. The prediction is about orchestration. The strategy is about actuation and governance. Same word, different layers.

Why the middle, specifically

The mechanism is not mysterious. Frontier models are now reinforcement-trained inside harnesses, on agentic traces. Any behavior a prompt rule enforces is a labeled failure mode — exactly what that training consumes. Your harness text and the vendor’s training loop are competing to fix the same failures, and the training loop compounds. Once the correction is in the weights, the rule is dead weight; a model generation later, it is a cage.

That yields a one-line test for any piece of harness machinery:

Anything expressible as “the model should have behaved differently” is trainable, and therefore temporary. Anything expressible as “the model couldn’t have known that” is not trainable, and therefore permanent.

No training run, at any scale, learns which library your org banned last quarter, why the deploy freezes on Fridays, or what you personally mean by “clean.” That information has no gradient. It has to be supplied — which is what the context layer is for, and why it survives every model release even as its form changes.

Rich Sutton predicted the eaten half in 2019. The Bitter Lesson’s cycle — building in human knowledge helps short-term, is personally satisfying, plateaus, and loses to general methods that leverage computation — maps onto harness engineering beat for beat. An orchestration layer is precisely a “built-in how we think we think”: hand-coded structure encoding how we believe the model should decompose, verify, and sequence work. But the essay’s own closing line draws the limit: “We want AI agents that can discover like we can, not which contain what we have discovered.” Discovery reaches what is in the world. Five things aren’t:

1. Hands — actuation is physics; no gradient grows a filesystem.
2. Information asymmetry — private context isn’t in the world’s data at any compute budget.
3. Authority — compute optimizes toward an objective; it does not pick one.
4. Accountability — a guarantee is a property of a mechanism, not a skill level.
5. Economics — a script’s marginal run is free; inference never is.

Three tests before you automate anything

The framework earns its keep as a decision procedure. Given a task someone wants to automate, three questions, in order.

Test 1 — Can you write the exact rule? Then it’s a script, not an agent. A program is cheaper and faster, and — the part that gets underweighted — more accurate: its failure modes are enumerable, a model’s aren’t. An LLM at runtime executing a deterministic task is paying inference prices for a lookup table. The model’s place in deterministic work is authoring time (write the script once) and repair time (fix the edge case that breaks it). The model is the mechanic, not the engine.

Test 2 — Does it need judgment? Then an agent runs it, and the real question becomes reachability: can the agent get to the context it needs — the repo, fetchable docs, an MCP connection — or must someone hand-carry it? Reachable context needs nothing custom. Unreachable context — the why behind a convention, what the last outage taught the on-call rotation, taste — is the one legitimate payload for a skill or a memory system. Anthropic’s advice for CLAUDE.md files states the rule as practice: “Avoid stating ‘the obvious’ things Claude should know by looking at your file system or your repo” — and spend the tokens on gotchas instead.

Note that reachability is an engineering variable, and it moves in one direction. Every MCP connection converts a category of hand-carried context into something the agent fetches itself. Wire up the ticket system and “what the ticket requires” stops needing a skill. The territory that custom context must cover shrinks monotonically — the context layer’s own version of the eating, driven by connectivity rather than training.

Test 3 — Does it need a guarantee? CI gates, billing, security policy, compliance: these belong to programs regardless of model quality. The requirement isn’t a high success rate; it’s determinism, reproducibility, and audit — properties of a mechanism, not a skill level. A probabilistic system asymptotes toward 100% and never reaches auditable. This is why the eating has a hard floor: a perfect model does not convert a gate into a judgment call, because the gate’s entire point is that nobody exercises judgment there.

Two honest complications. Many real tasks are 95% rule-writable with an endless tail of messy inputs — invoice parsing is the classic case. The right shape there is a deterministic core with an AI escape hatch: the script handles the head of the distribution, the agent handles the tail, and every tail case the agent solves becomes a candidate for promotion into the script. And the eating runs in both directions: 2023–24 pushed enormous amounts of deterministic work into LLMs because AI was the hammer in hand. The correction is symmetric — the model eats the orchestration middle while scripts reclaim the deterministic bottom. What remains custom is thin, declarative, and specific to you.

Skills come in two species with opposite fates

The consequence lands hardest on skills — the markdown instruction packages that Claude Code and its peers load into context. “Skill” currently names two things that could not age more differently.

Process skills — “follow these steps,” “YOU MUST invoke this before that,” all-caps enforcement — are orchestration wearing a skill costume. They exist to correct model behavior, which makes them trainable, which makes them temporary. Each model generation devalues them, and past some capability line they go negative, constraining a model whose judgment now beats the scripted process.

Knowledge skills — unreachable facts, stated declaratively — survive indefinitely. Anthropic’s post contains the survival criterion almost verbatim: “It’s best when skills encode particular opinions, knowledge, or best practices that are particular to you, your team, or product.”

The slogan version: a skill full of MUSTs is a bet against the model; a skill full of facts is a gift to it.

One data point from this blog’s own tooling, for scale. A July audit of the author’s installed skill fleet found 93 skills, every one model-invoked — meaning every description sat in the context window on every turn — while 60 days of full session transcripts showed only about 15 had ever actually fired. Pruning to 54 recovered roughly 2,800 description tokens per turn. What died was overwhelmingly process: restatements of what the model already does by default. What survived was the knowledge fleet — infrastructure facts, org gotchas, domain reference.

Even the official guidance is fighting about this, which is itself evidence. Within Anthropic’s own plugin marketplace, the skill-creator plugin calls all-caps ALWAYS/NEVER a yellow flag and recommends explaining the why; the superpowers plugin’s docs show recipes beating prohibitions in head-to-head wording tests — while its own meta-skill screams “this is not negotiable”; a third plugin mandates imperative prose everywhere. These sources contradict each other because each was written against a different capability snapshot of the model — coercion calibrated to a moving target. They are arguing about a depreciating asset.

A worked example: the skill that dissolves

Consider a nine-line commit-helper skill — already well-written by every authoring standard. One trigger. A single source of truth. A checkable completion criterion:

1. Run `git diff --staged` and read every hunk.
2. Write the message: imperative subject ≤ 50 characters; body explains why, wrapped at 72.
3. Done when every functional change in the diff is named in the message.

Run the three tests line by line. Line 1 is judgment the model brings unprompted — current models read the staged diff before writing a commit message without being told. Line 3 is a trained-in convention; restating it changes nothing, so it fails the most useful sentence-level check in skill writing: does this line change behavior versus the default? And line 2 is a writable rule — which means it was never skill material at all. It belongs here:

# .git/hooks/commit-msg
subject=$(head -1 "$1")
[ ${#subject} -le 50 ] || { echo "subject > 50 chars"; exit 1; }

The hook enforces at 100%, forever, for free, what the prose requested at whatever rate the model happened to comply. The knowledge residue — the only thing that would have justified the skill’s existence — is empty. The skill dissolves. Had there been a real house rule — a ticket-prefix format, a required sign-off trailer, a reason behind either — that two-line fact would be the whole skill, and it would survive every model release.

That is the general shape of the audit worth running: every skill decomposes into knowledge residue (keep, stated as facts), deterministic steps (demote to scripts and hooks), and process coercion (delete, or defend as a genuine governance guardrail). Sometimes the residue is empty. Then the skill was a program all along — and a well-written skill can still be a skill that shouldn’t exist.

What to do with this

For anyone building on top of models — a team harness, a plugin fleet, or a single CLAUDE.md:

1. Sort your harness by layer before betting on it. Hands, context, and governance are durable investments. Orchestration is a depreciation schedule — build it when today’s model needs it, and plan its deletion.
2. Run the three tests before automating anything. Exact rule → script, with the model as author and mechanic. Judgment → agent, fed only what it can’t reach. Guarantee → program, at any model quality.
3. Write context as facts, not steps. Imperative guidance ages with every model release; unreachable knowledge never does. When a MUST survives your pruning, it should be because violating it is unacceptable, not merely unwanted.
4. Re-audit on every model upgrade. “Does this line change behavior versus the default?” is a model-relative test — sentences that passed last year fail this year. The imperative ones fail first.

The harness isn’t dying. One layer of it is being metabolized, on schedule, by the training loops of the vendors themselves — and that layer was always compensation, never contribution. What remains is the part that was yours to begin with: the hands you give the model, the facts it cannot know, and the lines it may not cross.

---

Sources: The new rules of context engineering for Claude 5 generation models (Anthropic, Jul 2026), Logan Kilpatrick on Sequoia Capital’s Training Data (Jun 2026), Claude Fable 5 and Claude Mythos 5 announcement (Anthropic, Jun 2026), The Bitter Lesson (Rich Sutton, 2019). Skill-fleet numbers from an audit of the author’s own 93-skill installation against 60 days of session transcripts, July 2026.