The Next Agent Harness May Not Need a Core That Can Never Be Replaced

On August 13, DeepSeek published DeepSeek Harness on GitHub.

One sentence in the README stands out.

“Everything is a plugin.”

Plugins are familiar. Claude Code has Skills, Hooks, and MCP. Codex, OpenCode, and Gemini CLI have their own extension surfaces. Read in isolation, the sentence sounds like another plugin system. The difference appears a few lines into the architecture document.

The model adapter is a plugin. The tool registry is a plugin. The session log is a plugin. The agent loop that receives messages, calls a model, executes tools, and decides whether work should continue is also a plugin.

DeepSeek Harness is open source under the MIT license. Its GitHub source and npm package are public. On August 14, 2026, the npm package was 0.1.0-rc.6. The project is explicitly marked as a developer preview, with compatibility-breaking changes expected.

The important question is already present in the code. Does an agent runtime need a permanently fixed core?

The replaceable agent loop is where the design diverges

Many developers use Claude Code or Codex every day without using the word harness.

Give Codex a bug to fix. The model interprets the task and chooses its next step, but it does not manage the computer by itself. Another system decides which files are readable, how commands execute, when a dangerous action needs approval, how tool results re-enter context, and what happens when the conversation grows too long.

That system organizes the model, tools, permissions, memory, and execution process. It is the harness.

The same model can behave very differently inside two harnesses during a long task. One system reads a file before editing and refuses to overwrite a newer external change. Another writes an old version back. One system can distinguish a command that never started from one whose result is unknown after a crash. Another can only run it again.

The model affects how far one reasoning step can go. The harness often affects whether the task finishes reliably.

Most agent products keep a relatively stable runtime core. Plugins add tools, data, and workflow hooks. The loop that drives the agent usually stays outside the plugin boundary.

DeepSeek Harness keeps decomposing. The agent loop has no privileged position. Profiles can select different loops, and a new workflow does not have to patch one global driver before it can join the runtime.

That freedom creates two immediate obligations. The system must know where a replacement applies and what state should return when the plugin unloads.

A plugin can replace a service, then it has to clean up

Cordis, the system under DeepSeek Harness, places plugin-provided services, events, and effects into a shared context.

A mounted plugin can add a service or replace an existing one. When it unloads, its registrations and effects unwind. Components that depend on those capabilities receive the change.

The Cordis paper calls this spatiotemporal composability. The code gives the idea a practical meaning. A replacement has to identify what changed, the scope in which it applies, how long it lasts, and what state returns after removal.

The web and headless modes of DeepSeek Harness are different profiles. They share a base layer, then add bundles, a user patch, and command-line overlays. The execution world can change as well. E2B can provide a remote filesystem and subprocess environment, and Bash, PTY, and LSP follow the lower-level provider instead of requiring separate E2B-specific versions.

The official documentation still labels this E2B composition an experimental proof of concept. The architecture is visible; its maturity is a separate question.

The session system shows how this design reaches durable state.

A user sees chat messages. DeepSeek Harness stores an append-only event stream. User inputs, streamed assistant chunks, tool calls, tool results, and step boundaries become events. The next model-visible history is derived from those events.

The architecture document states an important invariant. Anything visible to the model must be reconstructable from the session log.

When context grows too large, the system can shorten a large tool result and compact older history. The model-facing projection becomes smaller while the original events remain. Resume, forks, transcripts, and telemetry derive from the same record.

After a crash, the record can distinguish two cases. A tool that never started can be scheduled again. A tool that was dispatched without a recorded result becomes outcome unknown, warning the model against casually repeating a side effect.

Repeating a read usually costs time. Repeating a command that changes external state can leave a real cleanup problem.

Component documentation also records what the model sees, the token cost, and possible KV-cache effects. It does not provide a cross-product cost benchmark. It does show that context economics are part of the component contract.

The agent can inspect the harness that carries it

Further down the Cordis layer is one of the project's less common capabilities.

DeepSeek Harness exposes Cordis tools that let the model inspect services, plugins, tools, and events in the current process. The model can also define a temporary plugin that registers a tool, contributes prompt content, listens to events, or adds a browser UI slot.

The agent can inspect its harness, then propose a small capability for the current task.

The boundary matters. A temporary plugin still requires the user to start it in the interface. It exists only in the current process, disappears after restart, and is not written back into persistent configuration. The documentation also says the internal VM is not a security boundary. The capability should be treated like Bash access.

Runtime inspection and temporary extension are accurate descriptions of the current feature. The model used to be limited to prepared tools. Here it can first inspect its surroundings and then propose an extension for the task at hand.

DeepSeek Harness takes a similarly open approach to other agents.

Its subagent interface can host different providers. The current process can start a fresh child agent or fork completed parent history. External providers can connect through ACP. The runtime can also start codex app-server --stdio or call Claude Code through Anthropic's Agent SDK.

In other words, dsh can treat Codex and Claude Code as two external subagent providers.

The current bridge is narrow. Both providers are disabled by default. They receive an independent task and the same workspace, not the complete parent conversation or tool set. The parent receives only the final response, without continuous progress, resume, pooling, or interactive approvals.

These limits are documented rather than hidden. Many package READMEs include Known Limitations and Deferred Work, spelling out which integrations are proofs of concept, where evaluators are missing, and when intermediate progress can be lost.

The ambition is large, and the boundary usually sits beside it. That documentation habit may be the project's most encouraging early signal.

How it differs from Claude Code, Codex, and OpenCode

Competing systems all work with tools, permissions, memory, and multiple agents. They make different parts permanent.

Claude Code is a mature product. CLAUDE.md, Skills, Hooks, MCP, and Subagents form a familiar extension model. The product has a broad extension surface, while Anthropic still decides which internal parts can be replaced completely.

Codex CLI is open source under Apache 2.0. Its Rust implementation combines the local agent, sandbox, approvals, and App Server protocol into one operating system, now connected to desktop, IDE, and cloud workflows. Codex extensions serve that product system.

OpenCode uses the MIT license, supports many providers and local models, and offers a TUI and clients for daily work. Freedom to choose the model is one of its clear advantages.

Gemini CLI places Gemini, multimodality, search, and the Google ecosystem inside an Apache 2.0 terminal agent. LangChain Deep Agents is closer to an embeddable Python framework, with LangGraph-backed subagents, filesystem backends, memory, and tracing.

Claude Code, Codex, and Gemini CLI prioritize a coherent product. OpenCode gives developers more model choice. Deep Agents helps developers embed an agent in an application. DeepSeek Harness concentrates on runtime composition, to the point that the agent loop itself has no permanent seat.

That choice does not automatically produce a better experience.

Most users want the agent to fix a bug. They do not care which provider implements the session log, and they do not want to learn profiles, bundles, scopes, and patches. More replaceable parts create more configuration, compatibility, and debugging work. A fixed core refined over time can deliver a more coherent product.

DeepSeek Harness security is also early. It exposes read-only, workspace-write, and danger-full-access modes, with read-only as the default. Linux, macOS, and Windows use different isolation mechanisms. When a required capability is unavailable, the design aims to fail closed instead of silently falling back to unrestricted execution.

Network and full process policy are not yet expressed through the same sandbox vocabulary, and Windows isolation is explicitly partial. Approval currently supports one-shot ask and never modes without a durable grant store. Plan Mode guides model behavior, while sandbox and approval remain responsible for enforcement.

DeepSeek Harness also has no published comparative benchmark. Its BENCHMARK.md mainly describes preparing isolated workspaces and sessions. It does not establish that dsh is faster, more accurate, or cheaper than Codex, Claude Code, OpenCode, or Gemini CLI.

The architecture and implementation choices are inspectable today. Production maturity requires later releases and deployment evidence.

What keeps an agent continuous when no core is permanent?

For the last two years, agent products have often been understood through model names. Claude Code is attached to Claude, Codex to OpenAI, and Gemini CLI to Gemini. The model becomes the product identity, while the harness delivers it to the user.

DeepSeek Harness loosens that binding.

The model can change. The execution environment can change. Subagents can come from other products. The session implementation and agent loop can change. A capability available to the model can even be added temporarily inside the current process.

If all of those parts can move, what keeps the agent continuous?

The Ship of Theseus replaces its planks one by one. When none of the original material remains, is it still the same ship?

DeepSeek Harness gives an engineering answer. Continuity does not have to live in one untouchable implementation. Service contracts, reconstructable session events, and unload rules let the system understand what it did before and after a component changes.

Stability moves into contracts, event semantics, and effect cleanup. Implementations can change, but the exchange between them has to stay explicit. Without those rules, “everything is a plugin” quickly becomes “anything can break.”

The fewer permanent components there are, the more important those contracts become. The unusually detailed package READMEs repeatedly answer the same questions. What does a component provide, what can it see, what remains after unload, and how does it affect tokens or the KV cache?

The same principle appears at a narrower tool-result boundary. MCP Slim Guard, maintained by LIU/lennney, separates upstream execution from the result projection shown to a model, so a shorter first result can still recover the original exactly. It does not recompose an entire harness. It makes one easy-to-blur component boundary explicit. The implementation and limitations are available in lennney/mcp-slim-guard.

DeepSeek Harness has not proved that this design will become the industry's future. It has published a choice that others can now inspect and test.

The next agent harness may not need a core that can never be replaced.

It still needs explicit contracts, traceable history, and a human's power to stop execution. Models, tools, memory implementations, and execution environments can then be selected for the task in front of them.