DeepSeek Has Pluginized the Agent Core Too: The Real Bet Behind Harness

Suppose the same team needs to build two Agent products.

One works through a Web interface, stores sessions in SQLite, and allows Bash and file tools; the other only runs one-off tasks, writes sessions to JSONL, disables the local Shell, and is invoked via a Python SDK. Later, the second product even wants to swap out the default Agent Loop.

If the model, loop, tools, state, and interface are all tangled inside a single Agent class, the team typically has only two paths: keep adding conditional branches, or fork the Agent Core. The more branches, the harder it becomes to synchronize fixes and upgrades across the two products.

DeepSeek Harness aims to change exactly this point. Its "Everything is a Plugin" does not mean search and MCP can be plugged in; it means the model adapter, Agent Loop, Session Log, Tool Registry, and product Surface all enter the same Cordis plugin semantics.

This is also where it gets truly radical: the Agent Core is no longer an untouchable center.

My assessment is that DeepSeek Harness's core bet is not to build a coding assistant with more features, but to let Agent product differentiation be expressed through composable, uninstallable, and observable runtime capabilities, reducing the need to copy the Agent Core. It gains finer replacement and lifecycle boundaries, but also shifts complexity onto the plugin graph, interface contracts, version migration, and diagnostics.

Is It a Harness, a Runtime, or a Product?

Harness, Runtime, Framework, and Product have no single enforced definition in the industry. To evaluate DeepSeek Harness, we can first adopt a set of operational boundaries:

• Framework provides libraries and abstractions for developers to describe flows, state, and components.
• Runtime is responsible for loading, scheduling, lifecycle, and actual execution.
• Agent Harness organizes context, tools, state, permissions, feedback, and stopping conditions around a model.
• Product delivers a default interface, policies, experience, and delivery commitments on top of the underlying capabilities.

DeepSeek officially positions dsh as an open-source agent harness. The fixed source code simultaneously exhibits clear Runtime characteristics: Cordis handles loading the plugin tree, Profile and Bundle determine composition, and Web, Headless, and SDK drive a common underlying semantic.

It does provide a runnable interface, but it is still a Developer Preview. Therefore, "the Web UI can open" and "it is already a mature Coding Agent product" are two different things.

To summarize in one sentence: DeepSeek Harness is a runtime chassis that uses a Cordis plugin graph to recompose Agent products, not a plugin framework that only allows adding tools around a fixed Agent Core.

What "Everything" Includes as Core Capabilities

The architectural judgments in this article are bound to the official commit 47f943859bef60e4160492346772ded9b24f765a. The fixed architecture document explicitly states that the model adapter, tool registry, Session Log, and Agent Loop itself are all plugins and can be replaced via configuration.

Core Capability	Execution Responsibility	Change After Entering Plugin Semantics
LLM Adapter	Unifies messages, streaming output, and model protocols	Swapping the model backend does not require changing the Agent Loop
Agent Loop	Claims input, requests the model, executes tools, and decides whether to continue	"Changing the loop" and "changing the Provider" both become compositional actions
Session Log	Saves Turns, Steps, messages, and tool events	The state backend and the loop can evolve separately
Tool Registry	Aggregates schemas and executes tool pipelines	Tools, execution Providers, and policies do not need to be bound in a single class
Surface	Entry points like Web, Headless, SDK	Multiple product entry points do not need to each copy the Agent Core

The most unusual part is that the Agent Loop is also just a plugin. Typical plugin systems usually assume the main loop is non-replaceable, with extensions happening only at the edges; DeepSeek Harness places the loop, state, and tools within the same composition mechanism.

But "a replacement seam exists" cannot be directly written as "any implementation is compatible." Error semantics, streaming events, state formats, security policies, and performance characteristics still require contract tests and controlled experiments. Splitting code into packages is an architectural fact; stably composing those packages is engineering capability.

Cordis Manages Not Just Registration, but When Plugins Exist

If plugins only register a tool in a Map at startup and are destroyed together when the process exits, ordinary dependency injection is sufficient. The truly difficult scenario for an Agent Runtime is dynamic change: a Workspace is loaded or unloaded, a Provider temporarily appears or disappears, configuration is updated, and local capabilities only exist within the lifecycle of a specific Agent.

Cordis calls its design goal spatiotemporal composability. Compressed into engineering language, it boils down to two questions:

1. Can the services, events, and child scopes registered by a plugin be reclaimed as traceable side effects upon uninstallation?
2. Can a consumer declare what capabilities it needs and re-coordinate when a Provider appears, disappears, or changes?

Therefore, a Cordis Context is not just a service container; it also tracks the effects produced by plugins. This makes "partially install, then completely uninstall" a design goal, rather than relying on the developer to remember every cleanup operation.

Boundaries are equally important. Cordis officially still states that the API is not yet stable; the related paper materials are a design framework continuously maintained by the project author, not a reliability theorem that has reached peer-reviewed consensus. Reversible lifecycles reduce one category of coupling risk but do not automatically eliminate race conditions, transient dependency gaps, and version compatibility issues in complex plugin graphs.

How Five Components Form a Truly Running Product

Looking only at the plugin directory cannot answer "what is actually enabled for this round." DeepSeek Harness uses five components to turn installed packages into a running composition.

Profile: Expressing Product Choices

A Profile is a named product composition. It decides which Bundles to use and saves the product's own configuration overrides. Web and Headless can share base capabilities while choosing different entry points and default policies.

Bundle: Distributing Capability Sets

A Bundle treats a set of Cordis configuration lines and code as a reusable composition. The base Bundle provides capabilities like models, tools, persistence, Sandbox, settings, credentials, and telemetry; different Surfaces then add their own increments.

Patch: Injecting Environmental Differences

Bundle, Profile, Home, and command-line Patches form the final plugin tree layer by layer. Important note: Patches locate and replace entire configuration sections by line ID, not arbitrary YAML deep merging. It is more predictable, but also requires the configurator to understand the full meaning of the replaced lines.

Capability Seam: Defining Replacement Boundaries

Officially, a complete seam is broken down into a Service Definition, Provider, and Consumer. The Consumer targets a stable service, while the Provider decides the local, remote, or specific protocol implementation. Having only an interface declaration does not yet constitute a complete replaceable capability.

Event Log: Preserving Shared Facts

A Session saves model-visible facts by appending events; the model history is projected from the log. UI, replay, persistence, Fork, and Resume are also derived from the same event stream. Different Surfaces therefore do not need to each maintain their own copy of the "current Agent state."

However, the existence of an append-only Log does not mean cross-machine recovery, idempotency of all side effects, or long-task reliability are already established. These conclusions require fault injection and real deployment evidence.

Combined, these five form DeepSeek Harness's product method: Profile selects, Bundle distributes, Patch overrides, Seam isolates implementation, and Event Log preserves shared facts.

Flexibility Does Not Eliminate Complexity

The most direct benefit of pluginizing the Agent Core is confining changes within smaller boundaries.

• Switching the Session backend does not require rewriting the Agent Loop along the way.
• Removing the Shell for a restricted product can be done by withdrawing the relevant Tools and Providers from the final composition, rather than adding branches to the loop.
• Web and Headless share runtime semantics, eliminating the need to maintain two gradually diverging cores.
• A Workspace or a single Agent can possess local capabilities and an independent lifecycle.

The costs are also very specific:

• Current behavior depends on the final plugin tree; reading only a single entry file is insufficient to know what is actually enabled.
• Service contracts must cover not just types, but also errors, stream events, security, and migration semantics.
• Lifecycle errors can manifest as duplicate registrations, dangling events, or transient Provider absence.
• Bundles and multi-layer Patches increase reusability but also increase the cost of diagnosing configuration drift and upgrades.
• Compatibility breakage will still occur during the Preview phase; adopters need to freeze versions themselves and prepare for migration.

So, "Everything is a Plugin" is not getting modularity for free; it is choosing to manage change with an explicit composition graph.

If a product genuinely needs to switch models, loops, state backends, execution worlds, or Surfaces, this complexity may be worth it. If an application has only one fixed Loop, a few tools, and a single deployment, an explicit workflow plus ordinary dependency injection is often cheaper and easier to audit.

To What Step Does the Current Evidence Support?

As of August 14, 2026, the official repository HEAD is still the same as the fixed baseline 47f9438; the repository snapshot's internal version is rc5, while npm's @deepseek-ai/dsh and PyPI's Python SDK are already rc6. PyPI explicitly marks it as pre-release, the official README still labels it Developer Preview and warns of compatibility breakage, and Cordis also still declares its API is not yet stable.

The local records in the research materials can prove more limited things: the fixed source dependencies are installable, the Web build and page inspection are complete, the CLI and configuration parsing entry points can load, and selected Session, Loop, Tools, Jobs, Subagent, and Compaction tests pass. When model credentials are missing, Headless returns MISSING_CREDENTIAL.

This proves the credential gate triggers correctly, but cannot prove that real model E2E is complete, nor can it conclude that production-grade recovery, security, or scheduling capabilities are established.

A Table to Judge Whether It Is Worth Adopting Now

Usage Scenario	Current Recommendation	What to Supplement Before the Next Step
Researching Agent Runtimes, replacing Loops, state, or Providers	Suitable for isolated PoC	Freeze Commit and package versions, export the final plugin tree
Deriving Web, Headless, SDK, etc. entry points from the same chassis	Worth verifying composition benefits	Check consistency of state, permissions, and error semantics
Needing to dynamically load/unload capabilities per Workspace or Agent	Cordis route is targeted	Test repeated load/unload, Provider disappearance, and resource reclamation
Only having a fixed Loop, a single backend, and a few tools	Prioritize simpler solutions	First prove that dynamic composition can repay configuration and diagnostic costs
Preparing to carry critical production tasks	Caution is currently advised	Real model E2E, fault injection, migration drills, and permission audits
Wanting to directly prove it is superior to mature products or workflow frameworks	Insufficient evidence	Compare after fixing models, tasks, permissions, budgets, and versions

This table is not responsible for giving the project an overall score, but for separating architectural interest from production evidence. DeepSeek has made public a radical Runtime design whose source code can be read and whose local paths can be run; it has not yet completed stable interfaces, migration, fault recovery, and security verification on behalf of the adopter.

Conclusion

The most noteworthy part of DeepSeek Harness is not the number of plugins, but that it demotes the Agent Loop, Session, LLM, Tools, and Surface to ordinary participants in the plugin graph. The product no longer grows around a core class that must be forked, but is composed from Profile, Bundle, Patch, Capability Seam, and Event Log.

What it truly gains are replacement boundaries and lifecycle semantics; what it truly pays are composition, contract, version, migration, and diagnostic costs. For teams needing to derive multiple Agent products or dynamically replace execution capabilities, this is a route worth serious testing; for fixed, simple applications that emphasize stable delivery, a smaller explicit workflow may still be the better answer.

The most reasonable attitude at this stage is neither to chase it as a mature product, nor to ignore it because it is a Preview: treat the fixed source code as a verifiable architectural proposal, and keep marking production capability as yet to be proven.

References

1. DeepSeek Harness Official Repository: https://github.com/deepseek-ai/deepseek-harness
2. Fixed Commit Architecture Documentation: https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/docs/architecture.md
3. Fixed Commit Capability Seams: https://github.com/deepseek-ai/deepseek-harness/blob/47f943859bef60e4160492346772ded9b24f765a/docs/capability-seams.md
4. Cordis Official Repository: https://github.com/cordiverse/cordis
5. DeepSeek Harness Python SDK: https://pypi.org/project/deepseek-harness-sdk/

Evidence Boundaries

• Core plugin scope, composition order, and Capability Seam: fixed official source code.
• Cordis's spatiotemporal composability: the project author's design framework, not considered peer-reviewed consensus.
• Benefits, costs, and adoption table: engineering analysis based on the fixed architecture.
• Local records: limited to executed commands and page scope, no real model E2E.
• Competitor performance, production recovery, security, and cross-machine scheduling: not verified, no conclusions drawn.