dshbase
中文

Blog · Concept

Why it's called a harness

August 14, 2026 · dshbase

DeepSeek didn't call it DeepSeek Code or DeepSeek Build. It called it a harness — and that naming is the entire thesis. Most people miss it. The name is a precise technical claim, not marketing.

Agent = Model + Harness

Every AI coding agent is really two things bolted together. The model is the brain — the reasoning engine that decides what to do. The harness is everything else — the code that connects that brain to files, terminals, tools, and the outside world.

Claude Code, Codex, and DSH are all harnesses. The difference is what each one does with the harness layer:

  • Claude Code keeps the harness proprietary — you extend it through MCP servers, but you never see or change the core.
  • Codex is similar — a closed harness with an extension API.
  • DSH makes the harness itself the product — open source, and every part of it is a plugin you can swap.

The Cordis kernel: an agent that plugs itself together

DSH is built on Cordis, a minimal plugin kernel that does exactly one job: manage plugin loading, unloading, and dependency resolution. Everything else — models, tools, sandboxes, session storage, the UI, even the agent loop itself — is a plugin on top of that kernel.

Two properties of Cordis make DSH fundamentally different from a normal app:

  • Temporal composability — when a plugin unloads, its side effects fully undo. You can remove a capability and the system returns to the state before it was added.
  • Spatial composability — when one plugin changes, its dependents re-resolve automatically. Add or swap a tool, and everything that uses it picks up the change without a restart.

What this looks like in practice

We've verified this behavior directly on dsh 0.1.0-rc.6. Running dsh plugin add dsh-memory installs the package, records it in the profile's package.json, and — on the next launch — the plugin is already in the config tree. No rebuild, no restart dance, no manual wiring. The kernel discovers and loads it.

The flip side we also hit: a plugin without a dsh.bundle manifest installs silently as a plain dependency — it never activates. The harness is only as good as the manifest contract. That's the kind of detail you only learn by running it, which is why we document it in the plugin directory and the troubleshooting guide.

Self-evolution, not just extension

The result is an agent that can install and remove its own capabilities while running. Give it a task, and it can add a plugin to solve that task, then shed it. This is a form of self-evolution — the same idea behind DSH's other articles on the self-evolving loop and trajectory tracing.

That's why it's a harness, not a product. It's infrastructure for agents: a minimal kernel plus ~100 first-party plugins, explicitly inviting the community to build the rest. The name tells you the ambition — this isn't an app you use; it's scaffolding you own.

FAQ

Is "harness" the same as "framework"? Close, but a harness emphasizes the runtime wiring (files, terminals, tools) more than a generic framework does. DSH ships a full runnable agent, not just libraries.

Do I need to understand Cordis to use DSH? No. You can use it as a normal agent. Cordis only matters when you start writing plugins or swapping core parts.

Resources

All articles →