DeepSeek Harness: The Future of AI Agents?
Most AI coding agents look similar from the outside.
You give them a prompt. They read your repository. They edit files, run commands, search for things, and try to finish the task.
Underneath, though, there is a lot more than an LLM.
There is a runtime.
There are tools. Sessions. Permissions. Sandboxes. Model adapters. Agent loops. Storage. Scheduling.
That layer is the harness.
And DeepSeek just open-sourced one.
What Is DeepSeek Harness?
DeepSeek Harness (DSH) is an open-source agent harness from DeepSeek AI. It is currently released as a developer preview under the MIT license.
DeepSeek’s core idea is simple:
Everything is a plugin.
Not just external tools.
The model, tools, skills, sessions, sandboxes, storage, loops, scheduling, and even the UI can be provided as plugins. DeepSeek says these components can be selected, replaced, or extended through configuration without modifying the Harness source itself. citeturn1view0
That is what makes DSH interesting.
It isn’t just another coding agent.
It is an attempt to make the agent runtime itself composable.
The Architecture: Model + Harness
DeepSeek describes an agent as:
Agent = Model + Harness
The model provides the intelligence.
The harness provides the environment in which that intelligence can actually operate. citeturn1view0
A simplified view of DSH looks like this:
│ Model │
└───────┬───────┘
│
▼
┌───────────────────┐
│ DeepSeek Harness │
│ Runtime │
└─────────┬─────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌─────────┐
│ Tools │ │ Skills │ │Sessions │
└────────┘ └────────┘ └─────────┘
│ │ │
└─────────────┼─────────────┘
▼
┌──────────────┐
│ Environment │
│ Files / Shell│
│ Web / Runtime│
└──────────────┘
The interesting part is what sits in the middle.
DSH is built on Cordis, a plugin framework that manages plugin mounting, unmounting, dependencies, services, and events. The official architecture documentation goes even further: the model adapter, tool registry, session log, and agent loop are themselves plugins. There is deliberately no privileged core that developers have to patch to extend the system.
That changes how you think about customization.
Everything Is a Plugin
This is the feature I find most interesting in DeepSeek Harness.
In a traditional coding agent, you usually customize the system around the edges.
Add an MCP server.
Add a skill.
Change some configuration.
Maybe write an extension.
DSH takes a more aggressive approach.
The architecture itself is modular.
Want to change the model layer?
It is a plugin.
Want to replace a tool?
Plugin.
Want a different session implementation?
Plugin.
Want to change the agent loop?
Plugin.
Want to create a different runtime configuration?
Compose plugins.
DeepSeek explicitly exposes models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and UI as plugin capabilities. citeturn1view0
For developers, this matters because open source here isn’t just about being able to read the source code.
You can actually change the machinery.
You can fork it.
You can write your own plugin.
You can replace components.
You can experiment with completely different agent configurations.
And because the project is MIT licensed, the licensing barrier is much lower than with a closed commercial agent runtime.
Plugins: https://github.com/topics/dsh-plugin
The Four Agent Modes
DeepSeek doesn’t expose just one way to run the Harness.
It currently provides multiple runtime modes.
Standard Mode
This is the full coding-agent experience.
It includes file editing, shell access, file and web search, skills, planning, goals, subagents, and workflows. citeturn1view0
PTC Mode
This one is particularly interesting.
Instead of exposing every operation as another sequential tool call, DSH can expose its tools through the PTC Mode SDK, allowing the model to generate a TypeScript program that combines multiple operations.
Conceptually:
Traditional agent:
Model
↓
Tool call
↓
Result
↓
Model
↓
Tool call
↓
Result
↓
Model
Code Mode moves toward:
Model
↓
Generate TypeScript
↓
Execute multiple operations
↓
Result
That is a very different way of thinking about tool orchestration.
Minimal Mode
Minimal mode strips the environment down to a persistent Bash tool and a file editor.
This is useful when you want to evaluate a model with a smaller tool surface rather than giving it the entire agent environment.
Creator Mode
Creator mode is aimed directly at developers building agents.
You can inspect the runtime, experiment with Cordis plugins in memory, and compose custom agent presets. citeturn1view0
This is where DSH starts looking less like a coding assistant and more like an agent development platform.
And You Can Actually Customize and add your own
This is where the open-source part becomes important.
The DSH interface exposes separate areas for:
Models → Plugins → Agent Presets
You can inspect the installed plugins and their status, change configuration, and create custom presets.
But the deeper customization happens below the UI.
Because the runtime is open source and plugin-based, you aren’t restricted to the default presets.
You can modify the source.
Write your own plugin.
Replace an existing capability.
Create a different agent loop.
Change the model adapter.
Build your own tool.
Create a custom sandbox.
Compose your own agent preset.
The official architecture explicitly treats core components such as the model adapter, tool registry, session log, and agent loop as plugins. DeepSeek
That’s the important distinction.
You aren’t only customizing the agent’s behavior.
You can customize the machinery that makes the agent work.
The Trajectory View Is Another Big Deal
Agent debugging is difficult.
A normal application gives you logs.
An agent gives you a conversation, tool calls, context changes, subagents, model outputs, and a constantly changing state.
DSH addresses this with an append-only session log.
According to DeepSeek, the log records what the model sees, including system prompts, reasoning, tool calls and results, subagent scheduling, and context injections. The Trajectory view can then inspect those records, while resume, fork, search, and replay operate on the same event stream. citeturn1view0
For agent developers, this is more than a nice UI feature.
It is an observability primitive.
If an agent makes a bad decision, you want to know:
What did the model see?
↓
Which tool did it choose?
↓
What did the tool return?
↓
What context was injected?
↓
Which subagent ran?
↓
What happened next?
A traceable event stream makes that investigation much easier.
DeepSeek Harness vs Claude Code vs Codex
This is where DSH becomes easier to understand.
Claude Code and Codex are primarily developer-facing coding-agent products.
Claude Code runs in the terminal and can explore repositories, edit files, execute commands, use MCP, and automate development workflows. Anthropic also provides configurable permissions and CLI controls.
Codex is OpenAI’s coding agent, with a local CLI plus IDE, desktop, and cloud surfaces. Its CLI is open source under Apache-2.0.
But DeepSeek Harness is approaching the problem from a different architectural angle.
The important distinction is not simply open source vs closed source.
Codex is also open source.
The difference is what is being opened and how the system is structured.
With DSH, the plugin architecture reaches into the core runtime itself. DeepSeek’s architecture documentation explicitly describes the agent loop, model adapter, tool registry, and session log as replaceable plugins. citeturn0search0
That is a much more ambitious customization surface.
Why Open Source Matters Here
This is probably the strongest argument for DSH.
With a closed coding agent, you use the runtime that the vendor gives you.
You can configure it.
You can connect external tools.
But you generally don’t get to redesign the underlying agent architecture.
With DeepSeek Harness, the source is there.
You can inspect the implementation.
Change it.
Fork it.
Build plugins.
Replace components.
Create your own runtime profile.
Build an agent that behaves differently from the default DSH experience.
The official project is MIT licensed and explicitly encourages a plugin ecosystem. citeturn0view0turn1view0
For researchers and agent-framework developers, that matters.
You aren’t just testing an agent.
You can test your own idea of what an agent should be.
But There Is a Catch
DeepSeek Harness is still a developer preview.
DeepSeek explicitly warns that the project is evolving rapidly and that compatibility-breaking changes will happen.
That means I wouldn’t treat DSH as a polished replacement for Claude Code or Codex today.
The architecture is the interesting part.
The ecosystem still has to mature around it.
There is also a security consideration.
DSH can execute actions on the local machine, so DeepSeek recommends using a dedicated VM or container with limited privileges, especially when interacting with untrusted internet content.
That is an important distinction between “the agent can do anything” and “the agent should be allowed to do anything.”
My Take
I don’t think the most interesting thing about DeepSeek Harness is that it is another AI coding agent.
The interesting thing is that DeepSeek is exposing the machinery behind the agent.
The model is replaceable.
The tools are replaceable.
The session layer is replaceable.
The agent loop is replaceable.
The runtime can be recomposed.
And the whole thing is sitting behind an open-source plugin architecture.
That makes DSH feel less like “another Claude Code competitor” and more like an attempt to build infrastructure for building your own coding agents.
That’s a much more interesting problem.
The next step for AI coding agents may not simply be better models.
It may be better harnesses.
And DeepSeek has just open-sourced one of the more interesting architectures to experiment with.
Run DeepSeek Harness Locally
One of the best things about DeepSeek Harness is that you don’t have to interact with it through a hosted service.
You can run the entire Web UI locally.
Option 1: Run it directly
If you already have Node.js installed:
npx @deepseek-ai/dsh web
That’s it.
By default, DSH starts its Web UI at:
http://127.0.0.1:3080
The official CLI also opens the local UI in your default browser. If you don’t want it to open automatically, use:
npx @deepseek-ai/dsh web --no-open
This is the quickest way to try DeepSeek Harness locally without cloning the repository. GitHub
Option 2: Clone and run the source
If you’re interested in actually modifying the Harness, this is the route I’d recommend.
git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web
The important difference is that you’re now running your own checkout of the Harness source.