Skip to content
Published on

The Plugin Kernel Architecture of DeepSeek Harness — What Makes an Agent You Can Rewind

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

This post is based on items I read directly from the Hacker News API and the GeekNews feed on 2026-08-15. Scores and rankings keep moving.

What was up there

An item read from the Hacker News API. The title is DeepSeek Harness developer preview, the item number is 49285244, and as of 2026-08-15 it stood at 718 points with 297 comments. The link points to DeepSeek's Harness page. The same item appeared in the GeekNews feed.

One of the comments is from one of the authors, saying this is only an early developer preview and to expect many rough edges and compatibility-breaking changes. The license is MIT.

The sentence "everything is a plugin"

The central claim on the page is that everything is a plugin, and the list is specific. Models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI are all said to be provided by plugins.

What stands out is the back half of that list. Making tools into plugins is common. But loops, scheduling, and the UI as plugins means treating the agent's own control flow as replaceable.

The layer that manages this is introduced as a kernel called Cordis. It handles mounting, unmounting, and dependencies, and plugins communicate with each other through Cordis services and events.

The comments filled in the background. Cordis did not appear for the first time here; it is a plugin system that has been used in another project for years, and the core of it is loading and unloading plugins without restarting a running process. That it reverts the state and side effects a plugin created when it unloads was named as its distinguishing feature.

Why an undoable unload is a hard problem

Loading a plugin is easy. Unloading is the hard part.

Think about what a plugin does while it is alive. It attaches event subscriptions, opens sockets, registers timers, and registers services other plugins reference. Dropping the reference removes none of that. The timers keep firing and the subscriptions keep getting called.

That is why most plugin systems are effectively one-directional. You can load, and to unload you restart. But in an agent, restarting is expensive, because the session in flight and the context you accumulated go with it.

This is where requiring teardown handlers matters. It makes cleanup a contract rather than an option. With it, you can swap a single tool mid-session, or unload only the plugin that is misbehaving and leave the rest running. Carried to your own system the question becomes: to change one tool in our agent, what has to die? Usually the whole process.

The real feature is the event log

The most practical part of the page is tracing. Everything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and their results, subagent scheduling, and every context injection.

That last item matters. Recording context injections too removes the most common dead end in agent debugging.

When an agent behaves strangely, what we look at is usually the prompt we wrote. But what the model actually received is that prompt plus several fragments the system appended — earlier summaries, search results, file contents, tool descriptions. If there is no record of when those went in and in what order, we end up staring at what we wrote while trying to explain the consequences of what we did not send.

And the page says resume, fork, search, and replay all operate on that same event stream. That sentence is the heart of the design. The four capabilities were not built separately; they were derived from one data structure. One comment picked this tracing out as the best part of the project, noting that commercial services generally do not let you reach raw records at that level.

Four runtime modes

The page presents four modes.

  • Standard mode: the full toolset, with file editing, shell, search, planning, and subagents.
  • Code mode: the model generates TypeScript to orchestrate multi-step operations.
  • Minimal mode: only a bash shell and a file editor. Explicitly stated to be for benchmarking.
  • Creator mode: building custom presets, inspecting the runtime, and experimenting with plugins.

It is interesting that minimal mode names benchmarking as its purpose. It is now widely understood that a large share of the score in agent benchmarks comes from the harness rather than the model. Keeping a mode with tools pinned to a minimum lets you measure the model's contribution separately from the tooling's. If you run your own evaluations, that idea alone is worth taking.

The launch form is below and Node.js is required. The full source lives in the deepseek-ai/deepseek-harness repository.

# Example: the launch form given on the page
npx @deepseek-ai/dsh web

The objection from the comments

The sharpest objection went at the plugin structure itself. One comment wrote that products that depend on community plugins for their features work fine for the first six months and then accumulate incompatible, abandoned plugins with no consistency and no governance.

That is hard to dismiss, because it has happened repeatedly across ecosystems. Seen precisely, though, the risk comes not from the plugin structure but from plugins being both the extension point and the base functionality. When core features ship only as third-party plugins, the moment one is abandoned there is a hole in the product.

Another comment simply asked what this actually is, noting that the README is bare apart from installation instructions. Good architecture that does not show what you can build with it does not get adopted.

How to apply this

Even if you do not adopt the project, two things are worth taking.

First, record what was actually sent to the model. Most teams log the prompt template and the final response. Log the fully assembled input, the tool call results, and everything the system slipped in between, in order, and a large share of previously irreproducible bugs become reproducible. If storage cost worries you, start with failed sessions.

Second, build a separate minimal configuration for evaluation. Keeping one profile with tools pinned to a minimum lets you tell whether a performance change on a model swap came from the model or from the tooling.

Who this does not apply to

If you use a finished coding tool rather than building agents, this structure is background. Even so, whether you can reach the session record is a reasonable criterion when choosing a tool.

Agents that handle only one-shot tasks are also largely outside this. When sessions are short and a failure just means running it again, resume and fork are not needed. This design earns its value when sessions are long and rebuilding context is expensive. The preview status should be taken at face value too. The author says the API may change, so building a product on this now is only sensible if you have the capacity to follow those changes.

Summary

The idea that lasts here is not the slogan that everything is a plugin. It is that representing an agent's execution as a single append-only stream turns resume, fork, and replay from features you build into consequences of that representation, and that making teardown a contract lets you change a running system without restarting it. Neither is specific to agents.

Sources and related reading

The reading of teardown handlers and the event log, and the application advice, are my own, built on what I read on the page and in the comments.

Discuss on Twitter • View on GitHub