DeepSeek Harness: A Concrete Step Toward Self-Evolving AI Systems

Alongside the release of DeepSeek Harness, a paper co-authored by researchers from DeepSeek-AI and Peking University has started receiving more attention. Titled A Programming Paradigm for Spatiotemporal Composability, it is still a work-in-progress preprint. But read together with the open-source DeepSeek Harness, it offers a useful view into the design philosophy behind the project. DeepSeek Harness is not simply another coding agent. It can edit files, run shell commands, search, use skills, make plans, spawn subagents, and execute workflows. What makes it unusual is that the model, tools, sessions, storage, sandbox, scheduler, UI, and even the agent loop itself are all plugins. The project summarizes this idea as “everything is a plugin.” Why design it this way? I do not think the answer is merely extensibility. DeepSeek appears to be asking a more ambitious question: if an AI system eventually starts changing its tools, memory, and ways of working while it is running, how can the software safely change itself? ## Software is becoming more dynamic, while its architecture remains largely static A model alone is not enough to do real work. It also needs tools, memory, a filesystem, permissions, sessions, and an execution environment. Together, these components form the harness around the model. The model determines what an agent can think about. The harness determines what it can see, what it can do, and how it can continue working over time. In most agent systems today, those capabilities are still relatively fixed. Adding a tool, replacing storage, or modifying the agent loop usually means changing code, rebuilding the application, and restarting it. Even when plugins are supported, they are often attached to a core that is itself difficult to change. DeepSeek Harness reverses that relationship. Instead of placing every capability inside one large, permanent core, the running agent is assembled as a tree of plugins. By changing the configuration, developers can replace model adapters, tools, sandboxes, and storage layers, or compose entirely different kinds of agents. This reflects a broader change in software. Traditionally, development, deployment, and runtime have been treated as three separate stages. In the future, an AI system may identify a missing capability while it is running, create a new component, test a different workflow, and then decide whether to keep or discard the change. Development starts moving into runtime. Software is no longer necessarily a finished artifact that remains mostly fixed after release. But this creates a harder problem. Installing a plugin is easy. Can it be removed cleanly? A tool plugin might register model tools, subscribe to events, start timers, open connections, and create background tasks. Deleting its code does not automatically undo those effects. The old tool may remain in the model context. Event listeners may continue responding. Old connections and new logic may coexist. Eventually, the system becomes a mixture of multiple historical versions. For occasional upgrades, restarting the whole process is often acceptable. But if an agent is expected to adjust its tools, memory, and strategies continuously, restarting after every change means that “self-evolution” is still just an automated version of the traditional release process: the AI changes the code, and the system is redeployed. The deeper change would be allowing a running system to modify one part of itself without damaging everything else that is still working. ## Cordis is designed to let components enter—and leave—cleanly Cordis, the runtime underneath DeepSeek Harness, is designed around this problem. It does not prescribe which models or tools an agent should use. Instead, it manages plugin installation, removal, and dependency relationships. The paper calls this “spatiotemporal composability.” Temporal composability means that when a component leaves the system, the effects it introduced can be reversed. When a component creates a side effect, Cordis records the corresponding inverse operation: registering an event listener also records how to unregister it; opening a connection records how to close it; installing a child component records how to remove it. During disposal, the runtime performs those cleanup operations in reverse order. This changes cleanup from an afterthought—such as a deactivate() function that a plugin author must remember to maintain—into part of every side effect. A component only has a real runtime boundary if it can leave without abandoning historical residue. Spatial composability addresses dependencies. Imagine that a planner depends on a memory service, and the memory service depends on a database. Replacing the memory service is not just a matter of loading a new version. The system must know which components are using the old version and in what order they should stop and resume. Cordis lets components declare what they require and what they provide, and maintains those relationships at runtime. If B depends on A, A starts before B. During removal, B exits first and A is withdrawn only afterward. The consumer can still access its provider while cleaning itself up, rather than becoming trapped in a half-old, half-new state. Temporal composability aims to make removal complete. Spatial composability aims to make removal and recomposition respect dependency order. Together, they pursue a simple but demanding property: the behavior of the current system should be determined by the components installed now, not by every component version that happened to run in the past. ## Self-evolution becomes an engineering problem This is the most interesting part of DeepSeek Harness for me. If an AI can generate a new tool, memory mechanism, or strategy, it has only solved the problem of adding capability. A system can evolve safely only if obsolete capabilities can leave cleanly and failed changes can restore the previous state. If a system can only add components but cannot remove their effects, it is not accumulating intelligence. It is accumulating history that becomes increasingly difficult to understand. Self-evolution therefore requires more than generation. It requires controlled experimentation: propose a change, load it locally, observe the result, keep it if it works, and roll it back if it fails. DeepSeek Harness has not yet delivered a fully autonomous, self-evolving AI. Cordis cannot prove that an AI-generated plugin is semantically correct, nor can it reverse an email that has already been sent or a payment that has already been made. Permission and security boundaries also cannot simply become ordinary plugins that the agent is free to replace. Those problems still require sandboxing, auditing, staged rollout, capability controls, and external governance. Composability is not the same thing as security or isolation. But Harness makes one part of the problem much more concrete. Discussions about self-evolving AI often focus on whether a model can rewrite its own code. DeepSeek Harness asks the next question: once the code has been changed, how does a running system install it, coordinate it with existing components, observe its effects, and withdraw it if it fails? This may point toward a broader shift in software development. Future software may not only be something engineers finish and hand over to machines for execution. It may become a dynamic system that continuously composes, replaces, and retires components. The engineer’s role would then begin to change as well: from specifying all of the software’s behavior to designing the rules by which the software is allowed to change itself. DeepSeek Harness is still a developer preview, and the Cordis paper is still being revised. It is far too early to declare that a new software paradigm has arrived. But it does represent a concrete step toward self-evolving AI—not by merely describing an AI that can change itself, but by beginning to build a…