DeepSeek Harness's architecture in one sentence: everything is a plugin. The product is a plugin tree, and every part is replaceable from configuration.

Everything is a plugin

DeepSeek Harness is built on the Cordis plugin system, which offers spatiotemporal composability:

• The Cordis meta-framework handles only plugin loading/unloading and dependencies
• Every concrete component — model, tools, skills, sessions, sandbox, storage, loops, scheduling, UI — is a distinct Cordis plugin
• Plugins cooperate through Cordis services and events, composed freely at the configuration layer

Developers can select, replace, or extend any single capability as a plugin — without ever modifying DeepSeek Harness source code.

There is no privileged kernel to patch: you extend dsh by mounting plugins alongside other plugins, and every registration is a reversible side effect, undone when its plugin unloads.

Profiles & bundles

A running dsh is a plugin tree, assembled by stacking layers in order at startup:

• profile: a named assembly in the harness home, listing its stacked bundles, storing its out-of-tree plugins, and holding the user's cordis.patch.yml. web and headless ship as templates
• bundle: the distribution format for Cordis config entries and their mount code, so what it inserts can always be patched by the layers above it

Layers apply in order: each profile bundle, then the profile's cordis.patch.yml, then the home-level one, then any --patch overlay.

dsh --profile web --dump-config

This prints the configuration tree your machine actually boots — any entry it prints can be replaced by your own patch.

Multiple run modes

Four modes, each loading a different plugin set:

Mode	Loads by default
Standard	The complete tool set
PTC	Programmatic Tool Calling — the model generates code that composes multiple rounds of tool calls
Minimal	Just a shell tool plus a file-editing tool, for model benchmarking in a minimal environment
Creative	Inspect the runtime, try Cordis plugins in memory, and compose new modes

Every run is traceable

Everything the model sees is written to an append-only session log:

• What's recorded: system prompts, chain-of-thought, tool calls and results, sub-agent dispatch, and every context injection
• Trajectory view: browse this information by source
• Resume, fork, retrieval, and replay share one event stream

What the model sees is what gets recorded: everything that reaches a model request must be rebuildable from the log, enforced by a runtime invariant.

Capability seams

A seam is a replaceable capability with three roles:

1. The Service Definition declaring the interface
2. The Service Provider implementing it
3. The Consumer using it (usually a model-facing tool)

Seams are why swapping one provider changes the whole product. For example, the filesystem and process providers share one execution world, so pointing them at a remote sandbox moves Bash, PTY, and LSP along with them — no provider-specific fork needed.

Core packages

A few of the packages that contribute to the Cordis tree:

Package	Responsibility
core/session	Append-only SessionEvent log and in-memory storage
core/system-prompt	Assembly of prompt sections and tool schemas
core/tools	Scoped tool registry with a gated execution pipeline
core/agent / core/agent-loop	The Agent interface and its default driver
core/scope	Scoped registration primitives
llm/llm	Message and streaming vocabulary, plus the adapter seam

Want to go deeper?

The full write-up is in the official repo's docs/architecture.md.