The Flywheel That Keeps Remaking the Agent Harness

A couple of years ago, the interesting question in agent tooling was whether a dedicated harness could squeeze meaningfully better coding results from the same model. The answer, at the time, was yes: careful prompt engineering, custom code-edit tools, codebase-navigation routines, and small models dedicated to applying diffs all added up to measurable gains on real benchmarks.

That window appears to be closing. Two independent studies — one from UC Berkeley testing seven frontier models across several harnesses on SWE-Bench Lite, another from Apple and EPFL on an MLE benchmark — found that harness choice no longer moves the needle on score for newer, smarter models. The models have absorbed the skills the harness used to inject.

This is not a coincidence; it is a mechanism. A harness brings harder tasks within reach. More users attempt those tasks. More task-completion data flows back to the labs. Models learn those skills natively. The harness then deletes the patch it added and moves to the next frontier. Call it a flywheel: the harness enables, the model commoditizes, the harness moves on.

What Has Actually Changed

The part of the harness dedicated to coding intelligence — the behavioral tricks, the codebase-exploration routines, the self-check loops — is being commoditized by this flywheel. That is worth acknowledging honestly: effort spent fine-tuning those layers over the past year or two is watching them dissolve.

But the harness itself is not dissolving. It is shifting into territory the flywheel cannot yet reach.

Infrastructure is the first area. Tasks that ran for seconds now run for minutes; tasks that ran for minutes now run for hours. A harness designed to run on a developer’s laptop is not the right substrate for an agent that must stay alive through a sleep cycle, a network blip, or a machine restart. The shift to cloud-hosted, long-lived agents is not a feature addition — it is a prerequisite for the next class of work.

Trust and security is the second. As agents gain the ability to email colleagues, merge code, or trigger production deploys, the question of which agent can do what on behalf of whom becomes non-negotiable. Scoped permissions, guardrails against catastrophic actions, and cost controls are harness responsibilities that no model upgrade can absorb — because they are not about intelligence, they are about authorization.

Efficiency is the third, and it tends to get underweighted in score-focused evaluations. The same studies that found no significant score difference across harnesses found significant cost-per-task differences. Optimizing cache hit rates, token counts, and model mix for a long-running multi-agent system can yield dramatic reductions in cost and latency with no quality drop. That optimization work lives entirely in the harness.

The Next Frontier the Flywheel Is Targeting

The coding-agent flywheel brought software engineering tasks within reach. The current generation of harness work is aimed at a broader target: all knowledge work.

Systems that compose long-lived coordinator agents orchestrating fleets of worker agents across slide decks, travel booking, Slack threads, and bug triage are now in production at a handful of companies. The complexity added back into these harnesses looks different from what was just removed: communication cadence (keeping a user informed without overwhelming them), acting-versus-asking guardrails (when does an agent send an email on your behalf versus pause and check?), and long-term memory of working style across sessions.

A concrete example: a bug reported in Slack triggers auto-triage, a cloud agent fixes it and produces before-and-after videos, and a rollout agent watches production after deployment. This is a meta-harness orchestrating many agents — and none of that orchestration structure is something the underlying models can absorb, because it encodes organizational intent, not cognitive skill.

Where This Leaves Harness Builders

A few directions are worth tracking. First, primitives over one-off integrations: rather than building a separate wake-up mechanism for each event source — a Slack post, a CI failure, a scheduled time — a single subscriptions framework that any agent can register with scales more cleanly. Second, shim tracking: deterministic patches that correct model misbehavior should be logged centrally; when a shim stops firing, it should surface automatically for removal. The harness should shed its patches as the model improves, not accumulate them indefinitely. Third, design for easy ship and unship: the flywheel is speeding up, which means the harness will get messier before it gets cleaner. Features that cannot be removed quickly become liabilities.

The higher-level picture is that earlier harnesses composed LLM calls. The ones being built now compose agents. The abstraction level has moved up by one, and the design problems have moved with it.

Yesterday’s harness — the one that injected coding intelligence — may be largely obsolete. The infrastructure, trust, efficiency, and frontier-unlocking work it is evolving into is not going anywhere. And the flywheel keeps restarting the cycle.

Text summarized and optimized using Anthropic’s models and reviewed by a human.