DeepSeek Harness Is Open: The Agent Runtime Is Now a Plugin Tree

DeepSeek has open-sourced a new project. This time, it is not another model. It is the runtime foundation for building agents: DeepSeek Harness.

Its command-line name is dsh, and its central design rule is simple: Everything is a plugin.

Model adapters, tools, session records, and even the Agent Loop that keeps work moving are not hard-wired into one privileged core. There is a defined place to swap the model, replace the sandbox, or change how the loop runs.

What Is It?

A harness is the runtime skeleton around an agent. The model answers questions and tools perform actions, but a real agent product also needs request scheduling, context management, session replay, permissions, sandboxes, and a user interface.

DeepSeek Harness brings those pieces into one composable framework. It is not a new model or simply another chat page. It is closer to a reusable foundation for building agent products.

The project is currently in developer preview. The official README warns that future releases will include breaking changes. It is a good time to study the architecture, build plugins, and test workflows; it is too early to treat the interfaces as a frozen production contract.

The Big Decision: Everything Is a Plugin

DeepSeek Harness is built on Cordis. Cordis lets plugins contribute services, typed events, and reversible side effects to a shared context.

There is no giant core that every feature must modify. New behavior is added by mounting another plugin, and a plugin can withdraw the services and effects it registered when it is unloaded.

In practical terms:

• Swap a model by replacing its adapter
• Add tools through the shared tool system
• Move from local execution to a remote sandbox by replacing filesystem, process, and terminal providers
• Add approvals, timeouts, or telemetry through tool execution events
• Change agent behavior by replacing the Agent Loop instead of rewriting the product

Many agent projects start as a model call, a few functions, and a loop. Once permissions, recovery, long-running tasks, and remote execution arrive, those pieces quickly become tangled. DeepSeek Harness separates the boundaries early. The tradeoff is a steeper learning curve, but less painful surgery later.

Profiles and Bundles Make the Runtime Composable

An active dsh process is not just a fixed list of modules. It is a plugin tree assembled from configuration.

A profile is a named runtime composition. It selects the bundles to load and can keep extra plugins and a user-owned cordis.patch.yml. The distribution currently includes two templates: web starts the Web UI, while headless runs one-off tasks without a server.

A bundle is a distributable group of plugins and Cordis configuration. At startup, Harness layers the selected bundles onto an empty configuration, then applies profile-level, user-level, and command-line patches. The same components can therefore be configured differently for different environments without copying the codebase.

To inspect the configuration actually being loaded, run:

dsh --profile web --dump-config

That command captures the project’s approach well: deployment differences belong in composition and configuration rather than a growing collection of code branches.

How Does an Agent Run?

The official architecture separates work into a turn and a step. A turn is one complete task and can contain multiple steps. A step is one model request together with the tool calls it triggers.

The simplified flow looks like this:

turn/start
  -> claim input
  -> agent/pre-step
  -> assemble prompt and tool schemas
  -> agent/request
  -> llm/stream
  -> assistant/message
  -> tool/call
  -> tools/pre-execute
  -> tools/execute
  -> tools/post-execute
  -> tool/result
  -> step/end
  -> turn/end

These events are not there just to make logs look organized. They are concrete extension points. A plugin can rewrite or reject input before a request, intercept the request itself, or add approvals, timeouts, monitoring, and policy checks around tool execution.

Session Logs: What the Model Sees Must Be Replayable

Harness treats the session log as the source of the model’s context. The history shown to the model is projected from the event stream rather than kept as an opaque in-memory array. Raw assistant/chunk events are also retained for replay and UI rendering.

The architecture has a strict rule: everything visible to the model must be reconstructable from the log.

That matters for long-running work. If a task fails and needs a retry, if execution needs to resume, or if a session is forked into a new path, the system must be able to answer one basic question: what exactly did the model see? A context that only exists in temporary state makes all of those operations fragile.

What Do the Core Packages Do?

The architecture documentation assigns the main responsibilities to separate packages:

Package	Responsibility
core/session	Stores SessionEvent logs and in-memory state
core/system-prompt	Assembles prompt fragments and tool schemas
core/tools	Registers tools and manages the execution pipeline
core/agent	Defines the Agent interface and active-agent registry
core/agent-loop	Provides the default Agent Loop driver
llm/llm	Handles messages, streaming, and model adapters

There is no single giant Agent class responsible for everything. The model is the model, tools are tools, and the loop is the loop. They are composed when the application needs them.

Capability Interfaces: Change the Backend, Keep the Product

Harness calls a replaceable capability a seam. A seam usually has three parts: an interface definition, a concrete provider, and the module that consumes it.

Consider the execution environment. The local filesystem, processes, Bash, PTY, and LSP can share one execution world. Replace the filesystem and process providers with remote sandbox providers, and related tools can move with them instead of growing a separate remote branch for every tool.

Script-style agents are faster to write. Harness is more concerned with whether the same agent can change environments, permission policies, and models while continuing to work. Understanding Cordis, plugin trees, and event streams takes time, but larger workflows eventually run into these boundaries anyway.

Run It Now

With Node.js installed, start the Web UI with:

npx @deepseek-ai/dsh web

The Web UI runs at http://127.0.0.1:3080 by default.

To run from source:

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

The project is released under the MIT License. Developers interested in extending it can start with the official architecture documentation and then explore repositories tagged with dsh-plugin.

Why This Release Matters

DeepSeek Harness is not simply a new wrapper around “a model plus tool functions.” It moves the parts that tend to become unmanageable in agent products into the architecture itself: runtime, state, permissions, execution environments, replay, and deployment composition.

It is not lightweight. Plugin trees, profiles, bundles, event streams, and seams all add to the entry cost, and the developer-preview status means the interfaces will continue to change. But anyone building an agent that must run long tasks, recover from failures, support auditing, or move between execution environments will eventually face these problems.

DeepSeek has chosen to open-source the layer that is rarely impressive in a demo but often determines whether an agent can keep working over time.

Finally

DeepSeek Harness is not yet a mature platform whose version can be locked down without concern. Its direction is clear, though: models, tools, sessions, sandboxes, UI, and the Agent Loop should all be replaceable components.

To try it, run npx @deepseek-ai/dsh web. To build plugins, start with Cordis and the official architecture guide. The interesting question is not how many buttons DeepSeek Harness has today, but how finely “everything is a plugin” can break an agent apart and still put it back together in useful ways.

Sources:

• DeepSeek Harness official GitHub repository
• DeepSeek Harness README
• Official architecture documentation
• Cordis project