06 · 0 privileged core

Cordis, the microkernel

Everything that makes DeepSeek Harness special comes from a plugin framework called Cordis, which was not born with it.

Cordis predates DeepSeek Harness and has years behind it: a chat bot framework with thousands of community plugins has been running on it for a long time. It lives in its own organisation and DeepSeek Harness pulls it in as a dependency. The academic paper that formalises it is co-written by people from Peking University and DeepSeek.

Cordis, with no core

llm talks to the model tools registers tools permissions decides what is allowed sandbox confines execution session records what happens agent-loop decides the next step Shared context registered services, typed events and the trail to undo each one removing a piece leaves the context as it was before adding it
No piece sits above another. They all register in the same context and any of them can be replaced, including the one that decides the next step.

Its model fits in five ideas.

  • 01 · Plugin An object that contributes a capability Nothing more. There are no plugin categories and no hierarchy between them.
  • 02 · Context A store of capabilities Each capability takes a stable name, and the others look it up by that name instead of depending on a concrete implementation.
  • 03 · Dependencies Declared, not ordered A plugin that states what it needs waits until that exists before starting, so load order is derived rather than written by hand.
  • 04 · Events Typed, with declared dispatch Every event declares how it is distributed among its listeners.
  • 05 · Teardown Every registration knows how to undo itself When a plugin unloads, everything it installed is removed on its own. This is the idea the rest rests on.
Technical detail optional

There are four event dispatch modes, depending on whether the event is observed, wrapped, distributed in parallel or run in order. The mode is part of the public contract of the event, and there is a generated catalog that checks the declaration matches actual use. The practical rule the documentation repeats: every registration must have its teardown function, and if unmount order matters, related work goes in the same block.