Is the harness the same thing as the model?

No. The model turns text into more text and has no memory of yesterday, no file access and no ability to run anything. The harness is the program around it that decides what the model sees, executes the tools it asks for, feeds the results back, and stops the loop when the work is done.

Is an agent harness just a wrapper around an API call?

A single call is not a harness. The defining feature is the loop: the harness calls the model, executes whatever tool the model requested, adds the result to the conversation and calls again, repeating until a stopping condition is met. Everything hard about harnesses — context management, permissions, session persistence, error recovery — exists because of that loop.

How is a harness different from an agent framework?

A framework is a library you build an application with; a harness is a runnable program you use. Frameworks give you the pieces and leave the decisions to you, while a harness has already made those decisions and shipped them as defaults. The line blurs when a harness is unusually configurable, which is exactly what DeepSeek Harness is.

Does an agent harness replace MCP?

No, they answer different questions. MCP is a protocol that describes how a tool or data source exposes itself to an agent, while a harness is the program that runs the loop and decides when a tool gets called at all. A harness can act as an MCP client, which makes them complementary rather than competing.

What makes DeepSeek Harness unusual among harnesses?

Its everything-is-a-plugin design. Models, tools, skills, sessions, sandboxes, filesystems, the loop, orchestration and the UI are all plugins loaded into a shared Cordis runtime and composed through a cordis.yml file, so the parts most tools treat as fixed internals are replaceable packages here.

What is an agent harness?

An agent harness is the runtime layer wrapped around a language model that turns a text generator into something that can do work. It runs the loop, hands the model tools, decides what goes into context, keeps sessions somewhere durable, and enforces what the agent is allowed to touch. The model supplies judgement; the harness supplies everything else.

What the harness actually does

Strip an agent down and five responsibilities are left, none of which the model can handle by itself.

The loop. A model call returns once and stops. An agent keeps going: call the model, execute the tool it asked for, append the result, call again, until the task is finished or a limit is hit. That cycle is the harness's core job, and most of what distinguishes one harness from another — how it retries, when it gives up, whether it can run steps in parallel — is a decision about the loop.

Tools. Reading a file, running a command, searching the web. The harness advertises what is available, validates the arguments the model produced, executes the call, and formats the result back into something the model can read.

Context. Every model has a finite window and a real task will overflow it. Deciding what stays, what gets summarised, and what is fetched again on demand is a harness responsibility, and it is the one users feel most directly when an agent forgets what it was doing.

Sessions. Work that spans hours or restarts has to live somewhere: transcripts, intermediate state, the ability to resume. Without persistence you have a chat window, not an agent.

Permissions. An agent that can run shell commands is a security surface. Approval prompts, allowlists, sandboxes and filesystem boundaries all live in the harness, because the model cannot be trusted to police itself and was never designed to.

What a harness is not

It is not the model. Swapping the model changes how well the agent reasons; it does not change whether sessions resume or whether a command needs approval. Those are harness properties, which is why the same model can feel capable in one tool and hopeless in another.

It is also not an IDE plugin, though the two are easy to confuse because you often meet the harness through an editor. An editor extension is a surface: it collects your request and displays the output. The harness is what owns the loop, the tool execution and the state. A well-built harness can drive several surfaces — a CLI, a web interface, an editor — over the same session, which is a good test of whether you are looking at a harness or a front end.

How DeepSeek Harness implements it

DeepSeek Harness — dsh — was released by DeepSeek AI on 13 August 2026 under the MIT license, and takes an unusually literal position on all of the above: everything is a plugin. Models, tools, skills, sessions, sandboxes, filesystems, the loop itself, orchestration and the user interface are all plugins loaded into one shared runtime.

That runtime is Cordis, a meta-framework whose job is loading and wiring plugins; @deepseek-ai/cordis is a peer dependency of every harness package. Composition happens in a cordis.yml loader config that lists the plugins to start and their options, and a --profile flag selects between bundles for different situations — the shipped profiles include headless.

The consequence is that in dsh there is no meaningful line between the application and its extensions. Replacing the sandbox is structurally the same act as adding a tool. That is why a plugin directory matters more here than for most agent tools: the capability lives in the packages, not the core. We currently index 632 repos carrying dsh topics, of which 348 show real plugin wiring — you can browse them or move through them by category. One caveat worth repeating: dsh is a developer preview and its README warns that compatibility-breaking changes are coming, so the loader format described here is a snapshot, not a contract.

Harnesses versus agent frameworks

An agent framework is a library you build an application with. It hands you loop primitives, tool abstractions and memory helpers, and leaves the product decisions to you — you write the program, and what you ship is yours.

A harness has already made those decisions. You install it and it runs: there is a default loop, a default set of tools, a default permission model, a way to resume yesterday's session. The trade is the usual one between a library and a product — less control, far less to build.

dsh sits interestingly on this line. It is a harness you can run immediately, but because every part of it is a plugin over a general-purpose framework, a sufficiently determined user can replace the parts most harnesses treat as fixed. The distinction still holds — you can use dsh without writing any code — but it is a softer boundary than usual.

Harnesses versus MCP

MCP, the Model Context Protocol, is often mentioned in the same breath as harnesses, but the two solve different problems. MCP is a protocol: it standardises how a tool or data source describes itself and responds to calls, so that a server written once can be used by any client that speaks it. It answers “how does the agent reach this thing”.

A harness answers “who runs the loop, and when does that tool get called at all”. It manages context, permissions and sessions, none of which MCP has an opinion about. A harness can be an MCP client, in which case MCP servers become one more source of tools alongside whatever else it offers. If you want the concrete version of this in the dsh ecosystem, the directory's MCP and Tools category collects the plugins that sit at that boundary.

Frequently asked questions

Is the harness the same thing as the model?: No. The model turns text into more text and has no memory of yesterday, no file access and no ability to run anything. The harness is the program around it that decides what the model sees, executes the tools it asks for, feeds the results back, and stops the loop when the work is done.
Is an agent harness just a wrapper around an API call?: A single call is not a harness. The defining feature is the loop: the harness calls the model, executes whatever tool the model requested, adds the result to the conversation and calls again, repeating until a stopping condition is met. Everything hard about harnesses — context management, permissions, session persistence, error recovery — exists because of that loop.
How is a harness different from an agent framework?: A framework is a library you build an application with; a harness is a runnable program you use. Frameworks give you the pieces and leave the decisions to you, while a harness has already made those decisions and shipped them as defaults. The line blurs when a harness is unusually configurable, which is exactly what DeepSeek Harness is.
Does an agent harness replace MCP?: No, they answer different questions. MCP is a protocol that describes how a tool or data source exposes itself to an agent, while a harness is the program that runs the loop and decides when a tool gets called at all. A harness can act as an MCP client, which makes them complementary rather than competing.
What makes DeepSeek Harness unusual among harnesses?: Its everything-is-a-plugin design. Models, tools, skills, sessions, sandboxes, filesystems, the loop, orchestration and the UI are all plugins loaded into a shared Cordis runtime and composed through a cordis.yml file, so the parts most tools treat as fixed internals are replaceable packages here.

Keep reading

To see the ideas above as running software, install dsh — one npx command gets you a Web UI on http://127.0.0.1:3080. To see how a plugin-everything harness compares with an established proprietary one, read our early comparison of dsh and Claude Code.