DeepSeek Harness: The Agent With No Core
A field guide to how DeepSeek built an agent runtime in which even the loop is a plugin you can swap out of configuration.
Timeline
- 2026-08-13 Repository created / public developer preview begins
- 2026-08-17 dsh 0.1.0
rc.7 shipped; boot, profile/bundle composition, and the plugin-based agent loop in place
The Thesis: Nothing Is Special
Most agent frameworks have a center of gravity — an Agent class, a runner, a loop — that you configure around. DeepSeek Harness starts from the opposite assumption. Everything is a plugin. The model adapter is a plugin. The tool registry is a plugin. The session log is a plugin. The agent loop — the thing that turns one user message into model output and tool calls — is also a plugin.
The consequence is deliberate. There is no privileged core to patch and no "blessed" integration path. You extend dsh by mounting a plugin beside the others, and because a registration is a reversible _effect_, it unwinds when its plugin unloads. Swap the loop, swap the LLM, swap the tool guard. All from configuration, all at the same altitude.
The Mechanism: Cordis
The "everything is a plugin" claim is not a slogan; it is a framework constraint. DeepSeek Harness is built on Cordis, an open pluggable framework whose design is described in the paper _A Programming Paradigm for Spatiotemporal Composability_. In Cordis a plugin contributes services, typed events, and reversible effects into a shared context object, and there is no global registry it bypasses. dsh simply adopts it as the rule of the road: the core runtime is a small set of packages (core/session, core/tools, core/agent, core/agent-loop, llm/llm), each owning a capability exposed under a shared-context key like ctx.llm or ctx.tools.
The loop is the test case. The Agent interface is defined in one package, and the concrete default driver lives in core/agent-loop. A different driver could be mounted in its place, because the rest of the system depends on the interface and the events, not on the driver's internals.
How a Turn Reads
A turn is zero or more steps; a step is one model request plus the tools it calls. Input reaches the driver through a single inbox. The driver opens a turn, claims the next input, assembles prompt sections and tool schemas, streams from ctx.llm, and runs every tool call through a guarded pipeline: tools/pre-execute (allow / deny / ask) → tools/execute → tools/post-execute. Durable events land in the session log; live events fan out over the agent domain. Everything the model can see is a log entry. Everything you can change is a plugin or a patch row.
Where It Stands
DeepSeek Harness is a developer preview. It is moving fast, and it says so plainly in the README: compatibility-breaking changes are expected. What is stable is the architectural bet — that an agent with no core is easier to extend, easier to sandbox, and easier to swap than an agent with a privileged one. The codebase is TypeScript, MIT-licensed, and built to be driven either from the dsh CLI or the bundled Web UI.
Sources
-
deepseek-ai/deepseek-harnessREADME (fetched 2026-08-17) -
docs/architecture.md(fetched 2026-08-17): plugins, profiles, bundles, core packages, events, turn flow -
docs/cordis-primer.mdanddocs/cordis-tutorial/(fetched 2026-08-17): the Cordis framework and composable programming model -
packages/core/agent-loop/README.md(fetched 2026-08-17): the default loop driver -
packages/boot/app-boot/README.md(fetched 2026-08-17): profile composition and boot -
apps/cli/README.mdandapps/cli/src/profile-boot.ts(fetched 2026-08-17): thedshentry point and profile boot
Ready to explore the code?
Start the DeepSeek Harness tour