Is the Agent Framework Dead? A Cursor Engineer Counters with Data

Is the Agent Harness Really Dead? A Hardcore Breakdown from a Cursor Engineer

Recently, a translated talk video on Bilibili sparked discussion in the AI coding community. The speaker is Jediah, a senior engineer at Cursor who joined in early 2025 and is the longest-serving engineer on the agent harness team; he recently joined the company as part of its acquisition by SpaceX. In his talk, he confronts a pointed question: Is the agent harness dead?

The backdrop is that over the past few months, several industry thought leaders have publicly written off the harness: Anthropic's Tariq said they deleted most of Cloud Code's system prompts; YC's Gary Tan believes the harness will fade and only skills matter. Even Jediah and his colleagues wrote articles about how they removed the guardrails in Cursor that existed to compensate for the model's intellectual shortcomings.

Jediah doesn't dodge these claims. Instead, he uses research and product practice to give a more nuanced answer: The part of the harness that makes it smarter is indeed dying, but the harness itself will not die.

From Prompt Engineering to Agent Harness: The Evolution of a Concept

Jediah first traces the shift in industry terminology. In early 2023, the hottest title was prompt engineer; by mid-2025, it became context engineer, responsible for programmatically assembling the best context for the model dynamically; and only recently has the industry finally settled on agent harness and harness engineering to describe the work the Cursor team had long been doing.

He breaks the harness into two layers. The runtime layer is the foundation: it controls where the core agent runs, how the agent loop executes, and how state is stored to support task resumption—this part is much like traditional software engineering. The context and orchestration layer is more like the "Wild West," deciding when to call which model and what context the model sees—including prompts, tools, and mechanisms like memory and compaction. This is the part most people mean when they talk about the harness.

SWE-bench Lite is a streamlined version of SWE-bench, used to evaluate a language model's ability to solve real GitHub issues. The full SWE-bench contains 2294 tasks from 12 popular Python repositories, while the Lite version selects 300 tasks, maintaining representativeness while greatly reducing evaluation cost. Each task requires the model to modify the codebase according to the issue description and verify the fix via hidden unit tests. This benchmark has become an important yardstick for measuring the practical engineering ability of coding agents, and is the core experimental platform for discussing harness effects in this article.

The "Peak Harness" and the Subsequent Wave of Doubt

Cursor once used a long-running harness called Grind Swarm to build a browser from scratch, orchestrating many agents across multiple models and machines. It was extremely costly, even causing Cursor's service to go down briefly once or twice. But just a few months later, the internet began saying the harness was dead.

The evidence for this view is not unfounded. According to Jediah, a UC Berkeley study ran seven frontier models on multiple harnesses—Pi, Codex, Cloud Code, and others—on SWE-bench Lite, and found that on newer, smarter models, the choice of harness had no significant effect on scores. Another study from Apple and EPFL also found that specialized MLE harnesses made little difference on MLE-bench.

Jediah accepts this conclusion: fancy harnesses indeed no longer add coding intelligence today. Skills that once required hand-holding the model—exploring the codebase, working continuously over long periods, running tests to check results—have been natively absorbed by the models. The reason is what he calls the "data flywheel": the harness brings harder coding tasks, more users can complete these tasks with the help of agents, more coding data flows back to the labs, the models natively learn these skills, and so the harness can delete the patches it once added to get tasks working.

Why the Harness Won't Die: Two Core Reasons

Reason 1: The Harness Opens New Task Frontiers for Models

Jediah uses Cursor's autonomous colleague product GrokBot as an example. It uses a new type of harness, not based on one-off conversations, but orchestrated by a long-lived coordinator bot that manages a group of worker agents—like a senior lawyer who is directly accountable to you and owns the strategy, delegating specific matters to a team of paralegals.

Interestingly, in Cursor they have been deleting things from the harness, but in GrokBot they are adding back lots of prompts and guardrails. Because in new scenarios—making slides, booking travel, proactive communication, distinguishing "act or ask," learning user habits through memory—the model hasn't mastered them yet. These tasks let the data flywheel complete its final loop: when coding ability is commoditized by models, it is precisely the harness that opens new frontiers and restarts the flywheel.

Another example is the "software factory": bugs are automatically triaged, a cloud agent attempts fixes and proves them with before-and-after videos, and after merge and deploy another agent monitors for issues in production. This amounts to a meta-harness orchestrating multiple agents.

Reason 2: Some Harness Components Cannot Be Absorbed by Models

Jediah lists three categories the model can't eat.

Infrastructure and runtime. Agent tasks are extending from minutes to hours, days, or longer; they cannot run on a personal laptop that goes to sleep—they must go to the cloud.

Trust and security. A simple harness with only bash and plaintext API keys can indeed solve coding problems, but you wouldn't really hand all your keys to the model. Enterprises need to narrow permissions to specific agents and specific people, and need guardrails to prevent catastrophic operations or a $10,000 API bill.

Efficiency. Although the two studies above found little difference in eval scores, both found significant differences in cost per task. Jediah spent the past month focused on optimizing the efficiency of the GrokBot harness—tuning cache hit rates, token efficiency, and model combinations—significantly reducing cost and improving speed without sacrificing quality.

Hyrum's Law, proposed by Google engineer Hyrum Wright, means: when an API has enough users, no matter what you promise in the documentation, all observable behavior will be relied upon by some users. In the context of agent harnesses, this means that once an internal mechanism (such as a particular prompt format, tool call order, or state storage method) is exposed to users or developers, it forms a de facto contract, and subsequent changes will face compatibility burdens. Therefore Jediah advocates reducing the exposure of harness internals to users, to lower change costs and speed up iteration.

Data Flywheel is the key concept for understanding the harness's self-obsolescence mechanism. Its loop logic is: the harness lowers the barrier to use, letting more users complete harder coding tasks with agents; these tasks generate large amounts of high-quality coding trajectory data (including successful and failed attempts, code changes, test results, etc.); the data flows back to model labs for training; the models natively acquire skills that previously required harness patches; and so the harness can remove those patches. The flywheel spins faster and faster, causing the "teaching the model to do things" part of the harness to be continuously commoditized—but precisely because of this, the harness can free up energy to open up new task domains the model has not yet mastered, restarting the flywheel again.

Next: Where the Harness Is Heading

Jediah offers several predictions. The flywheel is accelerating, products are once again running ahead of models, and the harness will get messy before it gets cleaned up—so it needs to be designed so new features can be easily shipped and rolled back. One manifestation is that fewer and fewer harness internals are exposed to users—per Hyrum's Law, whatever is exposed to users will be relied upon, so less exposure means lighter change management and faster iteration.

Another trend is designing primitives for agents. Primitives are composable, extensible building blocks: adding features doesn't increase agent complexity, and removing features doesn't require major code changes. He gives the example of a "subscription" primitive: agents need to be woken up in response to events—someone posts in Slack, a PR's CI turns red, or a certain time is reached—handled by one framework instead of separate integrations for each.

They also centrally track all "shims"—deterministic guardrails added to patch bad model behavior, like a nudge when GrokBot replies too slowly. Every time a model triggers a shim it is recorded, and a bot watches the dashboard; when a shim no longer triggers, it automatically files a PR saying it can be removed.

Finally, Jediah judges that the harness is moving toward a higher level of abstraction: the previous generation of harnesses was composed of a bunch of LLM calls, while the new generation treats the agent itself as the core building block. He also predicts that within six months, 90% of agent work will run off the laptop.

Conclusion: Yesterday's Harness Is Dead, Tomorrow's Harness Lives On

Back to the original question, Jediah's answer is layered: the part of the harness that makes it smart at coding is indeed dead—that's the data flywheel at work; but the harness as a vehicle for opening new task frontiers, providing trust, efficiency, and infrastructure will not disappear. In his words—yesterday's harness may be dead, but long live the long-lived agent harness.

For developers, the practical takeaway from this discussion is: don't get stuck on the binary question of "should I use a harness"; instead focus on the harness's value in cost, security, long-running operation, and new task domains—precisely what the model itself cannot replace.

One-line Summary

Cursor engineer Jediah breaks down the life and death of the agent harness: the coding intelligence part is dead, but new frontiers, trust, and efficiency keep it alive.

Paragraph Summary

Cursor senior engineer Jediah responds to the industry's claim that the "Agent Harness is dead." He acknowledges that UC Berkeley and Apple/EPFL research shows that on smarter models, harness choice has no significant effect on coding benchmarks like SWE-bench, and fancy harnesses no longer add coding intelligence—attributed to the "data flywheel," where task data brought by the harness lets models natively learn skills, obsolescing patch-style guardrails. But the harness won't die: it opens new task frontiers for models (e.g., GrokBot knowledge work, software factories), and infrastructure, trust/security, and cost efficiency cannot be absorbed by models. Future trends include reducing internal exposure, designing composable primitives, automatically tracking and cleaning up shims, and 90% of agent work moving to the cloud within six months.