A model can tell you how to fix a bug. An agent is expected to open the repository, read the code, make the change, run the tests, notice that the first attempt failed, try again—and, ideally, avoid deleting production on the way.
The gap between those two things is not a better prompt.
It is the system around the model.
Most of my work over the last few years has lived in exactly that system. When I built observability for a customer-facing AI avatar running on a multi-tenant Kubernetes platform, the interesting problems were almost never “is the model smart enough.” They were: is the right context reaching it, are the tools behaving, is the RAG pipeline returning what we think it is, and can we see what happened when something goes wrong. That surrounding layer now has a name that is catching on across the industry: the AI agent harness.
A useful shorthand—used explicitly by DeepSeek in its recently released harness—captures it:
Agent=Model+Harness
The vocabulary is not fully standardised. You will see agent runtime, orchestrator, agent framework and harness used to mean overlapping things. But the separation of responsibilities is worth holding onto:
| Layer | Main responsibility | Plain-language view |
|---|---|---|
| Model | Interprets information, reasons, proposes actions | The intelligence engine |
| Harness | Supplies context, exposes capabilities, executes actions, enforces controls | The execution and control system |
| Agent | Combines intelligence with the ability to operate | The complete working system |
This distinction matters because many “AI failures” are not really model failures. The model may understand the task perfectly well while the system around it retrieves the wrong document, exposes a confusing set of tools, drops an earlier result, executes an action incorrectly, or lets the agent declare victory without checking its own work.
A capable model inside a fragile harness is still a fragile agent.
What the harness actually does
Most useful agents run some variation of a reason–act–observe loop.
The harness first assembles the relevant instructions, state and context. The model then proposes a next action. Before anything happens, the surrounding system can apply policies, permissions and workflow rules. A tool or sandbox performs the action, the result is observed and verified, state is updated, and the new evidence goes back to the model. The cycle repeats until the task is complete, blocked, or needs a human.
The model proposes what to do. The harness decides what is available, what is permitted, how the action executes, and what evidence comes back.
That is why a production harness is much more than tool calling. In practice it carries system instructions that define objectives and boundaries; context management that decides what the model sees and when; memory that preserves useful information across turns and sessions; tools that connect the model to APIs, databases, search and applications; sandboxing to isolate risky execution; state and durable execution to survive interruptions; verification to catch mistakes; guardrails and approvals for sensitive actions; identity and authorisation to establish who the agent represents; and observability to record what happened.
None of these are things a language model grants itself. A model does not create durable state, hand itself database permissions, recover a crashed container, or produce a reliable audit trail just because you asked nicely. Those are system responsibilities—and building them well is closer to platform engineering than to prompt-writing.
From prompt engineering to complete systems
Prompt engineering still matters. It is just one layer.
The engineering focus has steadily expanded outward—from shaping instructions, to selecting context, to designing the whole environment a model operates in:
| Discipline | Central question | Main design work |
|---|---|---|
| Prompt engineering | How should the task be described? | Instructions, examples, constraints, formats |
| Context engineering | What should the model know right now? | Retrieval, memory, filtering, compression, assembly |
| Harness engineering | How should the whole agent behave? | Tools, execution, state, workflows, verification, permissions, observability |
These are complementary, not competing. A good prompt cannot repair a broken API integration. Excellent retrieval cannot make an irreversible action safe. A million-token context window will not tell an agent whether it should be allowed to send ten thousand emails.
Harness engineering is less about improving one response and more about making a sequence of decisions and actions dependable. That is a different discipline, and it is the one that tends to separate a demo from something you can put in front of a customer.
Sometimes the model is not the problem
The clearest recent demonstration of this came from Anthropic in April 2026.
After users reported that Claude Code had gotten worse, Anthropic investigated and traced the problem to three separate product-level changes affecting Claude Code, the Claude Agent SDK and Claude Cowork. The underlying API and inference layer, they said, were unaffected. One change had lowered the default reasoning effort. A context-management bug repeatedly stripped older reasoning out of resumed sessions. And a system-prompt change meant to reduce verbosity quietly hurt coding quality.
Users experienced all of this as the agent getting less intelligent. The model had not changed in the way people assumed.
That is the lesson worth internalising: people experience the behaviour of the whole system, not the model in isolation. The same weights can feel meaningfully better or worse depending on the reasoning configuration, context handling, tools, prompts, execution policies and verification wrapped around them. Anthropic reached a similar conclusion in its own work on long-running coding agents, where changes to planning, context hand-offs and evaluator structure moved performance more than any model swap.
Benchmarks are still useful. They just do not measure the thing that determines whether a working agent is any good.
Long-running agents need durable execution
This gets sharper as agents move from answering questions to doing work that lasts minutes, hours, or longer. A serious agent cannot assume that one process, one context window, or one container will stay alive forever.
OpenAI made this explicit in its April 2026 Agents SDK release. It describes the infrastructure as a model-native harness and deliberately separates the harness from sandbox compute. Agent state can be externalised, sandbox environments can be recreated, and execution can resume from stored checkpoints if the original environment disappears. DeepSeek’s harness takes a related route through event-sourced sessions: its history is an append-only log that can be persisted, inspected, replayed, and recovered after an interrupted run.
Both point at the same requirement:
Agent execution should survive the environment executing it.
For anything running in production, a failed container should not automatically mean a failed task. And once you accept that, you inherit a familiar set of distributed-systems problems—checkpoints, idempotency, retries, event history, state recovery, and the awkward question of whether an interrupted external action actually happened before you retry it. Agent engineering, increasingly, is systems engineering. Anyone who has run stream and batch pipelines to a reliability bar will recognise the terrain.
The harness is not the protocol
Part of the stack is also being standardised through open protocols, and it is worth being precise about where they sit.
Model Context Protocol (MCP) standardises how an agent connects to tools, APIs, resources and external context. Agent2Agent (A2A) addresses a different boundary—communication and coordination between independent agents—and reached its first stable, production-ready release (v1.0) in 2026. They are complementary rather than rival ideas.
Neither protocol replaces the harness. Protocols standardise the interfaces. The harness still decides which capabilities to expose, what context reaches the model, which identity is in use, what permissions apply, how execution state is maintained, when verification runs, and when a human has to step in.
Protocols define how systems connect. The harness defines how the agent behaves.
More tools do not automatically make a better agent
One of the easiest mistakes in agent design is to equate capability with the number of tools available. In practice, every tool is another decision the model has to weigh.
The MCP maintainers made this point directly in their updated roadmap, published on 22 August 2026. Connect an agent to a server exposing a hundred tools, and the model has to reason about that entire surface before the user has even asked for anything—and tool-selection quality tends to degrade as the catalog grows. One direction MCP is now exploring is progressive discovery: expose a small, useful set of capabilities first, and reveal more as the task becomes clearer.
That is a good principle well beyond MCP. A strong harness does not maximise what an agent could do. It makes the right capabilities available at the right moment.
Memory is useful—and part of the attack surface
Persistent memory creates the same trade-off, and it is one I would encourage anyone shipping agents to take seriously.
Memory makes an agent far more useful: it preserves preferences, prior work, intermediate findings and long-running context. But persistent information also influences future reasoning—which means it is a place an attacker would like to reach. OWASP’s Agentic Security Initiative now treats memory and context poisoning as a distinct agentic security category (ASI06). Unlike a one-shot prompt injection that resets when the session ends, poisoned memory persists across sessions and can shape decisions days or weeks after it was written.
So persistent state should not automatically become trusted state. Depending on the application, provenance, isolation, validation, write permissions, expiration and auditability all start to matter. The same logic applies to tools.
As agents gain autonomy, security becomes a question of blast radius: if the agent makes a bad decision—or is manipulated into one—what can it actually affect? Sandboxes, virtual machines, filesystem boundaries, network egress restrictions and narrowly scoped credentials shrink that radius before the model ever decides anything. In my experience that is far more reliable than asking a human to click through an endless stream of permission dialogs. Anthropic describes a similar philosophy in how it contains Claude across products—access boundaries and blast-radius reduction through sandboxes, VMs and egress controls.
A plugin-first case study: DeepSeek Harness
DeepSeek offers an interesting look at where harness architecture may be heading. Its open-source DeepSeek Harness—MIT-licensed and currently a developer preview—is organised around one idea:
Everything is a plugin.
Models, tools, skills, sessions, sandboxes, storage, loops, scheduling and even the UI can be mounted and recomposed as plugins. An underlying kernel called Cordis manages plugin dependencies and lifecycle rather than implementing the agent’s capabilities directly.
Plugin architectures are not new—software has used them for decades. What is interesting is applying that modularity across such a large slice of the agent execution stack. In principle you could compose a restricted research agent, a coding agent with an isolated sandbox and filesystem, and an internal enterprise agent limited to approved systems—all sharing most of the same harness infrastructure. DeepSeek’s event-sourced session model also makes the interaction history a durable, replayable part of the architecture rather than throwaway UI state.
It should be taken for what it is: a developer preview, not an established standard. But it illustrates a broader movement visible across OpenAI, Anthropic and the emerging protocol ecosystem. The harness itself is becoming a serious engineering surface.
The enterprise question is identity, authority and control
Run more than a handful of agents inside an organisation and one problem becomes unavoidable: who is the agent acting as?
An enterprise system needs to know not just which model produced an action, but which user, service or organisation authorised it, and what authority was actually delegated. The August 2026 MCP roadmap lists agent identity and enterprise-ready security as a major priority for good reason. Browser-based user authorisation works fine for interactive software, but autonomous cloud agents may run when the user is absent, or delegate narrower authority to subagents. That raises real questions around workload identity, token exchange and delegated authorisation—the kind of governance and RBAC concerns I have watched enterprises wrestle with well before “agent” became the word for it.
The harness is the natural place to enforce these boundaries. A good enterprise agent should let you reconstruct what happened: which identity performed the action, which data it touched, which tools were available, which permissions were active, how much the run cost, and whether any policy was overridden. Without a shared control layer, organisations end up with dozens of disconnected agents, each with its own permissions, logging conventions, memory behaviour and security assumptions.
The goal is not unlimited autonomy. It is controlled autonomy.
The model provides intelligence. The harness earns trust.
Agents are usually sold as model breakthroughs. The ones that turn out to be genuinely useful are engineering products built around those models.
The model provides reasoning. The harness turns reasoning into controlled action. Context decides what the model knows, tools decide what it can affect, memory provides continuity, durable execution keeps work alive, verification catches mistakes, identity defines authority, sandboxes limit damage, and observability makes the whole sequence legible. Protocols like MCP and A2A increasingly define how these pieces connect to the world.
None of this makes the model less important—better models expand what an agent can do and let you retire assumptions the harness used to carry. That is itself a design principle worth stating: a harness should evolve as models improve. Complexity added to paper over yesterday’s model limitations becomes tomorrow’s dead weight.
So the objective is not the largest possible framework. It is the smallest reliable operating environment that gives a model enough context to understand the task, enough capability to complete it, enough feedback to correct itself, and enough restraint to avoid becoming memorable for the wrong reasons.
The next generation of agents will certainly use better models. The ones that actually work will also have better harnesses—quietly doing the unglamorous work of making intelligence useful, durable, observable and safe.
Sources and further reading
- DeepSeek — DeepSeek Harness (developer preview). Documents the “Agent = Model + Harness” and “everything is a plugin” architecture, the Cordis kernel, and an append-only, replayable session log.
- Model Context Protocol — “The New MCP Roadmap” (22 August 2026). Covers agent identity, enterprise security, long-running agentic messaging and progressive discovery for large tool catalogs.
- A2A Protocol — Version 1.0. The first stable, production-ready open standard for communication between independent agents, and its complementary relationship with MCP.