更聪明的模型杀死了 Harness？智能体脚手架的消亡与下一代演化

My name is Jedidiah and I joined Cursor early in 2025 as the longest tenured engineer working on our agent harness and recently I came along to SpaceX as part of the acquisition of Cursor. So, today I want to talk to you all about how the agent harness has evolved to where we are today and where I think things are going. And there's a motivating question that I have for us to answer today, which is is the agent harness dead? So, let's get started.

Here's a more natural and flowing version of that script which reads like a cohesive conference talk rather than a series of short points. Oops. Just making sure everyone's still got their soft detectors on before lunch. Um no, for real. So, the story starts in early 2023 when prompt engineer was the hottest title out there. By mid-2025, that had evolved to context engineer, someone who programmatically puts the best context for the model together on the fly. And then only at the beginning of this year did the industry land on the term agent harness and harness engineering to describe work that my team and I have been doing for a while.

So, what's in an agent harness? The harness is like the eyes and the hands for the model. It wraps around the model, steers it, and connects it to the world. Users connect to our harness through apps and then the harness connects the model to computers and also to third-party services like MCPs.

I like to divide the harness into two layers, the runtime and the context and orchestration layers. The runtime is kind of like the foundation of the harness. It controls where the core agent loop runs and how state is stored so that work can resume. Building this foundation is a lot like traditional software engineering. And then, the context and orchestration layers are kind of like the wild west. This is what a lot of people refer to when they talk about the harness. These parts of the harness control which models are called when and what context they see. That includes things like prompts and tools, of course, but also memory compaction and a bunch of tricks you might not know that we do to make the agent behave in the way that we want. So, this is the area that I primarily work in.

In the new year, we kind of hit peak harness. Cursor announced that we had created a browser entirely from scratch using a new long-running harness called Grind Swarm. This was a multimodal harness that orchestrated a lot of agents and a lot of machines and it was very expensive to run. It actually took down Cursor maybe once or twice to get this demo.

Now, like anything in the world of agents, it only took a few months of peak harness for people online to start saying that the harness was dead. Tariq from Anthropic talked about how they had killed much of the system prompt from Claude Code. Garry Tan from YC thought that the harness would fade away and only skills would matter. Even myself and my colleague Stefan, we wrote about how we had removed all these guardrails that we had in cursor to patch over gaps in the model's intelligence. We used to have things like a small model just to apply code edits to a file because the frontier models weren't good at this. We also had all sorts of coding specific instructions like how to explore the codebase and how to check your work.

So, if all these people are saying the harness is dead, they were saying that smarter models are what killed it. And there's a lot of evidence for that. I want you all to think about a very simple harness where the model only has access to the shell and to all of my secrets. Please don't screenshot this slide by the way. This one's off limits. So, who here thinks that this really simple harness would do just as well on coding evals as a more sophisticated one? Maybe some hands who thinks it would? Raise your hand if you think it would. A few hands, but most of you know.

So, a few recent studies tried to investigate exactly that question. The first one out of UC Berkeley tried seven different frontier models on a series of harnesses including Pi, Codex, and Cloud Code. And what they found, particularly on the newer smarter models, is that the choice of harness did not actually make a difference significantly in the score on SweetBench light. And then another study from Apple and EPFL found similarly that a dedicated MLE harness did not make a big difference on MLEBench.

So, what is going on here? Is it actually true that the harness is dead? Are they right? Here's what I think that the evidence shows. A fancy harness in this day and age, no longer adds coding intelligence. I think that is true. I know that's surprising. But, these things that we used to do in the harness to patch over gaps in the raw coding muscle memory of the model, like teaching it how to explore the code base, how to work persistently for very long time with things like slash goal, how to run tests to check your work. The model has natively absorbed these skills.

So, why is this happening? It turns out the harness is actually making itself obsolete through what I call the data flywheel. So, in this process, the harness brings harder and harder coding tasks within reach. At that point, more users can productively attempt those tasks with agents. That means more coding data is shared with the labs. And eventually the models learn natively how to do these skills as well. Eventually, the models get so good that the harness can actually delete the things it needed to do to make those tasks work in the first place. It's a very interesting process.

So, that's how you get people saying that the harness is dead. And if the models are good enough to code well in any harness, then why should you care? Does it really matter which harness you use? Is the harness really dead? I say no, and there's two reasons why. First of all, and I'm going to go into both these points, the harness actually opens the new frontier of tasks for the model to solve. And then, second, there are some tasks or some parts of the harness, especially outside the context layer, which the model cannot absorb.

So, to first talk about how the harness unlocks the next frontier, I want to talk about Grokbot. Who here has tried Grockbot? Can I see some hands? Awesome. Let's go. That's great. Um so, for those of you who haven't, Grockbot is our autonomous colleague who gets work done for you. Not just coding, but all kinds of knowledge work. And I really recommend you try it. I'm not going to sell too much, but it's a groundbreaking new product. It's already created a new category. Let's just talk about the harness, though.

So, Grockbot has a new kind of harness that operates not based off of one-off chats, but long-lived coordinator bots that orchestrate a fleet of worker agents. You can kind of think of it like hiring a high-powered lawyer who deals with you, you know, directly and owns strategy, but they farm out their tasks to a team of paralegals. It's like that.

Now, something interesting about the Grockbot harness is I mentioned how in Cursor we found ourselves removing things from the harness, removing prompting, removing guardrails as the models got smarter. But, curiously in Grockbot, we've actually found ourselves putting back a lot of these things, adding new prompting, adding new guardrails. And that's because there's a lot of new tasks in this new way of working, in the new domains that Grockbot is meant to solve, that the models have not nailed yet.

To give a few examples of those kind of things, just a few things that we're focused on right now when it comes to Grockbot, there's key website flows like making slide decks and booking travel, communication. An autonomous colleague needs to keep you up to date on what it's been doing without overwhelming you. Acting versus asking is another big one. Grockbot can do a lot of things which are kind of risky in some sense, like emailing your colleagues. You want us to be able to do that, but you only want us to do it in the way that you intended. And then, of course, learning over time the way that you work through memories is another big focus.

So, those of you who might have pushed the boundaries with coding agents might have noticed that none of these tasks are new. But, for GrokBot, they're much more important because everybody is needing them in some way. And right now in GrokBot, it is the harness that is making these tasks feasible. Of course, the model is a big part of that, but the harness is helping bring them into its own reach.

So, going back to our data flywheel, GrokBot, that example, lets us fill in the last the last arrow in our cycle, which is when a capability like coding gets commoditized by the model, it's actually the harness which unlocks a new frontier for the model to then solve and kicks off that flywheel again. So, that might look like, you know, taking on new tasks outside of the coding domain, as we just saw with GrokBot, or it could just mean taking on tasks in the software engineering job beyond pure coding. I'm sure some of you here are, you know, pretty senior in your software careers, and you might know the more senior you get, the less coding you're actually doing. So, there's a lot of other things in the job that matter.

This is the core idea that I would like you to understand, this flywheel and how the model and the harness together drive it.

One more example of how the harness can unlock new frontiers is some of you may have heard of this idea of the software factory, where you have multiple agents coordinating together to solve the full software development life cycle. Now, this is far from a solved vision, but there's a lot of industry or there's a lot of innovation happening across the industry at the harness.

To give an example of how this might manifest, you know, internally, we have a lot of channels where someone might report a bug to that channel, and then an automation immediately auto triages that bug. Then it might kick off a cloud agent to try to fix the bug, and that agent will use our tooling to show before and after videos to prove that it's fixed. And then, once that fix is deployed and or is merged in and starts deploying, we have our rollouts product, which kicks off another agent to watch in production for any issues. So, you can think of all this as almost like a meta harness, which is orchestrating many agents together.

So, beyond unlocking the frontier, the other big reason the harness is not dead is that there are many other parts of the harness that the model cannot natively absorb. Now, I have three of them here. I don't have too much time to talk about them, but environment is one. There is no way that the model is going to natively absorb running a cloud container for you. And if you're not running a cloud container, then you're running on your laptop. And running a 12-hour agent run on your laptop is not a great experience.

Second is trust. You know, you might think, "Oh, the models are getting smarter. I can just trust them with all my secrets." Well, I hope that you don't. Um or if you're okay with that, I'm sure that your head of security would have something to say. There are many aspects of building trust that cannot be solved by a smarter model. You need deterministic safety guardrails. You can't have a model with a 99% accuracy rate deciding whether to confirm or to take a really catastrophic action or to a $10,000 API fee, right?

And then finally, there's efficiency. If you think back to to two studies I showed, where the choice of harness did not make a significant difference in eval scores, both of those studies actually found that there was a significant difference in cost per task. I have personally been focused over the past month on optimizing the efficiency of the Grok Bot harness. Now, through tweaking variables like cache hit rate, improving that, token efficiency, model mix, we were able to bring down the costs and the speed of Grok Bots significantly for users without any hit to quality. Users have really, really been appreciating this. It's been awesome to see.

Now, it could be an entire different talk about how we did this, but the key takeaway here is that the more and more that you use agents to do your work, the more it matters, the more valuable it will be for you to have the most efficient harness.

So, by now you might be convinced that the harness still matters. Then you might be asking, "What's next?" Here's a few trends that I'm anticipating.

First of all, that flywheel is speeding up, and right now we've entered a new age where the product is once again moving faster than the model. That means that the harness is going to get more messy before it gets cleaned up. There's going to be more things shipped. So, because of this, we're expecting people to build their harnesses, design them so it's easier to ship and unship new features.

One way we're already seeing that manifest is with both Grok Bot and other similar products, less and less of the harness inner workings are being exposed to the user. Some of you may have heard of Hyrum's Law, which says that anything that you expose to users, they will come to depend on. Now, obviously there are tradeoffs to giving users less, you know, less visibility into what's happening, but one advantage is that there's less change management to deal with, and you can iterate much faster.

Now, another way that we've been seeing this trend manifest is a bigger focus on designing primitives for agents. Primitives are like building block interfaces that can be composed and extended into powerful features. When you have primitives, you can add new features without making things more complicated for the agent, and you can remove features without having to do a complicated refactor in your code base. It's just good engineering. One example across our agent harnesses of a primitive we've added is called subscriptions. Agents need a way to wake up in response to events. Those might be someone posting in Slack, CI going red on a PR that the agent cares about, or just a certain time of day. Now, rather than having one separate integration, you know, having separate integrations for each of these things, we have one framework and one tool that the model can use or the agent can use to subscribe to an event.

And then another cool thing that we do, I mentioned earlier that we have these deterministic guardrails to patch over bad behaviors in the model. That might be, for example, if GrokBot doesn't respond to the user fast enough, and we might give it a little nudge and say, "Hey, user's waiting on you." Now, we'd rather not do these things. They're kind of like hacks, but we would rather fix them now than, you know, wait for the next model checkpoint to to get released. So, in order to make our code base, you know, be less messy and and have less of a worse time iterating the future, we track all these things, which we call shims centrally, and every time the model uses one, it gets logged. So, now we have a bot who watches this dashboard, and whenever a shim stops firing, that model or that agent will put up a PR and say this shim can be cleaned up.

Another thing that I think is next for the harness is it is moving up to a higher level of abstraction. Yesterday's generation of harnesses were built from composing a bunch of LLM calls. Now, the new harnesses we're seeing, like GrokBot and the software factory, are using agents as the core building block.

And then finally, I predict that within 6 months, 90% of agent work is going to run off the laptop. This is already where things are going, and I think there's just no way that, you know, this is this is not necessary in order to have truly autonomous agents who can, you know, really work with us in in the way that we want.

So, is the harness dead? The parts that made it smarter at coding, yes, that is the flywheel at work. That is the flywheel at work. But, the harness, as we saw, is how the agents can unlock the next frontier of work. And then also the trust, the efficiency, the infrastructure that the harness brings, those things are not going anywhere. So, yesterday's harness may be dead, but long live the agent harness of tomorrow. Thank you.