Is the Agent Harness Dead? — Jediah Katz, SpaceXAI
Read the talk
Is the Agent Harness Dead?
Smarter models are absorbing coding tricks that once lived in prompts and guardrails. Jediah Katz explains why that makes yesterday’s harness thinner while increasing the value of runtime infrastructure, security, efficiency, and higher-level agent orchestration.
From a talk by Jediah Katz
At a glance
Ideas worth remembering
A harness has at least two distinct responsibilities: a runtime that executes and preserves work, and a context-and-orchestration layer that controls model calls, tools, memory, and behavioral guidance.
Smarter models can absorb coding behaviors once supplied by scaffolding, including repository exploration, persistent work, file editing, testing, and self-checking.
The data flywheel explains the apparent contradiction: a harness makes harder tasks usable, usage teaches models those skills, obsolete scaffolding is deleted, and the harness moves to a new frontier.
New knowledge-work agents need fresh scaffolding for communication, risky actions, website workflows, memory, and coordination among long-lived coordinators and worker fleets.
Runtime durability, scoped permissions, security controls, and cost optimization remain harness responsibilities because model weights cannot provide persistent compute or enforce external authority boundaries.
Design temporary interventions for removal: centralize and log behavioral shims, use composable primitives such as subscriptions, and consider the visibility tradeoff when exposing internal details to users.
The harness is the model’s eyes, hands, and operating environment
Jediah Katz joined Cursor in early 2025 and described himself as its longest-tenured agent-harness engineer; he later moved to SpaceX following its acquisition of Cursor. He starts with a term that arrived after “prompt engineer” and “context engineer.” A context engineer assembles what the model should see for a particular request. A harness engineer owns a larger system: the software that wraps the model, steers it, preserves its work, and connects it to computers and third-party services. The model supplies learned capability; the harness determines how that capability enters the world.
The useful split is between two layers. Runtime controls where the core agent loop executes and how its state is stored so interrupted work can resume. This resembles conventional software engineering: processes, persistence, recovery, and execution environments. Context and orchestration decide which models run, when they run, and what they see. Prompts and tools are only the obvious pieces; memory, context compaction, and behavioral interventions also live here. Much of the “harness is dead” debate concerns this second layer, even though the runtime remains part of the same system.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Smarter models removed the need for coding-specific scaffolding
The previous high-water mark was an expensive, long-running, multi-model harness that coordinated many agents and machines to build a browser from scratch. Katz says producing that demonstration even disrupted Cursor once or twice. Yet the industry soon moved in the opposite direction: system prompts shrank, guardrails disappeared, and some builders predicted that only reusable skills would remain. Cursor itself removed interventions that had compensated for model weaknesses.
Those deleted interventions were concrete. A small auxiliary model once applied edits because frontier models could not reliably modify files themselves. Coding-specific instructions taught agents how to explore a repository, persist on long tasks, run tests, and check their own work. As models improved, keeping all of that machinery could become redundant rather than helpful.
The provocative test is a harness that offers little more than a shell—plus, in Katz’s deliberately unsafe joke, access to every secret. Katz describes a UC Berkeley study that tested seven frontier models across several harnesses, including Pi, Codex, and Claude Code. On SWE-bench Lite, he reports no significant difference in scores attributable to harness choice, particularly for newer models. Separately, he says another study found that a dedicated machine-learning-engineering harness made little difference on MLE-bench. These are his descriptions of two distinct results; the supplied material does not include the papers or numerical results.
That is the limited sense in which part of the harness is dead. Repository exploration, persistent execution, test running, and edit application used to be product-side patches for missing “coding muscle memory.” Once those behaviors became native model capabilities, the patches stopped earning their complexity.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The harness makes its own coding tricks obsolete
Katz calls the mechanism the data flywheel. A frontier harness first makes harder tasks feasible. More users can then attempt those tasks productively, producing more coding interactions that reach model labs. Models learn the recurring behaviors, so the next generation can perform them without the original prompts or guardrails. The harness can finally delete the intervention that created the training opportunity.
Deletion is therefore evidence that one turn of the flywheel succeeded, not evidence that the surrounding product has no value. Once a capability such as basic coding becomes commoditized inside the model, the harness can move outward to a harder domain or a broader part of the job. That final transition—from absorbed capability to a newly accessible frontier—restarts the cycle.
The agent-harness data flywheel
Read the diagram as text
- Harness opens a harder task. Prompts, guardrails, tools, and orchestration bring previously unreliable work within reach.
- More users attempt it. The task becomes productive enough to generate more real agent interactions.
- Labs receive more task data. Repeated interactions expose the skills needed to complete the work.
- Models absorb the skill. Behaviors such as exploring repositories and running tests become native capabilities.
- Harness deletes old scaffolding. Prompts and guardrails that no longer help can be removed.
- Harness opens a harder task → More users attempt it: makes task feasible.
- More users attempt it → Labs receive more task data: creates interactions.
- Labs receive more task data → Models absorb the skill: supports model learning.
- Models absorb the skill → Harness deletes old scaffolding: makes patches redundant.
- Models absorb the skill → Harness opens a harder task: prompts a move to a new frontier.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Grokbot puts prompting and guardrails back at a new frontier
Grokbot changes the unit of interaction. Instead of treating each request as a one-off chat, it uses long-lived coordinator bots that direct fleets of worker agents. Katz compares the coordinator to a lawyer who owns strategy and deals directly with the client while delegating pieces of work to paralegals. The coordinator maintains the relationship and overall objective; workers execute delegated tasks.
This broader job reverses the simplification seen in coding agents. Grokbot has needed new prompts and guardrails because models have not yet internalized all the behaviors required of an autonomous colleague. The product is operating in unfamiliar domains, over longer periods, with more consequential actions. Old scaffolding disappeared from coding while new scaffolding appeared around knowledge work.
Four unresolved behaviors show why:
- Website workflows: Tasks such as producing slide decks or booking travel require reliable interaction with external systems.
- Communication: A long-running colleague must report progress without flooding the user.
- Acting versus asking: Sending email may be useful, but the agent needs to know when intent is clear enough to act and when approval is required.
- Memory: The system must learn how a particular person works over time.
Experienced coding-agent users may recognize all four problems, but a general colleague encounters them routinely rather than at the edges.
The harness currently makes those behaviors feasible by structuring coordination, inserting behavioral guidance, and constraining risky actions. If models later absorb these patterns, some of that scaffolding may disappear too. The next frontier can also remain within software engineering: senior engineers spend substantial time on work beyond writing code.
Grokbot’s coordinator-and-worker topology
Read the diagram as text
- User. Supplies goals and receives updates.
- Long-lived coordinator. Owns strategy, communication, and orchestration across work.
- Fleet of worker agents. Executes delegated pieces of the larger assignment.
- User → Long-lived coordinator: sets goals and intent.
- Long-lived coordinator → Fleet of worker agents: delegates tasks.
- Long-lived coordinator → User: reports progress and requests decisions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A software factory is a harness around multiple agent stages
The software-factory example raises the abstraction again. A bug arrives in a team channel and an automation triages it. That triage can start a cloud agent to attempt a fix. The agent then produces before-and-after video evidence. After the change merges and begins deploying, another agent watches the rollout for production problems. No single model call owns the lifecycle; a “meta-harness” connects specialized agent runs to events and deployment state.
The example remains a direction rather than a solved autonomous development lifecycle. Its value is architectural: each stage has a distinct trigger and responsibility, while the outer harness coordinates work across them. Better coding models improve the fix attempt, but they do not by themselves build the event routing, deployment integration, or production watcher.
A bug moving through the meta-harness
Read the diagram as text
- Bug report. A person reports a problem in a team channel.
- Automatic triage. Automation triages the incoming report.
- Cloud fix agent. An agent attempts to repair the bug.
- Before-and-after evidence. Tooling records videos intended to demonstrate the change.
- Merge and deployment. The fix is merged and begins rolling out.
- Production watcher. A separate agent monitors the rollout for issues.
- Bug report → Automatic triage: triggers.
- Automatic triage → Cloud fix agent: may start an attempted repair.
- Cloud fix agent → Before-and-after evidence: produces videos.
- Cloud fix agent → Merge and deployment: if the fix is merged.
- Merge and deployment → Production watcher: starts production monitoring.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Models cannot absorb runtime, authority, or operating economics
Some harness responsibilities cannot migrate into model weights. Infrastructure and runtime are the first. Agent tasks have stretched from minutes toward hours and days. A sleeping laptop cannot reliably host an autonomous colleague through that duration, so execution state and compute move to persistent cloud infrastructure. A smarter model cannot keep a powered-down process alive or recover state that was never stored.
Trust and security are the second. A shell plus a file containing every API key might perform well on a coding benchmark, but benchmark capability does not make that design acceptable. Production systems need permissions scoped to particular agents and people, plus enforced limits that prevent catastrophic actions or runaway spending. Instructions can influence behavior; the harness controls what credentials and actions are actually available.
Efficiency is the third. The studies that reportedly showed similar evaluation scores across harnesses also found meaningful differences in cost per task. Katz says Grokbot’s team adjusted cache hit rate, token efficiency, and model mix, reducing cost without a reported loss of quality. His wording about speed does not establish whether it improved. The talk gives no figures or evaluation method, and does not explain how the model mix was allocated.
Efficiency compounds with adoption. A small per-task difference matters little when an agent runs occasionally; it becomes a major product and infrastructure concern when agents handle a growing share of daily work. Equal benchmark scores therefore do not imply equivalent harnesses. Reliability, authority boundaries, and cost can diverge even when the final answer score does not.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build harnesses so temporary behavior is easy to add—and remove
The flywheel is accelerating, but product requirements are again moving ahead of model behavior. That means the near-term harness becomes messier before it becomes cleaner: teams add interventions quickly, then remove them when models catch up. The engineering requirement is reversibility. A harness should make features cheap to ship, observe, and unship rather than allowing each workaround to harden into permanent architecture.
One response is to expose less of the harness’s internal machinery as a user-facing contract. Hyrum’s Law captures the risk: anything observable may acquire users who depend on it. Hiding internals reduces change-management cost and permits faster iteration, but it also reduces visibility into what an agent is doing. That is a real product tradeoff, especially when users need to inspect consequential work.
Another response is to design reusable primitives rather than one-off integrations. The example is subscriptions: an agent may need to wake when someone posts in Slack, CI turns red on a pull request, or a particular time arrives. Instead of giving every event source its own bespoke integration, one framework and one tool let the agent subscribe to an event. New triggers can then reuse the same model-facing concept.
Temporary behavioral patches receive their own lifecycle. If Grokbot waits too long to respond, a deterministic guardrail can nudge it that the user is waiting. Katz calls these patches shims: they fix current model behavior without waiting for another checkpoint. The team tracks shims centrally and logs every firing. A bot watches that telemetry; when a shim stops firing, it opens a pull request proposing removal. The workaround is observable by design, so model progress can delete code instead of leaving fossilized guardrails behind.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The next harness composes agents and moves work off the laptop
The harness is also moving up a level of abstraction. Earlier systems composed individual LLM calls; Grokbot and software-factory designs compose agents as their building blocks. Each child agent can own its own context, tools, and execution loop, while the parent system coordinates assignments and lifecycle events. This does not eliminate lower-level model orchestration—it places another control layer above it.
Katz closes with a concrete forecast: within six months, 90% of agent work will run off the laptop. That is a prediction, not an observed result. Its rationale follows from the runtime argument: agents that work for hours or days need persistent compute, resumable state, and access that survives a user closing a lid.
So the answer depends on which harness is under discussion. The coding-specific prompts and guardrails that once supplied missing intelligence are disappearing as models absorb their lessons. The harness that opens new task frontiers, coordinates agents, preserves state, limits authority, and controls cost is becoming more important. Yesterday’s harness can die while the system around tomorrow’s agents expands.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Further reading
Practical documentation for the remote execution model discussed in the talk: agents running in isolated cloud environments rather than depending entirely on a developer laptop.
Background on the organizational transition mentioned at the beginning of the recording.
Related talks
- Hard-Won Lessons from Building Effective AI Coding Agents
Examines why stronger models can outperform elaborate coding-agent scaffolding and why difficult evaluations matter.
- Building your own software factory
Extends the meta-harness example into autonomous agents, scheduled automation, observability, and architectural guardrails.
- Building Deterministic Infrastructure for Non-Deterministic AI Agents
Develops the runtime side of long-running agents, including state, retries, observability, and oversight.
Read the complete timestamped transcript
- 0:12
My name is Jediah, and I joined Cursor early in 2025, uh, 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 wanna 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
- 0:42
question that I have for us to answer today, which is: Is the Agent Harness Dead? So let's get started.
- 0:55
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 slop detectors on before lunch. Um, but no, for real. So the story starts in early twenty-twenty three when prompt engineer was the hottest title out there. By mid twenty-twenty five, that had evolved to context engineer, someone who programmatically puts the best context for the model
- 1:25
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.
- 1:40
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.
- 2:10
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.
- 2:27
And then the context and orchestration layers are kinda 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.
- 2:44
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.
- 2:59
In the new year, we kind of hit peak harness. Cursor announced that we had created a browser entirely from scratch, uh, using a new long-running harness called Grind swarm. This was a multi-model harness that orchestrated a lot of, a lot of agents and a lot of machines, and it was very expensive to run. Um, it actually took down Cursor maybe once or twice to, to get this demo. Um, now,
- 3:30
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. Gary Tan from YC thought that the harness would fade away and only skills would matter. Even myself and my colleague Stephane, we wrote about how we had removed all these guardrails that we had
- 4:00
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 code base and how to check your work.
- 4:19
So if all these people were 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.
- 4:43
Uh. 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? Who thinks so? Who thinks it would if you-- Raise your hand if you think it would. A few hands, but most of you, no. 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 Claude
- 5:13
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 SWE-bench Lite. And then another, another study from, uh, from Applin EPFL found similarly that a dedicated MLE harness did not make a big difference on an MLE-bench. So what is going on here? Is it, is it actually true that the harness is dead? Are they right? Here's what I think that the evidence
- 5:43
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, uh, how to work persistently for a very long time with things like slash goal, uh, how to run tests to check your work, the model has natively absorbed these skills.
- 6:16
So why is this happening?
- 6:20
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 well.
- 6:47
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.
- 6:58
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?
- 7:12
Is the harness really dead? I say no, and there's two reasons why. First of all, and I'm gonna 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 Grokbot?
- 7:42
Can I see some hands? Awesome. Let's go. That's great. Um, so for those of you who haven't, Grokbot 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. Not gonna sell too much, but it's a groundbreaking new product 'cause it already created a new category. Let's just talk about the harness, though. So Grokbot has a new kind of harness that operates not based off of one-off chats, but long-lived
- 8:12
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.
- 8:32
Now, something interesting about the Grokbot 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 Grokbot, 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 Grokbot is meant to solve that the models have not nailed yet.
- 9:02
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 Grokbot, 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. Grokbot can do a lot of things which are kind of risky in some sense, like emailing your colleagues. You want it to be able to do that, but you only want it 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
- 9:31
focus.
- 9:36
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 within reach.
- 9:59
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,
- 10:29
um, 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. Um, this is the core idea that I would like you to understand, this flywheel and how the model and the harness together drive it.
- 10:53
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
- 11:23
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, uh, or is, uh, merged and, and starts deploying, we have our rollouts product which kicks off another agent to watch in production for any issues.
- 11:50
So you can think of all this as almost like a meta-harness which is orchestrating many agents together. That's how I would like you to think about this. So that's the first reason that you should care about the harness, because a frontier harness is needed to be at the frontier of agentic tasks. And then the next reason is there are some parts of the harness that the model can't absorb. So let's talk about those.
- 12:16
First of all, there is the infrastructure and runtime needed to make an autonomous colleague reliable. Over the past year plus, we've gone from agents that work for on a typical task for minutes to hours to days and even longer. And there's just no way that this can work on one person's laptop, which might go to sleep. It has to be running in the cloud if you really want an autonomous colleague.
- 12:43
And then next, we have trust and security. Yes, like we saw before, uh, a simple harness with just Bash and all your, you know, all your API keys in a file can solve coding tasks, but you probably don't wanna give all your API keys in a file to the model. Um, or if you're okay with that, I'm sure that your head of security would have something to say. Um, so this is obviously really important in companies where we wanna have permissions that are scoped down to specific agents and specific people, but it's also important to have guardrails for anyone who doesn't wanna wake
- 13:13
up one morning to a really catastrophic action or to a ten thousand dollar API fee, right?
- 13:21
And then finally, there's efficiency. If you think back to those 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 Grokbot harness. Now, through tweaking variables like, uh, cache hit rate, improving that, token efficiency, um, model
- 13:51
mix, we were able to bring down the cost and the speed of Grokbot significantly for users without any hit to quality. Users have really, really been appreciating this. It's been awesome to see. Um, 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.
- 14:18
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 gonna be more things shipped. So because of this, we're expecting people to, uh, build their harnesses, design them so it's easier to
- 14:48
ship and unship new features. One way we're already seeing that manifest is with both Grokbot 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 trade-offs to giving use- lose-- 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.
- 15:18
Now, another way that we've been seeing, um, 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.
- 15:49
Agents need a way to wake up in response to events. Those might be, uh, 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 for-- or, 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
- 16:18
bad behaviors in the model. That might be, for example, if Grokbot, um, doesn't respond to the user fast enough, and we might give, 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
- 16:49
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."
- 16:58
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, uh, are using agents as the core building block. And then finally, I predict that within six months, ninety percent 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 ne-- this is not necessary in order
- 17:28
to have truly autonomous agents who can, you know, really work with us in, in the way that we want.
- 17:36
So is the harness dead? The parts that made it smarter at coding, yes, that is the flywheel at work.
- 17:46
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.