Inside DeepSeek Harness: An Open-Source Agent Runtime Where Everything Is a Plugin

DeepSeek Harness looks, at first glance, like another local coding agent. It can open a workspace, read and edit files, run shell commands, search the web, invoke skills, delegate to subagents, and keep working across long tasks. But the more interesting part of the project is not the checklist of agent features. It is the decision to make almost all of those features replaceable.

DeepSeek has released Harness as an MIT-licensed developer preview, with a blunt warning that compatibility-breaking changes are expected. The project describes itself with one phrase: “Everything is a plugin.” In this case, that is closer to an architectural rule than a slogan.

What DeepSeek Harness actually is

An agent harness is the software between a model and the environment where the model is expected to do work. The model supplies reasoning and generation; the harness supplies the loop around it — files, terminals, tools, context, permissions, persistence, retries, subagents, user interaction, and the rules that decide what happens next.

Harness is therefore not tied to a single DeepSeek model. Its Web UI can configure DeepSeek directly, add catalog providers such as Anthropic or OpenAI, or connect a custom company gateway or self-hosted endpoint. The model is one component inside the runtime rather than the identity of the runtime itself.

The easiest way to see the product is also unusually simple for a framework this large: with Node.js installed, `npx @deepseek-ai/dsh web` starts the local Web UI on port 3080. The same architecture can also be composed into headless and programmatic forms rather than forcing every deployment through the browser application.

“Everything is a plugin” is literal

DeepSeek Harness is built on Cordis, a plugin framework based on shared contexts, services, typed events, and reversible effects. The architecture documentation says the model adapter, tool registry, session log, and agent loop are all plugins. There is no privileged core that developers are expected to patch when they want to extend the system.

That design produces what the project calls capability seams. A capability can be separated into an interface, a provider that implements it, and a consumer that exposes it to the agent. A local filesystem or subprocess provider can, in principle, be replaced by a remote sandbox implementation without rewriting every model-facing tool that depends on it. The point is not simply to add plugins; it is to make the boundaries between agent capabilities explicit enough that whole pieces can be swapped.

This makes Harness feel less like an application with an extension store and more like a runtime that happens to ship with an application. Even the Web app and the headless runner are assembled as bundles layered onto a shared base of model adapters, tools, persistence, sandboxing, settings, credentials, and policy.

Agent Presets turn one runtime into different agents

The most visible expression of that composability is the Agent Preset system. A preset is not just a personality prompt. It is a per-session composition that determines the tools, prompt sections, skills, and other capabilities an agent can see. Scope resolves from agent to preset to global, so multiple sessions can run different agent configurations inside the same process without exposing every capability to every agent.

The repository currently ships four default presets. Standard mode is the full coding agent with file editing, shell access, file and web search, skills, planning, goals, subagents, and workflows. Minimal mode deliberately strips that down to just persistent Bash and `str_replace_editor`. Cordis, shown as Creation mode in the interface, adds runtime inspection, plugin experiments, and guidance for creating new presets.

The fourth preset is especially interesting. The repository directory is named `code`, while the product labels it PTC mode. It keeps the Standard capabilities but presents tools through the Code Mode SDK, allowing the model to write a TypeScript program that combines multiple operations into one `run_code` execution. Instead of bouncing between the model and individual tools after every small step, intermediate work can stay inside the execution environment.

That is a useful reminder that a harness can change a model’s effective behavior without changing the model weights. Tool selection, tool schemas, system prompts, context projection, execution strategy, and the number of model-tool round trips all sit outside the model. Comparing the same model under two harnesses is therefore not necessarily comparing the same system.

The session log is more than chat history

One of the strongest engineering ideas in Harness is its session model. A session is an append-only stream of typed events and acts as the source of truth for the agent’s interaction history. The LLM message history is derived from that log rather than maintained as a separate, loosely synchronized copy.

The architecture states the invariant succinctly: “Model-visible means logged.” User messages, model requests, raw streamed chunks, assembled assistant messages, tool calls, tool results, request configuration, and other durable state are recorded so the system can reconstruct what the model actually saw. The request header can include the effective model configuration, rendered system prompt, and assembled tool schemas.

This matters for more than resume buttons. Agent failures are notoriously difficult to diagnose when a system stores only the final conversation. If a tool result was transformed, context was compacted, a model route changed, or a new instruction arrived during execution, a replayable event log gives developers a path to auditing and reproducing the run rather than guessing from the final answer.

Tool use goes through a control plane

Harness also treats tool execution as a pipeline rather than a direct function call. A requested tool call is logged before execution, then passes through pre-execution policy, approval when needed, monotonic guards, the execution wrapper, post-processing, and finally an authoritative result that is logged back into the session. If an approval cannot be answered, the documented path is to deny rather than silently continue.

Code Mode does not bypass those rules. The tool pipeline documentation says both the reserved `run_code` transport and its serialized sub-calls still pass through the same execution pipeline. That is important because composability becomes dangerous if a clever orchestration layer can route around the permission and audit layer underneath it.

Why this is more interesting than an open-source Codex clone

A polished coding agent makes choices on the user’s behalf: which model to use, how context is managed, which tools exist, how sessions persist, when subagents appear, and how the interface behaves. DeepSeek Harness ships defaults for all of those things, but its architecture repeatedly tries to turn those choices back into replaceable components.

That changes the natural unit of customization. Instead of asking only which coding agent to install, a developer can ask which model adapter, execution backend, preset, skill set, persistence layer, tool policy, and interface should make up a particular agent. A writing agent and a coding agent do not have to be separate applications; they can be different compositions running on the same host.

It also makes DeepSeek’s choice to support other model providers more meaningful. If the agent runtime is the product, using an Anthropic or OpenAI model inside it is not an edge case. It is evidence for the project’s larger claim that the model itself should be swappable.

The trade-off is complexity

The same architecture that makes Harness interesting also makes it a demanding project. Cordis compositions, scoped services, capability seams, event sourcing, preset lifecycles, tool policies, multiple front ends, and user-authored plugins create far more surface area than a single-purpose coding assistant. Extensibility also expands the trust boundary: a preset or plugin that can expose shell and filesystem capabilities is not equivalent to a harmless theme extension.

DeepSeek is explicit about the maturity level. This is a developer preview and breaking changes are expected. That makes it an unusually rich project to study and experiment with, but not yet a framework whose APIs should be assumed stable for long-lived production integrations.

What to watch next

The most important test for DeepSeek Harness is not whether it can beat Codex or Claude Code in one generated demo. Early side-by-side examples can show that harness design matters, but they cannot isolate every difference in prompts, context, permissions, cached files, or execution history. The stronger test is whether third-party developers can build materially different agents on the same runtime without having to fork its core.

Watch the plugin ecosystem, custom presets, remote execution providers, session-analysis tooling, and the ways teams use Headless or SDK interfaces outside the bundled Web UI. If those layers grow independently, DeepSeek Harness may become useful for a reason that has little to do with being DeepSeek’s own coding assistant.

The project’s most consequential idea is simple: a model is only one part of an agent, so the rest of the agent should be software that can be inspected, replaced, replayed, and recomposed. DeepSeek Harness is an attempt to open-source that layer.