Answer in brief
DeepSeek Harness is an open-source runtime around an AI model, not a model itself. It coordinates workspaces, sessions, tools, permissions, model providers, plugins, and user interfaces so an agent can carry out multi-step software tasks under explicit operational boundaries.
DeepSeek Harness (command name dsh) is an open-source Agent Harness from DeepSeek AI. It is not a new model, but a complete environment that runs around the model: it organizes workspaces, tools, permissions, sessions, model adapters, and interfaces so the model can complete multi-step tasks.
Official note: the project is currently in Developer Preview and may introduce breaking changes.
How Model, Agent, and Harness Relate
You can think of the three as three layers:
| Layer | What it handles | Example |
|---|---|---|
| Model | Generation and reasoning | DeepSeek models |
| Harness | Tools, state, permissions, the loop, and the runtime environment | DeepSeek Harness |
| Agent | The executable entity formed by a model running inside a Harness | A session that can read a repository and modify code |
With only a model, it can only generate output from input. Add a Harness, and it can read a real project, call tools, wait for results, proceed to the next step, and record the entire process.
What “Everything is a Plugin” Means
DeepSeek Harness is driven by Cordis under the hood. Model adapters, the tool registry, the Session Log, the Agent Loop, and even the Web UI can all be mounted as plugins. The official architecture documentation emphasizes that extending behavior is usually done by installing or composing plugins, not by modifying an irreplaceable core.
This leads to two consequences:
- The runtime is highly composable — teams can swap out models, sandboxes, tools, and interfaces.
- Plugin quality and permission boundaries directly affect the reliability of the entire Agent.
Understand a Harness Through Five Questions
| Question | DeepSeek Harness mechanism |
|---|---|
| How should the model work? | Instructions, Plan Mode, Skills |
| What must it not do freely? | Approval, sandbox, tool validation |
| How do we know it is correct? | Results, tests, logs, review |
| How are facts preserved? | Session events, compaction, forks |
| How is complexity divided? | Agent loop, tools, subagents, plugins |
A read-only audit needs a clear task contract, a read-only sandbox as the hard boundary, and file-based evidence. During a task the harness derives model input from session state, validates tool calls, applies approval and sandbox policy, persists results, and optionally compacts older context into a traceable summary.
When It Makes Sense to Try
- You want to understand how an Agent combines models, tools, and sessions.
- You are comfortable with interface changes during the Developer Preview.
- You need a Web UI, Headless mode, or an extensible Plugin runtime.
- You want to understand what happened during a task through real event logs.
If your production workflows require long-term stable APIs, evaluate it in an isolated environment for now rather than replacing critical workflows directly.
Next Steps
Continue to the 10-Minute Quick Start to launch the Web UI on your machine and complete your first task.