DeepSeek Harness Cordis Architecture: How the Plugin Kernel Works

DeepSeek's design bet is that an agent runtime should be a dynamically composed collection of plugins rather than one giant application. The kernel exists to keep that composition sane: mounting, unmounting, and dependency resolution are the only things it owns^[1].

Every agent capability lives in a plugin: models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI. Because the loop itself is a plugin, changing how the agent reasons between steps is a configuration change rather than a fork^[1][2].

The Cordis kernel manages three things for every plugin: mounting, unmounting, and dependencies^[1].

The kernel is intentionally minimal. It does not implement tool calling, memory, or any agent behavior itself — those come from plugins. That separation is what lets you swap a sandbox provider or a model adapter without touching the core^[1].

• Mounting: activating a plugin in the runtime and registering its capabilities
• Unmounting: safely removing a plugin (and any plugins that depend on it)
• Dependencies: resolving which plugins require which, in the right order

Plugins cooperate through two mechanisms: Cordis services and Cordis events^[1].

A service is a capability one plugin publishes that other plugins can consume (for example, a search service, a storage service, or a sandbox service). Events are messages flowing through the runtime — tool-call results, subagent scheduling, context injections — that plugins can listen to and act on.

This is the same pattern used by mature plugin ecosystems: the kernel stays stable, the behavior comes from the graph of services and event handlers.

Traceability is built on the event stream, not on ad-hoc logging. Everything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection^[1].

The Trajectory view lets you inspect these records by source. Resume, fork, search, and replay all operate on the same event stream — which is exactly what makes a harness useful for debugging agent behavior in production^[1].

Session log (append-only):
- system prompts
- reasoning tokens
- tool calls + results
- subagent scheduling
- context injections

Operations on the stream:
- resume / fork / search / replay

The four runtime modes are not special code paths — they are preset bundle compositions of plugins^[1]:

Because modes are just bundles, you can build your own: combine a subset of Standard's tools with a custom model adapter, then launch it as a named profile via dsh --profile <name>^[2].

DeepSeek published the Cordis paper alongside the preview, linked from the official harness page. It describes the kernel design and the dependency model in formal terms^[1].

The official roadmap signals point at: plugin API stabilization before 1.0, more official plugins across models/tools/sandboxes, and DeepSeek's own agent product built on the harness (hinted at by hiring materials about a desktop agent product). The repo does not accept PRs — evolution happens through new plugins and coordinated core releases^[3].