DeepSeek Harness Makes the Agent Runtime Itself Programmable

Most coding-agent products compete on a familiar axis: model quality, tool access, autonomy, or the smoothness of their chat surface. DeepSeek Harness is pursuing a stranger boundary. Its claim is that the harness should not be a fixed shell around an agent. The shell itself should be composed from plugins, while every run should leave behind a detailed, exportable account of what actually happened.

That combination matters because agent failures are often not model failures in the narrow sense. A result can be shaped by a hidden system prompt, a silently loaded skill, an unexpected tool payload, an opaque context selection, or a UI behavior that makes a capability difficult to discover. A product that treats those layers as configurable components gives users a different kind of leverage: not merely asking an agent to do work, but examining and changing the conditions under which it works.

Two claims define the experiment: everything is a plugin, and every run is traceable

The developer preview is organized around two unusually strong propositions. First, “everything is a plugin”: not just extensions added after the fact, but the sidebar, tool-use capabilities, system prompt, and other individual pieces of the experience. Second, every run is traceable: messages, loaded skills, tool calls, payloads, tool results, timing, turn counts, and the model’s visible reasoning can be inspected in a trajectory view.

Neither proposition is especially radical alone. Plugin systems are common; run logs are common. The distinctive move is their granularity. A sidebar is not a permanent piece of furniture. A creator capability is not an undocumented product mode. A system prompt is not an invisible constant. Each is presented as something that can participate in a composition.

“Every single call, every single tool call, every single message, every single skill that’s loaded” can be examined—down to the exact tool payload and its result.

That is a direct contrast with products that expose polished outcomes while keeping much of the runtime hidden. Transparency does not automatically make a harness better—raw traces can overwhelm people, and visible reasoning has its own reliability and safety questions—but it changes the debugging posture. Instead of inferring why an agent made a filesystem call, a user can inspect the call, its working directory, its payload, its result, and the surrounding context.

Cordis is an attempt to make composition reversible rather than merely extensible

The Harness is built on Cordis, whose associated paper supplies a more formal ambition than “a plugin framework.” The presenter describes the central idea as an action calculus where an action has an inverse: add something, remove it again, and avoid unwanted side effects. The paper’s vocabulary—dynamic composition, temporal composability, and spatial composability—is useful because it names the difficult part of extensibility.

Temporal composability asks whether a component can be introduced and later withdrawn cleanly. Spatial composability asks whether dependencies between components can be declared and reactively managed. Ordinary extension systems tend to make the “add” path easy. Their costs show up later: residual state, ordering constraints, implicit dependencies, and a growing set of features nobody feels safe disabling.

The preview does not establish that Cordis solves those problems in production. The demonstration is deliberately practical rather than a proof of the underlying mathematics. Still, reversibility is the right standard to aim at for an agent shell that may dynamically load skills, UI widgets, tools, and custom behavior during a working session. If the agent can create capability, it also needs a disciplined way to contain, stop, and undo capability.

A configuration file can remove a visible part of the product

The smallest demonstration makes the architecture concrete. In the web profile’s cordis.patch.yaml, adding a patch for the plugin ID ui.sidebar with disabled: true removes the sidebar on reload. Returning the configuration to an empty list restores it.

This is not a dramatic end-user feature; it is currently a developer-preview workflow, edited in a config file rather than toggled in the UI. But it reveals the intended unit of control. The sidebar is not a special case. The same approach is meant to apply to the components listed under Plugins, and the project encourages third parties to add more of them.

Creator mode turns a request into a session-local capability

The sharpest demonstration comes from creator mode. In this preset, the harness automatically loads a Cordis plugin-development skill. The user asks for a capability in ordinary language; the agent builds a plugin during the session and then asks for approval before adding it.

Two intentionally modest examples show the loop. A request for a cat overlay produces an animation moving across the bottom of the screen. A request for a calculator overlay produces a GUI calculator in the lower-right corner. Both are rough—the calculator’s controls are confusing enough that the presenter has to discover which button is division, addition, and multiplication—but that roughness is informative. The point is not that these plugins are polished. It is that a session can acquire a new surface, have that addition approved, stop it to remove it, start it again, and potentially persist it.

That makes creator mode closer to capability synthesis than conventional extension installation. The important governance boundary is the confirmation step. An agent that can write and activate a plugin has changed the user’s environment, not merely answered a prompt. Approval turns that into an explicit transition rather than a silent side effect.

Traceability is useful only if it reaches the level where failures occur

The Flask to-do-app example is intentionally simple, but it exposes the trace format at the right resolution. The trajectory view displays the system prompt, user prompt, loaded context, assistant message, visible reasoning, Bash invocation, directory, payload, returned result, duration, and turn statistics. A session can also be exported as a ZIP containing session.jsonl.

For a coding harness, this is more consequential than a pretty activity timeline. Consider the questions raised by a surprising result: What instructions were active? What context was injected? Did the model inspect the target directory before writing? Did a tool receive the arguments one expects? Did the model take ten turns because it was stuck, or because a provider was slow? A trace that answers those questions makes evaluation and incident analysis substantially less mystical.

It also makes runs portable. A JSONL record is not automatically reproducible—providers, model versions, tools, and external state still matter—but it is a better artifact for review than a final chat message. The preview’s strongest product instinct may be this: agent work should leave evidence that can be read by somebody other than the agent that produced it.

The model layer is deliberately plural

Although branded DeepSeek Harness, the demonstration does not confine users to DeepSeek’s API. The setup begins with an API key flow at DeepSeek’s platform, but the Models settings support adding providers. The presenter connects OpenCode Go for open models and a custom Ollama instance running on a Dell Pro Max with GB10 hardware—described as a DGX Spark implementation. He then switches to an Ollama-hosted GPT Open Source 120B model and fetches additional available models, including Gemma variants.

There is one explicit limitation: a ChatGPT subscription cannot, as far as the presenter knows, be connected directly. The broader point is architectural rather than commercial. A harness that treats providers as replaceable can make model choice part of the operating context: a user can select a model appropriate for a task, local hardware, or cost envelope without moving to another interface.

DeepSeek Harness vs. Claude Code: a concrete example

Think of both products as ways to ask an AI agent to modify a repository. The practical difference is not simply “one writes code and the other does not.” Claude Code is a mature coding-agent workflow: you open a project, give it an instruction, and it reads files, runs commands, edits code, and reports back. You can shape that workflow with project instructions, permissions, hooks, and integrations. Its primary unit of work is the coding task in a repository.

DeepSeek Harness can perform that same kind of task, but its preview is trying to make the agent environment itself the unit of change. Its native UI pieces, agent presets, loaded skills, tool calls, and session record are intended to be visible components in a composable runtime. This does not mean Claude Code has no configuration or extensibility; it means the Harness is making a stronger claim about how much of its own surface and execution machinery should be inspectable and mutable.

Example: a coding agent needs a persistent calculator while it works

Imagine asking an agent to add pricing logic to a SaaS application. During the task, you realize you want a small calculator pinned in the lower-right corner of the agent interface so you can check annual-contract, discount, and usage-tier arithmetic without leaving the working session.

With Claude Code, the natural response is to use an existing calculator, ask the agent to calculate values in chat, or build a separate local tool/page for the project. Claude Code may help write that tool, but the request is still outside the ordinary shape of a repository-editing task: you are changing your own working interface, not just the codebase.

With DeepSeek Harness creator mode, the demonstration’s intended flow is: ask for “a calculator overlay in the bottom right”; the harness loads its plugin-development skill, generates a session plugin, asks you to approve adding it, and then runs that UI capability alongside the agent. You can stop it to remove it, start it again, refine it by prompting, or persist it. The video’s calculator is visibly rough, so this is an architectural example rather than evidence of a polished calculator product.

Example: the agent behaves unexpectedly

Suppose the agent unexpectedly runs a shell command in the wrong folder or spends many turns on a trivial Flask to-do app. In either environment, you can inspect the repository and the resulting changes. DeepSeek Harness’s stated differentiation is its trajectory view: it exposes the system prompt, loaded context and skills, assistant messages, tool payload, tool result, timing, and turn count, then allows a session export as session.jsonl. The point is to diagnose the run from its execution record instead of reconstructing it from the final answer.

That trace-first design is valuable for evaluation and debugging, but it is not automatically a reason to replace Claude Code. A verbose trace can be hard to interpret, and visibility does not guarantee correctness, security, or reproducibility. The meaningful choice is therefore not “transparent versus opaque”; it is whether this degree of runtime programmability and inspection is worth the preview-stage complexity for the task at hand.

What this preview gets right—and what it has not earned yet

The preview earns attention because its pieces reinforce one another. A plugin-oriented runtime without traces can become impossible to debug. Traces without modularity can document a fixed black box without offering a path to alter it. Creator mode without reversibility risks turning every session into a pile of irreversible improvisations. Together, the ideas describe an agent environment where change is meant to be observable and retractable.

But the operative word is still preview. The presenter repeatedly notes that it is not mature and that some workflows are “a little bit scuffed.” Plugins are edited through configuration today; the generated calculator illustrates that dynamically created UI can be functional while still needing substantial iteration. The promised ecosystem, easier enable/disable controls, and mature user experience remain future-facing. Nor does a detailed trace by itself prove that a run was correct, secure, or reproducible.

Practical lessons for evaluating agent harnesses

1. Inspect the runtime boundary. Ask whether prompts, tools, context, skills, and UI behavior are observable—or whether the product only reveals a final answer.
2. Prefer clean disable paths to feature accumulation. A plugin system is credible when a component can be removed without leaving broken dependencies or invisible residue.
3. Make environment changes approval-worthy. Generating a plugin or modifying a workspace is qualitatively different from drafting text; the confirmation model should reflect that.
4. Export evidence, not just outcomes. Session-level records such as JSONL give teams something to inspect, compare, and audit after an agent run.
5. Judge generated capabilities by their iteration loop. The first calculator can be awkward. What matters is whether it can be reviewed, adjusted, stopped, restarted, and eventually made durable.

The most provocative part of DeepSeek Harness is not the question of whether it replaces Claude Code. It is the suggestion that the next useful agent interface may be less like a sealed application and more like a visible runtime: one where users can see the machinery, alter the machinery, and undo what they altered.