A stronger brain still needs an evolving body
People building agents keep returning to the same question: as models become more capable, will they eat the harnesses we build around them?
I believe models and harnesses will keep evolving together. Stronger models will absorb some supporting designs and make others unnecessary. They will also let us attempt new tasks and design new ways for agents to act.
I think of the model and harness as a brain and a body. The model handles understanding, reasoning, and decisions. The harness connects those capabilities to an environment: gathering information, calling tools, maintaining task state, and returning feedback so the model can take its next step. Here, a harness means the system that runs tasks around a model, such as Claude Code, Codex, or another agent runtime with a tool loop and state management.
For example, a model decides to open a page, fill in a form, and submit it. The harness operates the browser, collects the page and API responses, and returns them to the model to judge whether the task is complete. The decision, the action, and the result together make up the work.
A stronger brain still benefits from a better body. Better perception, more useful tools, and more flexible ways to act and receive feedback change what intelligence can accomplish. A more capable brain also changes how that body should be organized.
An old harness module can disappear while harnesses as a whole continue to evolve. The question is how the work gets redistributed as models improve.
Models eat old designs. Harnesses gain new capabilities.
Anthropic's Prithvi Rajasekaran describes this process in research on harnesses for long-running application development, published in March 2026. An early design reset context and handed off state to keep Sonnet 4.5 working. Opus 4.5 made that reset unnecessary. With Opus 4.6, the structure that divided development into sprints was removed too.
The harness also gained capabilities. In a three-agent design, a Planner expanded a brief request into a product specification, reducing the detail users had to supply. An Evaluator used Playwright to test real pages, check functionality, APIs, and database state, and send problems back to the Generator for repair. The system grew from keeping work going to developing requirements and checking results.
With Opus 4.6, planning and evaluation were adjusted to the task. Work the model could handle independently needed less checking; work near its limits still benefited from external feedback. Deletions and additions did not all follow the same model upgrade. Model capabilities, task goals, and system design changed together.
Cursor's Stefan Heule and Jediah Katz describe both removal and expansion in their April 2026 engineering retrospective. Early guardrails and large amounts of static context gave way to ways for the agent to fetch past conversations, terminal state, and relevant tools as needed. When users switch models during a conversation, the harness switches prompts and tools and adds handoff instructions to prevent the new model from calling unavailable tools. The team also added the ability to request a particular model for a subagent.
These additions change how agents gather information, hand off work, and collaborate. As models become more autonomous, we can give them more demanding tasks, creating new room for harness design.
Co-evolution includes both deliberate deletion and expansion. We can hand work back to the model when it can do that work well, while building tools, interactions, and feedback mechanisms for the next set of tasks. Both can happen within the same harness.
We are still discovering the fuel and inventing ways to use it
We are still very early in AI. We have begun discovering the fuel for a new civilization, and we are learning how to use it. Models supply capabilities; harnesses organize them into work that can actually be done.
Think of LLMs as electricity that we have only just begun to use. Some of today's harnesses are the first light bulbs: a filament and a circuit turn that energy into light. World models and other new capabilities could be another source of energy, like nuclear power. Putting that energy to work takes systems such as nuclear power plants and nuclear submarines. As models bring new capabilities, we will invent harnesses that make use of them. These capabilities and systems can also coexist and be combined.
TypeSafe's Jev is a System One Model. Models like it need corresponding System One Harnesses. Realtime voice models likewise need harnesses that handle audio streams, conversational turns, and user interruptions.
Looking ahead, 3D physics models and the various approaches described as world models may open up new tasks in spatial interaction, simulation, and action. New runtimes may serve them, or existing harnesses may expand to support them. As applications become more varied, we will keep inventing ways to connect models to their environments.
The agent use cases we have unlocked today may represent less than 1% of what we will eventually discover. Human imagination expands as models advance and new harnesses emerge. We often need to see a capability put to work before we can imagine the next thing we want it to do.
The body and brain shape each other
Think of a basketball player practicing a jump shot. Stronger legs and better balance allow a higher, more controlled jump. Practice and games teach the player to coordinate the jump with the release and choose the right moment based on the defender's position. Strength becomes a skill the player can use in a game. Better judgment also makes it clearer what to practice next. The body and brain push each other forward.
Models and harnesses can interact in a similar way. The harness determines which tools, context, and feedback a model acts on. That shapes its execution trajectories, the sequences of actions and results that may later be used for evaluation and training. A better harness can create different opportunities for a model to learn.
The July 2026 preprint Co-Harness studies alternating improvements to a harness and model parameters: analyze failures, validate harness changes, then generate trajectories with the improved system to fine-tune the model. The September preprint Harness Learning trains a proposer model to revise a solver's executable harness using execution feedback, with no parameter updates at test time. Both involve training. The difference is where the improvements take effect: Co-Harness updates model weights using trajectories from an improved harness; Harness Learning modifies the solver's external program at test time.
Each study is limited to its own experimental setting, but together they point toward an important direction. Models are beginning to help improve the systems through which agents act, and those systems can help shape subsequent learning. Models may increasingly help generate, evaluate, and maintain harnesses.
A harness written by a model still has to run as a program to read and write files, call tools, preserve state, and check results. Models are changing who designs the body and what shape it takes. The system that carries out actions and returns feedback remains.
I think this will change how harnesses are created and accelerate their interaction with model development. An athlete who masters a technique can move on to the next stage of training. Once a model learns new behaviors, its harness can evolve from that new starting point.
Even for the same task, the best setup can change
New tasks are only half the story. Even when what a user wants stays the same, the conditions for doing it keep changing. Models improve, tools evolve, reusable skills accumulate, and workflows change.
Building for agents includes redesigning their tools. A tool can change how much reasoning the model must do, how much state it must retain, and how it completes an action. Skills and workflows change with it, affecting which harness and model fit the task.
In an April 2026 article on tool design, Claude Code's Thariq Shihipar explains how TodoWrite initially helped the model follow a task list. As models improved, reminders could make them cling to a list when they needed to change course. The team replaced TodoWrite with a Task tool supporting dependencies and collaboration. Active search and Skills also changed how models gathered context. These changes happened within the same product, serving similar tasks.
Consider a hypothetical refund workflow. At first, the agent queries the order, checks the rules, calculates the amount, and calls the refund API. Later, the team provides a tool that combines rule checks and the refund operation into a verifiable transaction. The user's request has not changed, but the model no longer has to organize each operation. It can focus on deciding whether to initiate the transaction and what to do if it fails. A skill designed to prevent missed steps can be simplified, and the team can compare candidate models again. The tool has changed the difficult part of the task.
The value of a component can also change with the model. In their September 2026 study of coding-agent harness components, Run-Ze Fan and colleagues compare planning, action space, and context management. They find that the benefits depend on conditions including model capability and context budget. Planning, for example, can shift from improving accuracy for weaker models to saving cost for stronger ones. The findings are limited to the models and tasks studied, but show why a component's value depends on the combination it belongs to.
So I believe teams can converge on a best setup for a task and use it reliably for a time. What is best today may not remain best as models and tools change. Finding and maintaining the best setup is an ongoing engineering process.
Models learn more. Harnesses put those capabilities to work. We discover more things we want to do, and that drives the next round of improvement. The brain grows stronger, the body evolves, and human imagination expands with them.
Start with your own task
Run two configurations. Compare what they deliver.
Sign up and run a real task with two supported harness and model configurations. Inspect the execution and the finished work. Check task quality first, then compare cost and latency.
Run your first task