Inside DeepSeek's inspectable agent harness

A harness that shows its work

DeepSeek has put out a developer preview of an agent harness, and it is worth attention less for what it does today than for the two bets it makes. The first: every component is a plugin, including the interface chrome. The second: every run is traceable in full, down to raw tool payloads.

It is a preview, and it behaves like one. Configuration happens in YAML files, some generated output is rough, and plenty of it will change. The architecture is the interesting part.

The trajectory view

Most agent tools show you a chat log and, if you are lucky, a summary of the reasoning. This one exposes the run as a graph you can click through: the system prompt as actually assembled, the user prompt, the context loaded into the window, each assistant message, each reasoning block, each tool call with its exact payload and its exact result, plus timings and turn counts at every step.

The whole session exports as a JSON Lines file. That single detail changes the category of the tool.

A run you can export is a run you can diff, replay, review and regression-test. A run you can only scroll is an anecdote.

Everything is a plugin, including the sidebar

The plugin list is granular past the point most tools stop. Tool capabilities are plugins. The system prompt is a plugin. The UI sidebar is a plugin, and switching it off is a two-line entry in a patch file with a hot reload. Nothing is privileged core, which means nothing is off limits to replacement.

Provider choice follows the same philosophy. The default path uses DeepSeek's own API, but custom endpoints are first class, including a local Ollama server running open-weight models on your own hardware. For work where the code cannot leave the building, that is not a nice-to-have, it is the deciding feature.

Creator mode: prompting features into a running tool

The preview ships several agent presets, one of which exists purely to extend the harness itself. Describe a capability, and it loads a plugin-development skill, writes the plugin, and asks for approval before activating it live in the session. The demos are deliberately trivial (an overlay animation, a small calculator) and the results are visibly unpolished, buttons unlabeled and layout approximate.

Ignore the polish and look at the loop. A running application that writes, loads and unloads its own features on request, behind a confirmation step, is a meaningfully different thing from a chatbot that emits code you then install yourself.

The idea underneath

The plugin layer is built on a framework the project calls Cordis, published with a paper that sets out a formal model. The core claim is that every action has an inverse. From that you get temporal composability, meaning anything added can be cleanly removed without residue, and spatial composability, meaning components declare their dependencies and those are managed reactively.

That is not academic decoration. Hot-swapping live capabilities is only safe if removal genuinely restores the prior state. Undo is the feature that makes everything else in this design tolerable.

How we think about this at Birdhouse

Three things we take from it:

• Traceability is an engineering requirement, not a debugging luxury. When an agent run goes wrong in client work, "it seemed to work before" is not an answer. An exportable, machine-readable trace of prompts, context and tool payloads is what turns an agent run into something you can actually review.

• Runtime self-extension needs a real gate. An agent authoring plugins into its own process is, viewed plainly, an arbitrary code execution path. A confirmation click is the right instinct and the minimum bar. Sandboxed execution, narrow permissions and a readable diff of what is being loaded are what make it safe rather than merely exciting.

• Model portability protects the client, not the vendor. A harness that treats providers as configuration lets sensitive work run against a local model and everything else run against whatever is currently best. Tools that hard-wire one provider make that decision for you.

We would not put a developer preview near production. But the direction is one we would like the rest of the field to copy: expose the whole run, make every part replaceable, and make every change reversible. Those three properties are what separate an agent you can supervise from one you can only hope about.