Former Cursor Engineer: Is Agent Harness Dead? The Data Flywheel and Three Things the Model Can't Absorb

The Three-Year Evolution of Agent Harness: From Prompt Engineer to Harness Engineering

If you've been following the AI Agent space, you've likely heard two opposing voices lately: one says Harness is dead, the other says Harness matters more than ever. Jediah Katz, a former engineer on the Cursor Agent Harness team, systematically traced the evolution of this concept and the debate around it in a talk at AI Engineer.

According to Katz's retrospective, the hottest title in early 2023 was Prompt Engineer. By mid-2025 it had evolved into Context Engineer — using code to dynamically assemble the optimal context at runtime. Only recently did the industry finally settle on the names Agent Harness and Harness Engineering.

Harness can be understood as the model's "eyes and hands": it wraps around the model and connects it to the real world. Users connect to the Harness through an application, and the Harness connects the model to the computer and third-party services like MCP. Katz breaks Harness into two layers: the Runtime layer handles where the core loop runs and how state is stored, so work can be resumed at any time; the Context and Orchestration layer decides when to call which model and what context the model can see, encompassing a large number of engineering techniques such as prompts, tools, memory, and context compression.

Agent Harness is the software layer wrapping the foundation model, responsible for connecting the model to the real world (users, tools, file systems, third-party services). It typically contains two sub-layers: Runtime (the execution environment for the core loop, state persistence, task resumption) and Context & Orchestration (prompt construction, tool calls, memory management, context compression, multi-model routing, etc.). You can think of it as the operating system to the CPU: the model provides raw intelligence, and the Harness decides how that intelligence is scheduled, constrained, and extended.

Harness Engineering refers to the engineering practice of specifically designing and optimizing this layer, involving prompt engineering, tool design, guardrail setup, cost optimization, and more, with the goal of maximizing task success rate and safety within the boundaries of the model's capabilities.

The Peak of Harness and the "Death" Declaration

Katz mentioned that Cursor once shipped a multi-model Harness called GrindStorm, which produced a browser demo coordinating a large number of Agents and machines — at a cost high enough to bring Cursor down at one point. But the peak lasted only a few months before voices saying "Harness is dead" began to appear.

Evidence for this claim came from multiple directions: Anthropic's Tariq mentioned they had deleted part of Claude Code's System Prompt; YC's Gary Tan believed Harness would gradually disappear and that in the end only Skill would matter; Katz himself and his colleagues also removed the guardrails in Cursor that made up for the model's intelligence shortcomings — for example, they once used a small model specifically to write code changes into files, because frontier models at the time couldn't do it well.

There's research support too. According to a UC Berkeley test, seven frontier models showed no significant differences in SWE-Bench Lite scores across different Harnesses like Claude Code and Codex, and the newer the model, the smaller the difference. Research from Apple and EPFL reached similar conclusions on M1 Bench.

The Data Flywheel: How Harness Makes Itself Obsolete

Katz's core explanation is the "data flywheel": the Harness makes increasingly difficult coding tasks completable, so more users genuinely use Agents to attempt these tasks, more coding data is shared with model labs, and the models eventually learn these skills natively — so the Harness can remove what it originally added to get the tasks done.

His examples are concrete: teaching the model how to explore a codebase, how to use slash commands, how to keep working for long periods, how to run tests to check its own work. These were once the Harness's responsibility, and now the model has absorbed them natively. So the accurate meaning of "Harness is dead" is: a fancy Harness can no longer add coding intelligence to the model.

But that's only half the story. Katz gives a clear answer: Harness is not dead, for two reasons.

Data Flywheel in this context refers to a self-reinforcing loop: the Harness lowers the barrier to tasks so more users try Agents, the interaction data users generate (such as code edits, test runs, and bug fixes) is fed back to model labs for training, and once model capabilities improve and natively master these skills, the Harness can remove the corresponding assistive logic. This mechanism explains why some Harness features become "obsolete," but it also means the Harness must continually migrate toward new domains the model hasn't yet mastered.

Reason One: Harness Opens the Next Frontier for Models

The first reason is that the Harness is unlocking new tasks the model hasn't yet conquered. Katz uses Grok Bot as an example — an autonomous colleague product that doesn't just write code but handles various kinds of knowledge work. Its Harness isn't a one-off conversation but a long-lived coordinator bot orchestrating an entire team of Worker Agents, like a lawyer interfacing with clients and delegating work to assistants.

The interesting twist: at Cursor they kept removing prompts and guardrails as models got stronger, but in Grok Bot they actually added many back. The reason is that the model hasn't yet mastered tasks in the new domain: key website operation flows (making slides, booking itineraries), communication (keeping users informed of progress without overwhelming them), deciding whether to act directly or ask the user first, and gradually learning the user's working style through memory.

Katz also mentions the "Software Factory" example: someone reports a bug in a channel, automation immediately triages it, spins up a cloud Agent to attempt a fix, calls tools to record before-and-after comparison videos proving the problem is solved, and after deployment rolls out the product and starts another Agent to watch production. This is almost a meta-harness, orchestrating many Agents together.

Reason Two: Three Things the Model Can't Absorb

The second reason is that some parts of the Harness can't be absorbed by the model. Katz lists three:

Infrastructure and routing. The duration of typical tasks Agents handle has gone from minutes to hours, days, or even longer, and this can't possibly run on someone's laptop. If you want an autonomous colleague, it has to run in the cloud.

Trust and safety. A simple Harness with only bash and all API keys in a single file can also complete coding tasks, but nobody wants to actually hand their keys to the model. Enterprises need permissions narrowed to specific Agents and specific people, and they need guardrails to prevent catastrophic operations or astronomical bills.

Efficiency. Although the two studies mentioned earlier found that the Harness has little impact on benchmark scores, both found significant differences in cost per task. Katz spent the past month focused on optimizing Grok Bot's cache hit rate, token efficiency, and model mix, significantly reducing cost and increasing speed without compromising quality.

Hyrum's Law was proposed by Google engineer Hyrum Wright, originally meaning: when an API has enough users, no matter what the documentation says, all observable behavior will be depended upon by some users. Katz extends this to Harness design: once a product exposes internal mechanisms (such as a particular prompt structure or tool-calling method), users will build workflows on top of them, making them hard to change later. Modern Harnesses therefore tend to hide internal implementation and expose only stable abstract interfaces.

Katz's Four Predictions

Regarding where Harness is heading, Katz offers several judgments:

The flywheel is accelerating, and product iteration speed has once again outpaced the models; the Harness will get messier before it gets cleaned up. So when building a Harness, design it so new features are easy to launch and just as easy to retire. He cites Hyrum's Law: anything exposed to users will eventually be depended upon — which is why products now expose fewer and fewer internal Harness mechanisms to users.

Designing primitives for Agents is becoming a trend. Katz's team built a "subscription" primitive: rather than building separate integrations for Slack messages, CI turning red, and scheduled events, build a framework and tools that let the model or Agent subscribe to events itself.

They use sims to centrally manage deterministic guardrails; every time a sim is triggered it's logged, and a bot watches the dashboard and automatically opens a PR to remove a sim once it stops triggering.

Harness is moving toward a higher level of abstraction: the previous generation composed a bunch of LLM calls, while the new generation treats the Agent as the core building block. Katz also predicts that within 6 months, 90% of Agent work will run off the laptop.

Primitive in Agent design refers to a minimal, composable set of foundational capability units. The "subscription" primitive designed by Katz's team is one example: instead of writing integrations separately for Slack messages, CI events, and scheduled tasks, provide a general event subscription framework that lets the model or Agent subscribe to the events it needs. The benefit of primitivization is reduced integration complexity, greater reusability, and a Harness that more easily adapts to new scenarios. This is similar to basic types and operators in programming languages: by composing primitives, rich behaviors can be built.

Conclusion

Katz's closing is crisp: the part of Harness that made it better at coding is dead — that's the data flywheel at work; but Harness is how Agents unlock the next frontier of work, and trust, efficiency, and infrastructure aren't going anywhere. Yesterday's Harness may be dead, but long live tomorrow's Agent Harness.

One-line Summary

Harness's coding-enhancement capabilities are dead, but as the cornerstone for Agents to unlock new frontiers and ensure trust and efficiency, it is moving toward a higher level of abstraction.

Paragraph Summary

Former Cursor Agent Harness engineer Jediah Katz reviewed the three-year evolution of Harness from prompt engineering to Harness Engineering. Addressing the "Harness is dead" narrative, he points out that the data flywheel has let models natively absorb coding-assist skills, so fancy Harnesses no longer add coding intelligence; but Harness is not dead — it is opening new frontiers like knowledge work for models while carrying three values the model can't absorb: infrastructure and routing, trust and safety, and efficiency optimization. Katz predicts Harness will move toward primitivization and higher abstraction, with 90% of Agent work running off the laptop within 6 months.