A coding agent is usually sold as one product: pick a model, open a terminal, and hope the tool loop behaves. DeepSeek published this developer preview on August 13, 2026, and it takes the opposite bet. DeepSeek Harness treats the agent runtime as a box of replaceable plugins. Models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the interface can be swapped or recomposed without editing the harness itself.

DeepSeek Harness plugin-first runtime diagram

That is a more interesting release than another model endpoint, but it is also easier to misuse. The repository says this is a developer preview and warns that compatibility-breaking changes are expected. I would test it now if I were building agent infrastructure. I would not attach it to production credentials, durable customer state, or an unattended deployment job.

The practical question is not whether the architecture sounds elegant. It is whether the modularity buys you anything during a real experiment, and whether the runtime gives you enough evidence to debug a bad run before the preview changes under your feet.

A safe preview setup

Start with the smallest useful mode. DeepSeek documents 4 modes: Standard, Code, Minimal, and Creator. Standard exposes the full coding-agent surface. Code lets the model orchestrate several rounds of tool calls through the Code Mode SDK. Minimal keeps only a shell and a file editor, which makes it useful for controlled harness comparisons. Creator is for inspecting the current runtime and experimenting with Cordis plugins in memory.

That menu suggests a sensible test sequence. Begin in Minimal mode inside a disposable repository with fake credentials and no network access beyond the services you explicitly need. Give the agent a fixed task such as editing one fixture file and running one test command. Record the tool calls. Then repeat the task in Standard mode. The point is not to see which mode feels cleverest. The point is to identify which extra capabilities change the trajectory.

The official quick start uses npm, while the repository also documents running from source. Pin the exact commit you evaluate. Do not install a moving developer preview globally and assume the next run uses the same plugin contracts. Keep the lockfile, the commit hash, the configuration, and the session export together. If you cannot reproduce yesterday's run, you do not yet have a useful benchmark.

The credential boundary matters more than the install command. Put API keys in a test-only environment. Mount a temporary workspace. Deny access to your normal SSH agent, cloud metadata endpoints, and production databases. DeepSeek Harness gives you more ways to compose an agent, which means it also gives you more ways to accidentally compose an unsafe one. The runtime is not a substitute for the write controls described in idempotent agent actions.

A five-minute smoke test should answer four things. Can the selected model load? Can the tool plugin execute only the command you intended? Does the session survive a restart? Can you remove a plugin without leaving hidden state behind? A preview that fails one of these tests may still be useful for hacking on the framework, but it is not ready for a shared team environment.

What the trace can prove

DeepSeek's most useful design choice is the append-only session log. The project says it records what the model sees, including system prompts, reasoning, tool calls and results, subagent scheduling, and context injections. Its Trajectory view supports resume, fork, search, and replay on the same event stream.

This changes how you evaluate an agent. Instead of asking whether the final patch looks good, you can inspect where the run diverged. Did the model receive an unexpected instruction? Did a plugin inject context after the tool result? Did the agent call the same tool twice because the session state was lost? Did a mode change alter the available capabilities? Those are runtime questions, not model-quality questions.

Use the trace to build a small failure taxonomy. Mark tool-selection errors, context-injection errors, state-recovery errors, and ordinary model mistakes separately. Then replay the same task after changing one plugin. If the outcome changes, you have evidence about the harness. If the trace cannot explain the change, the system is still too opaque for serious infrastructure work.

The replay feature is especially valuable for security review. Export a harmless trajectory, remove a tool, and replay it. The run should fail in a visible way rather than silently finding a new path to the same capability. Fork the trajectory before a write operation and compare a read-only branch with a branch that has a fake write tool. Those are 4 trace operations worth testing: export, remove, fork, and replay. This is the sort of experiment that fixed, bundled agent products make difficult.

There is a catch. A log can show what the runtime recorded without proving that it recorded everything that mattered. The preview page says the system records model inputs, tool activity, subagent scheduling, and context injections. You still need to verify redaction, retention, ordering, and behavior across crashes. A trace that contains secrets is a new security problem. A trace that omits a hidden side effect is false comfort.

Where the preview stops

The plugin-first idea is valuable because agent systems age badly at their seams. Teams swap a model, add a browser, change the memory store, or replace the scheduler, then discover that the product's real behavior lived in undocumented glue. DeepSeek Harness makes those seams explicit. That is the part worth studying.

The developer-preview warning is equally explicit. Compatibility-breaking changes are expected. APIs can move. Plugin assumptions can become invalid. A configuration that works today may not load next week. This is normal for preview infrastructure, but it makes production adoption a poor trade unless you control the fork and can maintain the integration yourself.

Use it when your goal is to learn what an agent runtime should expose, compare tool-loop designs, or build a disposable custom harness. Avoid it when you need stable upgrades, vendor support, predictable audit retention, or an agent that can touch live systems without a human in the loop. The most defensible path is to wrap the experiment behind your own narrow interface, keep the real system of record elsewhere, and promote only behavior that survives replay.

My decision is straightforward: test DeepSeek Harness, but test the runtime rather than trusting the product. The four modes and append-only trajectory give you enough surface area to learn something concrete. The preview status means none of that should be confused with a deployment recommendation. If the experiment cannot isolate credentials, export traces, and repeat a run after a restart, the problem is not that the model needs a better prompt. The harness is not ready.

Sources