Is the Agent Harness Dead? A Cursor Engineer's Deep Dive

"The agent harness is dead"—over the past few months, this phrase has echoed repeatedly through the AI engineering community. Anthropic's Tariq stripped out most of Claude Code's system prompt, YC's Gary Tan believes harnesses will disappear, and even the Cursor team has removed a large number of guardrails that existed to compensate for model shortcomings.

But Jediah Katz, an early core engineer at Cursor, offers the opposite answer: What's dead is the old harness that "patched intelligence"—the new harness that truly carries infrastructure, trust, and efficiency has only just begun. His frameworks of the "data flywheel" and "new frontier" offer one of the clearest perspectives available today for understanding harness evolution.

What Is an Agent Harness: The Model's Eyes and Hands

Jediah defines a harness as the layer that "wraps the model, steers it, and connects it to the world." Users connect to the harness through an application, and the harness in turn connects to models, computers, and third-party services (such as MCP).

He breaks it into two layers:

• Runtime layer: Determines where the agent loop runs and how state is stored so tasks can be resumed. This layer is closer to traditional software engineering, emphasizing stability and recoverability.
• Context and orchestration layer: Determines when to invoke which model and what context the model sees. This includes prompts and tools, as well as easily overlooked techniques like memory and compaction. Jediah calls this the "Wild West."

Understanding this layering is the prerequisite for judging whether "the harness is dead"—because the two layers are affected by model evolution in completely different ways.

The Evidence: As Models Get Stronger, the Harness's Gains Really Are Disappearing

In mid-2025, Cursor used a long-running harness called Grind Swarm to build a browser from scratch, with multi-model, multi-machine orchestration—at the cost of "taking Cursor down once or twice." That was the harness's peak moment. Yet just a few months later, the "harness is dead" voices began to rise.

Supporting this judgment is not just practitioners' intuition but empirical research. According to two studies Jediah cites:

• A UC Berkeley study: Tested 7 frontier models across various harnesses including Pi, Codex, and Claude Code, finding that for newer, smarter models, the choice of harness made no significant difference in SWE-bench Lite scores.
• A joint study by Apple and EPFL: Similarly found that specialized MLE harnesses made little difference on MLE-bench.

Jediah candidly acknowledges this conclusion: "Fancy harnesses no longer add coding intelligence today—that's true." The guardrails that once taught models to explore codebases, work persistently over long periods, and run tests to verify results have already been natively absorbed by the models.

SWE-bench Lite and MLE-bench are the evaluation benchmarks used in the two studies above, and understanding their construction helps determine the scope of the conclusions. SWE-bench was proposed by Princeton University and other institutions; it draws issues and corresponding fix patches from real GitHub repositories, requiring agents to generate code changes that pass hidden tests. Lite is a streamlined version after filtering out ambiguous samples—about 300 problems—and is widely used for harness comparisons due to its manageable cost. MLE-bench, launched by OpenAI, is derived from Kaggle competitions and evaluates an agent's end-to-end machine learning engineering ability across data cleaning, feature engineering, training, and submission. What both share is: clearly defined tasks and automatically determinable success signals, making them particularly suited to measuring "coding intelligence." But this also means they struggle to reflect the dimensions where harnesses truly excel—long-running execution, permission boundaries, human-agent collaboration, and cost constraints. This is precisely why the research shows converging eval scores while per-task costs still differ significantly.

The Data Flywheel: How the Harness Makes Itself Redundant

This is the core mechanism of the entire talk. Jediah calls it the "data flywheel":

1. The harness makes increasingly difficult coding tasks accessible;
2. More users can effectively attempt these tasks with the help of agents, generating more coding data;
3. The data flows back to model labs, and models natively learn these skills;
4. The harness deletes the patches originally used to make tasks work.

This cycle explains a counterintuitive phenomenon: The harness's greatest success is making part of its own functionality obsolete. But the flywheel doesn't stop there—once coding ability is commoditized by models, it's precisely the harness that opens the next frontier and gets the flywheel spinning again.

Why the Harness Isn't Dead: Two Irreplaceable Reasons

Reason One: The Harness Opens New Frontiers

Jediah uses GrokBot as an example—an autonomous colleague product for knowledge work, employing a long-lived coordinator bot that orchestrates a group of worker agents, akin to "a senior lawyer with a team of paralegals."

The interesting reversal is: in Cursor, the team keeps deleting prompts and guardrails, while in GrokBot they add these things back. The reason is that in new domains (creating presentations, booking travel, communications, judging "act or ask," cross-temporal memory), models haven't yet mastered the skills—the harness is key to making these tasks feasible.

This logic extends to software engineering itself: the more senior the engineer, the less code they write, and the harness must cover responsibilities beyond coding. Further still is the "software factory"—after a bug is reported, it's automatically triaged, a cloud agent is launched to fix it, before-and-after comparison videos are left, and after merging and deployment, another agent monitors production. This is essentially a meta-harness, orchestrating multiple agents to collaboratively complete the entire development lifecycle.

Reason Two: What Models Cannot Absorb

• Infrastructure and runtime: Task durations have expanded from minutes to hours, days, or even longer—impossible to run on a laptop that goes to sleep. They must run persistently in the cloud.
• Trust and security: A minimal harness with only bash and all your API keys can indeed solve coding problems, but no one wants to hand their keys to a model. Permissions need to be narrowed to specific agents and specific people, and guardrails are needed to prevent "waking up to a catastrophic operation or a $10,000 API bill."
• Efficiency: Although the two aforementioned studies found little difference in eval scores, both found significant differences in per-task cost. Jediah reveals that he spent the past month focused on optimizing GrokBot's cache hit rate, token efficiency, and model composition, substantially reducing cost and improving speed without sacrificing quality.

MCP (Model Context Protocol) is the standard channel through which harnesses connect to third-party services in this article, proposed and open-sourced by Anthropic in late 2024. It defines a client-server protocol: external tools, data sources, or services expose capabilities by implementing an MCP server (e.g., reading/writing databases, calling ticketing systems, accessing files), and the harness, as an MCP client, injects these capabilities into the model context in a unified format. Its value lies in consolidating "a private plugin for every service" into a reusable interface layer, so the harness doesn't need to adapt separately for each integration. However, MCP only solves "how capabilities are described and invoked"—it does not solve permission narrowing, auditing, or cost control. These remain the harness's own responsibilities, which also explains why Jediah believes the infrastructure layer won't be absorbed by models.

Why cache hit rate and token efficiency have become focal points of harness optimization is directly related to the billing and inference mechanisms of mainstream LLM APIs. Most providers offer prompt caching for request prefixes: if the beginning portion of consecutive requests (system prompt, tool definitions, early conversation) is exactly identical, that portion can be billed at a substantial discount or even skip redundant computation, while significantly reducing first-token latency. Conversely, any subtle change invalidates the cache, and cost and latency rise accordingly. Therefore, when designing context, the harness must deliberately keep the prefix stable, place volatile content later, and control history compaction strategies. This also shows that "significant per-task cost differences" are no accident: with the same model and task, different context orchestration can produce several-fold cost differences—and this capability cannot be absorbed by model weights.

Next Steps: Five Evolution Trends for Harnesses

Jediah's predictions for the future can be summarized in a few points:

• The flywheel is accelerating, and products are once again running ahead of models. Harnesses will become messy before they become tidy, so designs should make features "easy to add, easy to remove."
• Fewer harness internals will be exposed to users. He cites "Hiram's Law": whatever is exposed to users, users will depend on. Reducing visibility buys lower change-management costs and faster iteration.
• Design primitives for agents. For example, a unified "subscription" primitive that lets agents respond to events like Slack messages, CI turning red, or specific times—rather than building separate integrations for each event type.
• Centralized tracking shim. Those deterministic guardrails added to patch model behavior (like reminding "the user is waiting for you") will be centrally logged; when a shim stops triggering, a monitoring bot will automatically file a PR suggesting cleanup.
• Abstraction levels are moving up. The previous generation of harnesses was composed of a chain of LLM calls; the new generation (like GrokBot and software factories) uses agents as the basic building blocks.
• Within six months, 90% of agent work will leave the laptop and run in the cloud.

Conclusion: The Old Harness Is Dead, Long Live the New Harness

Jediah's conclusion is sharp and dialectical: the part of the harness that made it smart is indeed dead—that's the flywheel at work. But the harness as a vehicle for opening new task frontiers and providing trust, efficiency, and infrastructure will not disappear.

For builders, this points to a pragmatic direction: stop writing guardrails that teach models how to code—those will be swallowed by the next checkpoint. Instead, invest in runtime reliability, permission security, cost efficiency, and designing composable primitives for new domains. Yesterday's harness is dead; long live tomorrow's agent harness.