Is the Agent Harness Dead? Cursor's Early Engineer Breaks Down the Real Architecture of AI Coding Agents

From Prompt Engineering to Agent Harness: A Brief History of a Term

If you've followed AI coding tools over the past two years, you've probably noticed a pattern: every time model capabilities take a leap, the engineering practices around them get renamed. Jediah was one of Cursor's early engineers and the person on the team who worked on the agent harness the longest; he recently joined SpaceX following Cursor's acquisition. In a technical talk, he laid out this evolution clearly: in early 2023 the hottest title was prompt engineer, by mid-2025 it had become context engineer—the person responsible for assembling the best possible context for the model at runtime—and only earlier this year did the industry finally settle on agent harness and harness engineering to describe the work his team had been doing all along.

That naming delay is itself interesting. It shows that outsiders saw the model first and only later realized that what actually determines the experience is often the "shell" around the model. Jediah compares the harness to the model's "eyes and hands": users connect to the harness through the app, and the harness connects the model to the computer and to third-party services like MCP. He further splits the harness into two layers—the runtime layer handles where the agent runs, how the agent loop proceeds, and how state is stored so it can be resumed; this part is "a lot like traditional software engineering." The context and orchestration layer, by contrast, is "the Wild West": it decides when to call which model and what context the model sees, including prompts, tools, memory, compaction, and various little-known tricks. Jediah himself works mainly in this layer.

After the Peak: Why Everyone Is Saying the Harness Is Dead

Earlier this year Cursor hit what Jediah calls a "harness peak": the team used a long-running harness called Grind Swarm to build a browser from scratch. This multi-model harness orchestrated a large number of agents and machines and was extremely expensive to run. Jediah admits that building that demo probably took Cursor down once or twice.

But after the peak the winds shifted quickly. Anthropic's Tariq talked about how they deleted a significant portion of the Claude Code system prompt; YC's Gary Tan argued that harnesses would gradually disappear and that only skills matter; Jediah himself and his colleague Stefan wrote about how they removed the guardrails in Cursor that had been compensating for gaps in model intelligence—for example, they once needed a small model dedicated to applying code edits to files because frontier models couldn't do it well, plus all kinds of coding-specific instructions teaching the model how to explore a codebase and how to check its own work.

The common logic behind these voices is: models got smarter, so the harness is dead. And there's empirical support. According to two studies Jediah cites, a UC Berkeley project tested seven frontier models paired with different harnesses—Pi, Codex, Claude Code, and others—on SWE-bench Lite and found that for newer models the choice of harness had no significant effect on scores; another study from Apple and EPFL likewise found that a specialized MLE harness made no major difference on MLE-Bench.

SWE-bench (Software Engineering Benchmark) is one of the most commonly used benchmarks for evaluating AI coding ability. It collects issues and their corresponding fix patches from real open-source repositories on GitHub, and asks the model, given a codebase and an issue description, to automatically generate a patch that passes the tests; SWE-bench Lite is its trimmed subset, retaining about 300 tasks to reduce evaluation cost. MLE-Bench takes the same idea into machine learning engineering: proposed by OpenAI, it gathers real Kaggle machine learning competition problems and requires the agent to run the full pipeline from data exploration and feature engineering through training and submission, measuring end-to-end experimental engineering ability rather than single-point code generation. What these two benchmarks share is that they evaluate "model capability" and "the scaffolding around the model" in a single score, so when researchers compare scores for the same model paired with different harnesses, they are effectively separating these two sources—which is exactly why they became the core evidence in the debate over whether the harness still matters.

The Data Flywheel: The Harness Is Making Itself Redundant

Jediah is refreshingly honest in his reading of this evidence: fancy harnesses really don't add coding intelligence today. That part is true. The patches harnesses used to provide—teaching the model to explore a codebase, using mechanisms like slash goals to keep it going for long stretches, running tests to check its work—have been natively absorbed by the models.

He calls the underlying mechanism the data flywheel. The harness makes increasingly difficult coding tasks reachable, so more users can actually use agents to do those tasks, which sends more coding data back to the labs, the models natively learn those skills, and eventually the harness can delete what it originally added to get the task done. This loop explains why the claim "the harness is dead" appeared—and why it's only half right.

Compaction is a key mechanism for long-running agents. A model's context window is finite; when a conversation or task history exceeds the budget, the harness must decide what to discard, what to keep, and what to summarize into a shorter representation—that process is compaction. It differs from simple truncation: good compaction preserves the task goal, confirmed facts, failed attempts, and the current plan while compressing verbose tool output into summaries, so that an agent working autonomously for hours doesn't lose critical state. This is also why Jediah puts compaction in the context and orchestration layer—it is both an engineering technique and something that directly affects how long an agent can keep working and how much it costs. As models natively support longer contexts and better memory management, existing compaction strategies tend to get simplified or replaced, which is a concrete example of the data flywheel at work inside the harness.

Counterargument One: The Harness Opens New Frontiers

Jediah is clear that the harness is not dead, and gives two reasons. The first is that the harness unlocks new task frontiers for the model. He uses Grokbot as an example—an autonomous colleague product they built that doesn't just write code but covers all kinds of knowledge work, orchestrating a group of worker agents through a long-lived coordinator bot. He draws an analogy: it's like hiring a senior lawyer who is directly accountable to you and owns strategy, but delegates specific tasks to a team of associate lawyers.

The interesting twist is that in Cursor the team kept deleting things from the harness—deleting prompts, deleting guardrails—whereas in Grokbot they actually added a lot of that back. The reason is that new ways of working and new domains contain many tasks models haven't yet mastered: producing slide decks, critical website flows like booking travel, autonomous colleagues needing to sync progress without drowning you, the boundary between acting and asking—Grokbot can email a colleague on your behalf, but it must do so in the way you intend—and learning how you work over time through memory.

These tasks aren't novel to anyone who has written a coding agent, but they matter far more for Grokbot because everyone has similar needs, and right now it's the harness that makes those tasks feasible. Connecting this back to the data flywheel: once capabilities like coding are commoditized by models, it's the harness that unlocks new frontiers and gets the models to solve them, which restarts the flywheel. Another example is the software factory—multiple agents collaborating across the full software development lifecycle. Jediah describes the internal form: someone reports a bug in a channel, automation immediately triages it, then a cloud agent tries to fix it and uses tools to generate before-and-after videos as proof; after merge and deploy, the rollouts product spins up another agent to monitor production issues. This is almost a meta-harness orchestrating many agents.

Counterargument Two: Some Things Models Can't Absorb

The second reason is that some parts of the harness cannot be absorbed by models. Jediah lists three categories. The first is infrastructure and runtime: over the past year or so, the duration of typical tasks an agent can handle has gone from minutes to hours, days, or even longer, and that can't run on a personal laptop that goes to sleep—building a real autonomous colleague requires running in the cloud. The second is trust and security: a simple harness with just bash and all your API keys can indeed solve coding tasks, but companies need to confine permissions to specific agents and specific people, and need guardrails to prevent someone from waking up to a catastrophic operation or a $10,000 API bill.

The third is efficiency. Although the two studies above found that the harness has no significant effect on benchmark scores, both also found significant per-task cost differences. Jediah says he spent the past month focused on optimizing the efficiency of the GrokBot harness, tuning cache hit rates, token efficiency, and model combinations to significantly reduce cost and improve speed without hurting quality. His conclusion: the more you use agents to get work done, the more valuable an efficient harness becomes.

Prompt caching is one of the most important means of reducing agent running costs. In the agent loop, the system prompt, tool definitions, and conversation history are re-sent to the model every turn, and if you pay full price each time, the cost of long tasks balloons quickly. Major model vendors allow the prefix portion to be cached, with cache-hit tokens billed at a steep discount, but caches have a lifetime, a minimum length requirement, and only hit when the prefix matches exactly. So a harness's cache hit rate depends heavily on how context is assembled: put stable content first, put changing content last, and avoid inserting timestamps or random IDs at the start. Much of what Jediah calls efficiency optimization is about reorganizing context without sacrificing quality so that more tokens fall within the cache-hit range, while using model combinations to hand simple steps to cheaper models.

What Happens Next

Jediah offers several trend predictions. The flywheel is accelerating, and products are once again moving faster than models, which means the harness will get messier before it gets cleaned up, and teams need to design harnesses so new features can be easily turned on and off. One sign is that products like Grokbot increasingly hide the harness's internal workings from users, echoing Hyrum's Law—what you expose to users, they will depend on. The cost of exposing less is reduced visibility; the benefit is a lighter change-management burden and faster iteration. Another sign is a greater emphasis on designing primitives for agents: composable, extensible building-block interfaces where adding features doesn't increase agent complexity and removing them doesn't require a major refactor. One primitive they added is subscriptions, which let an agent wake up in response to events—someone posting in Slack, CI turning red on a PR, or a particular point in time—all using the same framework and tools rather than building each integration separately.

He also mentions how the team handles deterministic guardrails: these patches (like giving Grokbot a nudge when it's replying too slowly) are stopgaps, but better to fix them now than wait for the next model checkpoint. To keep the codebase from getting messier and messier, they register all shims in one place, log every time the model uses one, and then have a bot watching a dashboard that automatically opens a PR saying a given shim can be cleaned up once it stops triggering. Moreover, the harness is moving to a higher level of abstraction: the previous generation of harnesses was composed of a pile of LLM calls, while the new harness treats the agent as the core building block. He predicts that within six months, 90% of agent work will run outside the laptop.

Back to the question in the title: the part of the harness that made it better at coding really is dead—that's the flywheel at work. But the harness is how agents unlock the next task frontier, and the trust, efficiency, and infrastructure it provides aren't going away either. Yesterday's harness may be dead; tomorrow's agent harness lives on.

Hyrum's Law, proposed by Google engineer Hyrum Wright, originally means: when an API has enough users, no matter what the documentation promises, all observable behavior will be depended on by some users, so any change to an implementation detail can be a breaking change. Jediah extends this to the product level: once the logs, intermediate steps, tool-call details, and state file formats that the harness exposes internally are seen by users and written into their workflows or scripts, they become a de facto interface. This is also why a new generation of agent products tends to reduce internal exposure—at the cost of weaker debugging and observability, with the benefit that teams can freely add and remove harness internals without worrying about breaking user dependencies. For harness engineers, this law means "exposure is a promise," and visibility design is itself an architectural decision.