Why the harness matters
Consider a coding agent asked to make a change to an existing application. It needs to understand the relevant code, make its changes and test them. If the task exceeds a single session, it also needs an accurate record of what it has completed and what remains outstanding. Anthropic's research on long-running agents (2025) describes failures in precisely these areas. Agents attempted too much in one session, left work in an unclear state, or treated an incomplete application as finished. Its approach used structured progress records and incremental work, with explicit checks to establish whether features worked as intended.
The harness can also affect measured performance. In a 2026 engineering write-up, LangChain reported moving its coding agent from outside the top 30 into the top five on a public terminal-agent benchmark through harness changes alone. Those changes included better verification and context management. This is a vendor-reported benchmark result, so it should not be treated as an estimate of enterprise productivity. It does, however, give a reason to evaluate the model and its runtime together.
A changing boundary between model and platform
Some harness logic compensates for limitations in the model, such as difficulty maintaining progress over a long task and inconsistencies in output despite the same or similar prompts. As models improve, teams may be able to simplify that logic. At the same time, and pulling in the opposite direction, harnesses are becoming reusable software components. In recent months, model vendors both absorbed harness behaviour into their models and shipped harnesses as supported products, through SDKs and hosted agent platforms.
LangChain's description of harness architecture discusses this relationship between model training and harness design. Behaviours supported by the harness can become part of what subsequent models learn to do more effectively.
I would be cautious about interpreting this as the eventual disappearance of the harness. There will be nuance around what works well for specific tasks, and some elements of harness value may change with model releases but, for example, a model becoming better at planning does not mean your specific scaffolding will be adhered to any more consistently. There's also the element of harness memory being profile specific that is tricky to replicate. My expectation is that the balance of engineering effort will continue to change, with less effort spent correcting particular model behaviours and continued work on integration to a user or organisation's development processes, focus on consistency, and also addressing the inevitable new model behaviours.
It's worth calling out that part of what makes a harness reusable is the connections and tooling are converging on shared standards rather than bespoke integrations. Model Context Protocol (MCP) has become the common way for agents to reach tools and data, and agent-to-agent and editor-to-agent protocols are emerging for the cases where agents coordinate with each other or with a developer's environment. These standards matter for the same reason the harness does. They decide how a tool is exposed, how one agent presents itself to another, and, increasingly, how an agent proves whose authority it acts under. Identity and access for agents is an active area of work, and it sits closer to the durable, organisation-owned layer than to the model.
Context needs active management
The information available to an agent is likely to change as it works. Tool calls accumulate, earlier instructions become less relevant, and some decisions need to remain available throughout the task. Managing this well is a substantial part of harness design. Chroma's Context Rot research found that models' performance could deteriorate as input length increased, even when the task itself remained consistent. The findings challenge the assumption that a larger context window automatically makes an agent more reliable.
Compaction, which summarises earlier context to make room for new information, helps an agent continue working. It also creates a point at which detail can be lost. Teams should test whether the agent retains important requirements after compaction and whether it can retrieve the underlying evidence when needed.
For enterprise deployments, I would keep enforceable permissions outside that conversational history. A restriction on accessing or changing a record should remain in force regardless of how the agent summarises its previous work. Context management and access control have different responsibilities, even when both influence the same action.
For those running the likes of Hermes, OpenClaw, or another alternative, managing memory over time is also an important element of how effectively your harness and tooling will handle development tasks consistently, and is closely linked with context management. It's a topic that warrants a deeper conversation, especially because evaluation is a little trickier than simply comparing barebones harnesses or switching models, but you should consider persistent memory (memory, user md files) as requiring management and iterative adjustments over time.
Where the agent runs changes the controls it needs
The research also raises a deployment question that can be easy to overlook. Running an agent on a developer's machine, in an automated build pipeline, or as a hosted service creates different operating conditions.
On a developer's machine, the immediate questions concern local files, available credentials, and approval prompts. In a pipeline, the agent needs a workload identity with permissions appropriate to the job. There may be nobody present to approve an unexpected action. A hosted agent brings additional questions about session isolation, retained state and how operators investigate or stop work already in progress. Approval of a tool for interactive use should not automatically extend to unattended operation.
Data location or residency also needs to be assessed across the workflow. The execution environment, model endpoint and connected tools may each process information in different places. Logs and retained session data need to be included in that assessment. This connects directly to the sovereignty discussion: organisations need a clear account of where their dependencies sit and which operational decisions they control.
Cost and portability need a wider view
For agent workloads, the cost of a completed, acceptable task is a more useful measure than token price alone. An agent may make repeated attempts, call paid tools or require substantial review. A cheaper model can therefore produce a more expensive outcome, while a more capable model may justify its price if it completes the same work with fewer attempts. Headline prices are themselves unstable: the same nominal price can consume more tokens per task after a tokenizer change, and per-token prices have moved up as well as down, which is a further reason to measure the cost of the finished task rather than the sticker price. Either conclusion needs evidence from the actual workload.
Evaluation should include the human effort required to accept the result. Producing changes faster has limited value if reviewing and correcting them consumes the time saved.
Portability deserves similar attention. Switching a model endpoint may be relatively straightforward, but moving an agent's stored state, tool integrations and approval processes can require considerably more work. During platform selection, I would ask teams to demonstrate what they can export and what they would have to rebuild. That gives a more useful account of dependency than a list of supported models.
What to examine next
A worthwhile starting point is a bounded task with a clear definition of completion, evaluated in the environment where it will run, including interruptions, failed tool calls, and attempts to act beyond its permissions. Evaluating quality and effectiveness is not done using benchmarks alone, so it's important this is done in a way that you retain enough evidence to explain both successful and unsuccessful runs; that is what allows evaluation of success rather than metrics such as speed, cost, or lines of code alone.
The open question is how much of today's harness logic future models will absorb. Organisations can investigate that without postponing decisions about ownership and control. Whatever the eventual division between model and runtime, someone will still need to account for the actions an agent takes, the information it uses and the cost of the work it completes.