DeepSeek Harness and Cordis: The Runtime for Self-Modifying AI Agents
DeepSeek Harness is more than another local coding agent.
Following the release of DeepSeek V4 Pro, DeepSeek introduced the DeepSeek Harness developer preview (dsh), an open-source framework for building and operating AI coding agents. While its surface-level capabilities resemble other terminal-based coding assistants, its underlying architecture introduces a significantly more ambitious idea: the agent runtime itself can be dynamically reconfigured while it is running.
The key technology behind that capability is Cordis, a runtime architecture based on dynamically composable plugins, reversible side effects, and reactive dependencies.
DeepSeek and Peking University researchers subsequently published an 80-plus-page programming-language theory paper, A Programming Paradigm for Spatiotemporal Composability, which formalizes the ideas underlying Cordis.
The result is an unusual convergence of programming-language theory and AI-agent infrastructure: instead of treating the runtime as fixed infrastructure surrounding an agent, Cordis makes the runtime itself dynamically programmable.
🧩 DeepSeek Harness Treats Everything as a Plugin #
At the application level, DeepSeek Harness looks familiar.
It can:
- Read and modify files
- Execute shell commands
- Search documentation and the web
- Invoke external tools
- Delegate work to subagents
- Maintain sessions
- Execute multi-step coding workflows
The architectural difference is that these capabilities are not hardwired into one monolithic agent framework.
Everything is a plugin.
Model adapters, tool registries, session logging, safety policies, and even the primary agent loop are represented as dynamically composable components.
The Cordis Runtime Model #
The architecture can be simplified as:
┌─────────────────────────────────────────────┐
│ DeepSeek Harness │
├─────────────────────────────────────────────┤
│ [Model] [Tools] [Logs] [Agent Loop] │
└──────────────────────┬──────────────────────┘
│
┌──────────────────────▼──────────────────────┐
│ Cordis Kernel │
│ │
│ • Dependency Injection (Coeffects) │
│ • Reversible Side Effects (Effects) │
└─────────────────────────────────────────────┘
This separation makes the framework substantially more flexible than a conventional plugin system.
A search provider, for example, can be replaced through configuration rather than requiring modifications to the framework’s core implementation. New capabilities can be introduced through plugins, while removing a plugin can automatically revoke the hooks and side effects that it registered.
The runtime therefore behaves more like a dynamically managed dependency graph than a static application process.
⚙️ Four Runtime Modes Enable Different Agent Behaviors #
DeepSeek Harness exposes four primary runtime modes, each targeting a different operational model.
Standard Mode #
Standard Mode provides the full agent capability set, including:
- Filesystem access
- Bash execution
- Web search
- Subagents
- Planning
- Standard tool integrations
This is the conventional mode for day-to-day agent-assisted development.
Code or PTC Mode #
Code Mode, also referred to as PTC mode, asks the model to generate TypeScript programs that orchestrate multiple tool calls.
Instead of requiring the model to invoke tools individually through repeated interaction turns, the generated program can coordinate multiple operations within a single execution.
This approach can reduce orchestration overhead and make complex multi-step tool workflows more explicit.
Minimal Mode #
Minimal Mode removes most of the framework’s higher-level capabilities and provides a basic shell and text-editing environment.
Its purpose is primarily evaluation and benchmarking, providing a reduced runtime with fewer variables between experiments.
Creator Mode #
Creator Mode is the most unusual configuration.
Powered by dynamic Cordis tooling, the agent can inspect the currently active plugin tree, create temporary plugins in memory, mount them into the running runtime, use them to complete a task, and then unmount them.
Critically, this happens without restarting the host process.
That capability changes the relationship between the agent and its runtime.
Instead of merely selecting from a fixed set of tools, the agent can potentially modify the environment in which its own tools operate.
📚 The Paper Behind Cordis: Spatiotemporal Composability #
The theoretical foundation for Cordis is described in the research paper A Programming Paradigm for Spatiotemporal Composability.
The work was authored by researchers including Yifan Shi from Peking University and DeepSeek, Wei Zhang from Peking University, and Tianyi Cui from DeepSeek.
Rather than presenting Cordis simply as an implementation technique, the paper develops a programming model for dynamically composing software components over both space and time.
The distinction is important.
Traditional software composition generally assumes that modules, functions, and classes are assembled into a relatively stable program structure. Dynamic systems increasingly require components to appear, disappear, or change while the program remains active.
AI agents make that requirement particularly important because the agent may itself generate or modify tools during execution.
🔄 Static Composition Is Not Enough for Self-Modifying Agents #
Traditional software composition is largely static.
Functions, modules, classes, and dependencies are resolved during compilation, initialization, or application startup.
Dynamic systems require something different:
- Components can be loaded at runtime.
- Components can be unloaded without terminating the process.
- Dependencies can appear and disappear.
- Configuration can change while services remain active.
- Resources created by a component must be safely reclaimed.
Existing plugin architectures often solve only part of this problem.
The VS Code Extension Example #
The paper uses the VS Code extension ecosystem to illustrate the difficulty.
Among the top 100 extensions on the VS Code Marketplace, the authors identify 87 that contain executable code.
The challenge is not loading those extensions. Modern plugin systems can generally perform that operation.
The difficult operation is safe unloading.
If the extension host cannot reliably undo all runtime state introduced by an extension, disabling or removing the extension may require restarting the host process.
That approach is acceptable for conventional desktop tooling but becomes problematic for long-running AI agents.
Restarting the host can destroy:
- Active execution state
- Network connections
- Local caches
- Runtime context
- Tool state
- Accumulated task information
For an AI agent that has spent significant time reasoning about a task, losing that state simply because it needs to install or replace a tool is highly undesirable.
🧠 Cordis Reifies Effects and Coeffects at Runtime #
Cordis addresses dynamic composition through two complementary abstractions:
- Effects, representing what a component does to its environment.
- Coeffects, representing what a component requires from its environment.
These concepts have roots in programming-language theory and type systems, but Cordis turns them into explicit runtime mechanisms.
The distinction provides a structured way to reason about both dependency injection and resource cleanup.
🔁 Reversible Effects Enable Automatic Teardown #
An effect describes a modification performed against the runtime environment.
Cordis models an atomic side effect using a function of the form:
$$ \Gamma \rightarrow \Gamma \times (\Gamma \rightarrow \Gamma) $$
Here, $$\Gamma$$ represents the current execution context.
The operation receives a context, produces an updated context, and returns an explicit inverse function capable of restoring the previous state.
That inverse is the critical component.
Cleanup as a First-Class Runtime Operation #
When a plugin performs multiple side effects, Cordis records the corresponding inverse operations in a composite accumulator.
Conceptually:
Mount plugin
│
├── Effect A → inverse A
├── Effect B → inverse B
├── Effect C → inverse C
└── Effect D → inverse D
│
▼
Composite cleanup
│
D⁻¹ → C⁻¹ → B⁻¹ → A⁻¹
When the plugin is unmounted, the inverse operations are executed in LIFO order.
This reverses the state mutations in the opposite order from their construction.
The result is structurally similar to transaction rollback: the system retains enough information about what happened during composition to reverse those changes later.
Why This Differs From Manual Cleanup Hooks #
Conventional plugin systems often require developers to manually implement teardown functions.
A plugin may have an initialization function that registers services, hooks, listeners, and resources, followed by a separate cleanup routine that is responsible for undoing all of them.
That creates a correctness problem.
If the initialization path changes but the cleanup path is not updated accordingly, resources can remain registered after the plugin has been removed.
Cordis instead derives the teardown structure from the composition process itself.
The inverse operations are produced as effects occur, making cleanup part of the runtime’s compositional model rather than an independent convention.
🧬 Reactive Coeffects Model Runtime Dependencies #
Effects describe what a component does.
Coeffects describe what a component needs.
A component can declare dependency requirements represented by a coeffect $d$. The component remains inactive until the runtime context contains the dependencies necessary to satisfy those requirements.
This produces a reactive dependency system in which the availability of runtime services determines whether components can become active.
Dependency Matching #
Suppose a plugin requires a filesystem service, model provider, and logging interface.
Instead of assuming those services are permanently available, the runtime can evaluate whether the required coeffects exist.
If they do, the component can activate.
If a dependency disappears, the runtime can update the component’s state accordingly.
This makes runtime composition responsive to changes in the dependency graph rather than tied to a one-time initialization sequence.
Coeffect Isolation #
Cordis can also introduce mapping domains between dependency keys and values.
This provides mechanisms useful for:
- Multi-tenancy
- Sandboxing
- Test isolation
- Scoped dependency resolution
Two plugins can therefore receive different implementations or instances of what appears to be the same logical dependency without modifying the underlying provider or consumer code.
Coeffect Interception #
Coeffects can additionally be intercepted to attach cross-cutting metadata.
For example, a filesystem dependency could carry a path whitelist, while a database dependency could be marked read-only.
The important property is that these policies can be applied without rewriting either the service provider or the component consuming it.
That makes the runtime itself a policy-enforcement layer.
⏳ Cordis Introduces an Explicit UNLOADING State #
Dynamic dependency management creates a difficult lifecycle problem.
Consider a provider component with several active consumers.
If the provider is immediately removed, existing consumers may lose access to dependencies they still require during their own cleanup process.
Simply switching a component from ACTIVE to INACTIVE is therefore insufficient.
Cordis introduces an explicit:
UNLOADING
state.
Rule 1: Mark the Component as UNLOADING #
When removal begins, the target component enters the UNLOADING state.
At this point, it stops providing its coeffects to new consumers.
However, its existing dependency relationships remain available for cleanup and lifecycle processing.
This creates a controlled transition rather than an instantaneous disappearance.
Rule 2: Wait for Active References to Clear #
The runtime does not execute the component’s final side-effect cleanup until a guard condition confirms that no remaining active components depend on it.
Only then can the accumulated inverse effects safely be executed.
This prevents the runtime from destroying a provider while another active component still relies on it.
📐 The Confluence Theorem #
The paper’s formal results culminate in a particularly important property: confluence.
The central claim can be summarized as:
$$ \text{ State} \times \text{ Dynamic Mutation} \equiv \text{ State} \times \text{ Static Scratch Build} $$
In practical terms, the theorem establishes that dynamically loading, updating, and unloading components can result in a system state equivalent to assembling the final set of components cleanly from scratch.
This is a powerful guarantee for dynamic software systems.
Without such a property, repeated runtime mutation could gradually accumulate hidden state, leaked resources, stale dependencies, or ordering artifacts.
A dynamically modified system might behave differently from a freshly initialized system even when both contain the same logical components.
Confluence provides a formal basis for avoiding that divergence.
🧪 Why This Matters for Self-Evolving AI Agents #
The significance of Cordis becomes clearer when applied to AI agents.
A conventional coding agent has a relatively fixed runtime:
Agent
├── Model
├── Tools
├── Filesystem
├── Shell
└── Session
A self-modifying agent requires something closer to:
Agent
├── Inspect runtime
├── Create capability
├── Mount capability
├── Execute task
├── Replace capability
└── Unmount capability
The second model requires runtime composition to be safe and reversible.
Without a mechanism such as Cordis, the agent would typically need to:
- Generate a new tool.
- Stop the host process.
- Load the tool.
- Reinitialize dependencies.
- Restore state.
- Resume execution.
That workflow introduces substantial complexity and risks losing accumulated context.
Cordis instead allows the runtime to remain alive while its capabilities change underneath the agent.
🛠️ From Plugin Architecture to Runtime Metaprogramming #
The most important idea behind DeepSeek Harness is therefore not simply that it supports plugins.
Many development frameworks already provide plugin systems.
The more interesting property is that the runtime itself becomes an object the agent can manipulate.
Creator Mode makes this explicit.
An agent can inspect its active plugin tree, dynamically introduce capabilities, use those capabilities to solve a problem, and remove them afterward.
This moves AI-agent architecture toward runtime metaprogramming.
The agent is no longer limited to selecting from a fixed toolbox. It can potentially construct temporary computational environments specialized for individual tasks.
For example, a future agent could theoretically:
Task arrives
│
▼
Inspect current capabilities
│
▼
Identify missing capability
│
▼
Generate temporary plugin
│
▼
Mount plugin into runtime
│
▼
Execute task
│
▼
Verify result
│
▼
Unmount plugin
│
▼
Restore previous runtime state
The key requirement is that every mutation must remain controlled and reversible.
That is precisely the problem Cordis is designed to address.
🌐 DeepSeek Connects Programming-Language Theory With AI Infrastructure #
DeepSeek Harness illustrates a broader trend in AI systems engineering.
As agents become more capable, their limitations increasingly move beyond model intelligence.
The runtime itself becomes part of the problem.
An advanced agent may need to dynamically create tools, modify workflows, switch models, alter dependency graphs, access different data sources, and enforce changing security policies.
Static frameworks are poorly suited to that environment.
Cordis provides a theoretical model in which those changes can be treated as controlled runtime composition rather than ad hoc mutations.
The combination of reversible effects, reactive coeffects, explicit lifecycle management, and confluence gives the runtime stronger guarantees than a conventional collection of plugin hooks.
🚀 Cordis Could Become the More Important Part of DeepSeek Harness #
DeepSeek Harness is immediately useful as an AI coding environment, but its deeper significance lies in the runtime architecture underneath it.
Cordis attempts to solve a fundamental problem for self-modifying software:
How can a running system safely change its own structure without accumulating irreversible state or requiring a full restart?
Its answer combines:
- Dynamically composable plugins
- Reversible side effects
- Reactive dependency management
- Scoped and interceptable coeffects
- Explicit unloading states
- Dependency-aware teardown
- Formal confluence guarantees
For conventional applications, these mechanisms may appear highly theoretical.
For long-running AI agents capable of creating and modifying their own tools, they become directly relevant.
DeepSeek Harness therefore represents an interesting convergence of two traditionally separate domains: programming-language theory and agentic AI infrastructure.
If self-evolving agents become a major software paradigm, the ability to safely modify the runtime without restarting it could prove as important as the model’s ability to write code in the first place.