Self-Modifying Agents Are Real: DeepSeek Harness's cordis_define

---

Imagine your agent hits a task it doesn't have a tool for, writes a new tool on the spot, registers it into its own runtime, and uses it in the next step — without a developer touching the code. That's not a research demo. It's a shipped feature in DeepSeek Harness, exposed to the model as four ordinary tools: cordis_define, cordis_run, cordis_stop, cordis_undefine.

The context: a harness with no privileged kernel

To understand why this is even possible, you need DeepSeek Harness's core bet. dsh is an open-source agent harness that takes "everything is a plugin" literally: the filesystem, shell, model adapter, tool registry, session log, and even the agent loop itself are all plugins. There is no privileged kernel that needs patching — every part can be swapped from configuration, and unloading a plugin reverses its side effects.

That design is what makes self-modification architecturally unremarkable in dsh. A tool that defines a new plugin is just one more plugin. The framework doesn't have to make a special carve-out for the model to change its own runtime, because the runtime was never sacred.

The four self-referential tools

dsh exposes a set of self-referential tools to the model:

• cordis_define
• cordis_run
• cordis_stop
• cordis_undefine

(A related cordis_inspect_* family is also referenced in the technical-explainer source.) The semantics, as the sources state them, are direct: a running agent can define a new Cordis plugin on the spot, inject it into the real runtime, and the newly registered tools immediately become visible to the model.

The lifecycle reads like a plugin manager: define a plugin, run it, stop it, undefine it. Because dsh is built on Cordis — a vendored plugin framework whose design draws on a paper about composability — plugins are first-class citizens. Registering anything (a prompt fragment, a tool schema, an adapter, an event listener) is a side effect that unload cleanly reverses, and plugins declare their dependencies via inject instead of hand-orchestrating load order.

What actually happens when an agent modifies itself

The sources don't show an exact API signature for a cordis_define call, so rather than invent one, here's the mechanism as described:

1. The model calls cordis_define with a plugin definition — the package's code.
2. That code executes inside a vm sandbox, with a definition registry holding its state. (The specific component named in the sources is dsh-cordis-host-runner's vm sandbox.)
3. Once the plugin is run, its registered tools are injected into the runtime's tool registry.
4. Because the model's view of available tools is projected from that registry, the new tools show up in the model's next step. No restart. No developer.
5. The plugin's tools stay available until they're stopped (cordis_stop) or undefined (cordis_undefine) — or the process restarts.

The source material frames this as a closed loop:

use the framework
-> define the framework inside the framework
-> change your own toolset
-> keep using

In plain terms: the agent notices it lacks a capability, writes the plugin itself, registers it, and immediately uses it — instead of stopping to wait for a developer to change code. One source states it as directly as possible: an agent doesn't just use tools, it can create tools.

Why it's opt-in

This is not a feature that's on by default. The self-referential toolset is deliberately excluded from every distribution tree, because the team is explicit about what it means: dynamic package code reaches the real runtime. Code written by the model (or from any untrusted source) executes inside the vm sandbox, but it still gets injected into the live agent process. That's precisely why the sources say it's an intentional opt-in — you have to explicitly enable something whose whole point is letting a runtime-internal package run in your process.

What this means for builders

For people building agent platforms, the interesting part is that this slots into the same abstraction dsh uses everywhere else. The framework's replaceability is built on a Service Definition / Provider / Consumer trio: you define a capability interface, provide an implementation, and consumers depend only on the interface. A plugin the model defines on the fly registers through the same seam model as a plugin a developer ships in config — there's no separate "model-injected" pathway with looser rules. The consequence, as one source frames it, is a shift in how you think about capability planning: instead of "what tools do we pre-author for the agent," the question becomes "what interfaces should the agent be allowed to extend." For now that's a tooling mindset more than a proven pattern, but it's the direction the framework is betting on.

Why this is a big deal

The sources make a strong, specific claim: essentially no other framework exposes full meta-programming to the model as a toolset. You can find frameworks that let developers hot-reload plugins or register tools from config; you almost never find a framework that hands the model itself the ability to define, inject, and tear down new tools at runtime. That turns the agent from a consumer of a fixed tool catalog into something that grows its own capability surface mid-task.

Combined with dsh's other design decisions, it gets more interesting. Because the session log is the single source of truth — everything the model sees is reconstructed from a replayable log — a self-modified session is still forkable, resumable, and auditable. And because there's no privileged kernel, the agent's own modifications are just more reversible plugins, not patches to a sacred core.

The honest framing from the sources: how far agents will actually push this in real workloads is something the community has to validate. But the direction is real — this is the difference between an agent that uses tools and an agent that can build them.

The honest caveats

Before you get excited, the boundaries, straight from the sources:

• It runs in a vm sandbox, but it still reaches your real runtime. The vm sandbox (dsh-cordis-host-runner) contains execution, but the definition registry injects the plugin into the live runtime. That is exactly why it's opt-in and off by default. It's also worth placing in context: the project's broader sandbox posture is a platform matrix — bwrap/Landlock on Linux, Seatbelt on macOS, ACL restricted tokens on Windows, E2B remote sandboxes in the cloud — with enforcement levels honestly reported as full or partial, so production users still have to confirm the strength of their own platform.
• It persists until stopped or restarted. A running plugin's tools stay registered until cordis_stop / cordis_undefine or a process restart. Leave it running, and it stays.
• The whole project is a developer preview. Version 0.1.0-rc.5, with breaking changes explicitly promised. Don't build production dependencies on specific API details.
• The plugin core is vendored, not self-developed. dsh's plugin foundation is Cordis, brought in from upstream. Your trust model has to include Cordis, not just DeepSeek.
• "Replaces Claude Code" is media narrative. A preview-grade framework talking about replacing the mature benchmark is premature. What's real is the architecture direction, not the crown.

Conclusion

Self-modifying agents are no longer hypothetical. DeepSeek Harness ships the capability as four ordinary tools — cordis_define, cordis_run, cordis_stop, cordis_undefine — and the mechanism is coherent with the rest of its design: no privileged kernel, plugins as reversible side effects, and a session log that makes even self-modification replayable. It's sandboxed but not harmless, opt-in because dynamic code reaches the live runtime, and preview-grade rather than production-stable. Whether real workloads will exploit the loop — define a framework inside the framework, change your own toolset, keep going — is still to be proven. But the direction is clear: the next generation of agents won't just use tools. They'll write them.