DEV Community

Antonne Dillard
Antonne Dillard

Posted on Originally published at teamorouter.com

DeepSeek Harness Architecture: The Ultimate Guide to 'Everything Is a Plugin'


"Everything is a plugin" is the kind of line that sounds like marketing. In DeepSeek Harness (dsh) it's literal — and it's the source of every useful capability the framework has.

What is DeepSeek Harness (dsh)?

DeepSeek Harness is DeepSeek AI's open-source agent harness — the framework that turns a language model into a worker that can edit code and run commands. It follows the formula Agent = Model + Harness: the model (usually DeepSeek V4) is the brain; the harness is everything else — tools, filesystem, shell, sub-agents. Released under MIT, powered by the Cordis runtime, and in developer preview.

The key architectural claim is this: the filesystem, the shell, the model adapter, the Web UI, and sub-agents are not hardcoded. They're swappable plugins, orchestrated by a runtime called Cordis.

The two ideas behind Cordis

Cordis is the MIT plugin runtime that drives dsh. Two ideas capture it:

  • Registrations are reversible effects — tools, providers, and listeners install via ctx.effect() / ctx.on(), so reload and teardown unwind them cleanly.
  • Spatiotemporal composability — plugins compose in one context by declaration order; capabilities stack and unstack.

You don't need to read the source. Just remember: dsh's capability = the combination of plugins you load. Add a plugin to gain ability, remove one to lose it.

Seams: the "three-role" swappable capability

One word recurs in dsh's docs — seam, a swappable capability. It's the mechanism behind "swap one provider and change the whole product." A seam has three roles:

Role Responsibility Example (shell)
Service Definition Declares the interface dsh-shell
Service Provider Implements it dsh-bash-local / dsh-bash-sandbox
Consumer The model-facing tool dsh-tool-bash

Because the three are decoupled, changing an implementation touches only the Provider. Move the shell from local to a remote sandbox and the bash tool's model-visible schema doesn't change — invisible to the agent.

Three practical payoffs

1. Trimmable capability surface. Not every agent needs network. Mount only bash + file ops, omit web search → a more controllable, cheaper agent.

2. Swappable providers. The model backend is itself a seam — this is exactly how dsh plugs into DeepSeek V4 Pro (1M context, flagship reasoning) or V4 Flash (fast + cheap). Point DEEPSEEK_BASE_URL from the official API to any endpoint — one env var, nothing else changes:

export DEEPSEEK_BASE_URL="https://api.teamorouter.com/v1"
export DEEPSEEK_API_KEY="sk-teamo-your-key"
Enter fullscreen mode Exit fullscreen mode

3. Custom tools. Want a tool that queries your internal ticketing system? Write a Cordis plugin, register it on ctx.tools, done — faster than waiting for official support.

The mental model: a slot board

[ bash ] [ files ] [ subagent ] [ web-search ] [ model-adapter ] ...
        └────────── all mounted on the Cordis runtime ──────────┘
                              │
                   the agent's actual capability
Enter fullscreen mode Exit fullscreen mode

You decide what's plugged in. That model explains most of dsh's design — why the default preset bundles bash + file ops, and why headless mode needs only env vars.

The direct value is two things: cheaper (plug a cheap DeepSeek V4 in and the same loop costs an order of magnitude less) and more control (you decide exactly what the agent can touch).

Try the architectureGet a key on TeamoRouter

Top comments (0)