DeepSeek Harness Says Everything Is a Plugin. Cordis Explains How That Can Work

DeepSeek has open-sourced DeepSeek Harness, an agent harness where almost every product part is a plugin.

That includes parts many systems would call the core:

• Model adapters translate one common Harness request into the format expected by DeepSeek, OpenAI, or another model API.
• The tool registry holds the tools the model may call and the code that runs them.
• The session log records user messages, model output, tool calls, and tool results in order.
• The system prompt builder combines instructions contributed by several plugins into the prompt sent to the model.
• The agent loop repeatedly asks the model what to do, runs requested tools, and sends their results back.
• Execution plugins provide the filesystem, shell, sandbox, and approval checks.
• Product plugins provide the web application and telemetry.

You can replace those parts through configuration, and the repository describes an architecture with no privileged core that extensions must patch.

Without lifecycle tracking, replacing one adapter can leave its old route registered or its refresh timer running. New model calls may still reach old code, so a full process restart becomes the only reliable cleanup even though it also discards unrelated process-local state.

Many agents already call tools. What makes this project unusual is the runtime below the agent.

DeepSeek Harness is powered by Cordis, whose paper A Programming Paradigm for Spatiotemporal Composability explains the model behind this component runtime.

What does an agent harness do?

The LLM reasons. The harness is the software that lets it act.

Say you ask an agent to find why a test is failing. The harness does the following work around the model:

1. It loads your message and the earlier session history.
2. It builds a system prompt and a list of available tools.
3. It sends that request to a model through a model adapter.
4. The model asks to read a file or run the test.
5. The harness checks policy, runs the tool, and records the result.
6. It sends the result back to the model for the next decision.

The model chooses the next action, while the harness supplies the tools and state needed to carry it out through its execution rules and repeat loop.

Harness calls the complete response to one user request a turn. A turn contains several steps, each starting with one model call and possibly producing tool results for the next step.

The four layers have different jobs:

LLM provider
    returns text or requests a tool call

DeepSeek Harness
    runs the agent loop, tools, sessions, and execution

Cordis
    loads, connects, and removes Harness plugins

Cordis paper
    explains the rules behind that plugin lifecycle

While the test is running, an operator might reload the DeepSeek integration. The old integration's route and requests need cleanup, but the running test and session history must remain. Replacing the entire model service is different because the agent loop depends on it.

A plugin is loaded code, not a call

The paper calls each removable piece of software a component. DeepSeek Harness implements these components as Cordis plugins. The two words refer to the same runtime idea here.

Plugins outlive calls.

A plugin is a TypeScript module loaded inside the Harness Node.js process. It is not a separate process. It stays loaded across many user requests and installs a capability that those requests can use.

A basic plugin looks like this:

import type { Context } from "@deepseek-ai/cordis"

export const inject = ["tools"]

export function apply(ctx: Context) {
  // Plugin setup runs here after ctx.tools becomes available.
}

inject lists the services the plugin needs. Cordis runs apply(ctx) when it loads the plugin. Inside that function, a real plugin might register a tool, adapter, listener, or service.

The plugin may also own configuration, timers, listeners, or open requests related to its capability. This ownership lets Cordis replace one capability and clean up its resources without restarting the rest of Harness.

Cleanup belongs to the plugin.

A tool plugin, for example, can register run_tests once, and each request to execute it is a separate tool call. The plugin outlives those calls.

One model request through ctx.llm

The agent loop reaches model adapters through a service named ctx.llm.

Each plugin mount gets its own context. Cordis calls it ctx. It lists the available capabilities and records which plugin owns each registration and cleanup function.

Services hide implementations. A service is a capability published under a stable context key, which a plugin requests instead of importing a specific implementation. This lets the implementation change without changing the plugin that uses it.

Common services include:

ctx.llm       model access
ctx.tools     tool lookup and execution
ctx.sessions  conversation history
ctx.fs        filesystem access

ctx.llm is the property named llm on the context object, not “the DeepSeek model.” Its value is the Harness model service.

Inside that service are:

• A registry that maps provider routes such as deepseek or openai to adapter instances
• Functions for preparing and streaming a model call
• Provider and model information reported by the registered adapters
• Registration handles that let a plugin replace or remove only the routes it owns

It does not contain the conversation history, tool results, or one permanent provider connection. The session system stores the history. An adapter opens the provider request for a particular model call.

Cordis ctx is not the model's conversation context. They hold different information and never travel together.

The model service gives every caller one common request format, while its adapters handle the protocol required by each provider.

Routes direct calls. A route is the provider name used to find an adapter. The route deepseek, for example, sends a model call to the adapter currently registered for DeepSeek.

What does an adapter plugin do?

Adapters translate requests. Harness has one common model-request format, but DeepSeek and OpenAI use different URLs, request fields, authentication, stream formats, and errors.

The adapter performs four translations:

• It converts the common Harness request into the provider's HTTP request.
• It adds the configured credentials and model name.
• It reads the provider's streamed response.
• It converts provider-specific chunks into the common Harness stream format.

The agent loop sends the same Harness request shape through ctx.llm without learning the details of the selected provider.

Connections are request-driven. The adapter makes a network request when the agent calls the model and doesn't necessarily keep one permanent connection open between requests. Routing also happens separately for each model call.

Long-lived resources may include an adapter registration, event listener, or credential timer, and shutdown may also need to cancel a model stream still receiving chunks.

An adapter plugin installs that translator. When Cordis loads the plugin, it creates the adapter and registers it with ctx.llm under a route such as deepseek. Model calls use the registered adapter. When Cordis unloads the plugin, its registration and other owned resources are removed.

The DeepSeek adapter plugin follows this lifecycle:

Harness starts
    Cordis loads the DeepSeek adapter plugin once
        plugin registers the route named deepseek

User sends a message
    one model call uses the deepseek route
        adapter translates the request and calls the DeepSeek API
    model call ends
        plugin stays loaded for the next model call

Operator removes or updates the adapter
    Cordis unloads the plugin
        deepseek route is removed and adapter-owned work is cleaned up

DeepSeek remains available across model calls without setting up the adapter each time, and Cordis has one owner to clean up when the integration is removed.

The model system has two long-lived layers:

The service plugin finds the selected route and hands the request to its adapter. The adapter then makes the provider-specific request.

A model call is one short-lived request through these two layers. A tool call is one short-lived request to the tool system. Neither call is a plugin.

The two plugin layers have different lifecycles. Removing one adapter isn't the same as removing the shared model service.

The word “provider” has two meanings here. A model provider is an external API or local model backend, while a service provider plugin places a service such as llm or sessions on the Cordis context.

What happens if the model changes during a turn?

A developer types, “Run the failing test and explain the bug,” then presses Send.

Before Send, those words are only UI state. Pressing Send lets the session plugin record them and begin the agent turn.

One turn can repeat this sequence several times:

Model call 1
    asks to run tests
        |
        v
Test tool
    returns two failures
        |
        v
Model call 2
    asks to edit a file
        |
        v
Edit tool, then test tool
    returns a new error
        |
        v
Model call 3
    decides the next fix or gives the answer

The sequence is one turn with three model steps whose messages and responses, including tool calls and results, are stored in the session log. The loop uses those results in the next model request.

Ownership decides cleanup. During the turn, the state belongs to these components:

But “change the model” can mean three different things:

The first two operations affect the next model call without stopping the test, while the third can deactivate the loop by replacing the service itself.

A model change behaves differently depending on when it happens.

The request does not carry an old Cordis ctx. Selection happens once. Harness creates a prepared call before it contacts the provider. That prepared call captures the adapter registration selected from ctx.llm at that moment.

Assume the deepseek route first points to adapter A:

ctx.llm registry: deepseek -> adapter A

Call 1 is prepared
    captures adapter A

Plugin reload changes the registry
    deepseek -> adapter B

Call 1
    remains attached to adapter A
    may finish or be aborted by adapter A's unload policy

Call 2 is prepared later
    looks up deepseek again
    captures adapter B

The old call never moves to adapter B halfway through its stream. Capturing adapter A does not guarantee that the call finishes, because unloading adapter A may abort it.

The next model call gets a newly assembled model request, not a new Cordis ctx. Its saved conversation and completed tool results let the newly selected model continue from the recorded history.

During the switch:

• An in-flight call never moves from one adapter to another.
• The session log keeps the user message, saved tool results, and completed model chunks.

Cleaning up the old component and stopping the components that depend on it are separate jobs.

Where is this coordination tracked?

There isn't a database row saying, “change the model after the test finishes.” Harness doesn't delay the change. The running test and the next model call are separate pieces of work owned by different components.

The sequence comes from three places:

1. The agent loop waits in memory. A normal tool batch must settle before the loop creates the next model request.
2. The session log records durable facts. The tool call and result are appended so the next step can rebuild model history. Harness can persist this log through a JSONL or SQLite backend.
3. ctx.llm keeps the live adapter registry in memory. Each model call captures one registration during request preparation. This boundary prevents a later registry change from replacing the adapter inside that prepared call.

The test above is a normal foreground tool call. If a tool starts a background job and returns immediately, the loop is no longer waiting for that process. The tool plugin must then define who tracks, cancels, and later reports that job.

After the tool result is recorded, the next step prepares a new call and looks at the current selection and registry. If the requested route has a registered adapter, that adapter receives the call. If no adapter owns the route, the call fails instead of silently choosing another model.

The tool-batch wait and model-call preparation are Harness behavior. Cordis handles the plugin lifecycle around them. For each component, it keeps lifecycle state, the current transition, and cleanup functions in memory rather than in the session database.

Temporal composability: finish cleanup before removal completes

An operator disables the DeepSeek adapter plugin. The service stays. Only its deepseek route is removed.

When the adapter loaded, it may have:

• Registered the name deepseek with ctx.llm
• Added a settings listener
• Started a credential refresh timer
• Created controllers for active HTTP requests

These changes are the adapter's effects.

Cordis keeps each effect close to its cleanup. Harness ties registerAdapter() to the current plugin mount, so the route is removed automatically when the plugin unloads.

Cancellation needs a separate mechanism. The real LlmAdapter contract requires stream(options) to honor options.signal. An adapter that also wants unloading to cancel its active streams can combine that request signal with a plugin-lifetime signal:

import type { Context } from "@deepseek-ai/cordis"
import {
  LlmAdapter,
  type GenerateOptions,
  type StreamChunk,
} from "@deepseek-ai/dsh-llm"

declare function streamFromDeepSeek(
  options: GenerateOptions,
): AsyncIterable<StreamChunk>

export const inject = ["llm"]

export function apply(ctx: Context) {
  const lifetime = new AbortController()

  class DeepSeekAdapter extends LlmAdapter {
    async *stream(options: GenerateOptions) {
      const signal = options.signal
        ? AbortSignal.any([options.signal, lifetime.signal])
        : lifetime.signal

      yield* streamFromDeepSeek({ ...options, signal })
    }
  }

  const adapter = new DeepSeekAdapter()
  ctx.llm.registerAdapter(["deepseek"], adapter)
  ctx.effect(() => () => lifetime.abort())
}

streamFromDeepSeek() stands for the provider-specific HTTP implementation. Either controller can abort. The combined signal carries that cancellation into the provider request.

Cordis records each returned cleanup function, called a disposer, against the plugin and runs the plugin's disposers in reverse order when unloading begins. This disposer aborts active streams, while Harness withdraws the registered route.

Cancellation is one policy, not the definition of temporal composability. Abort is only a signal. The code above asks active streams to stop, but it does not wait for every stream to finish settling.

If removal must wait until no adapter-owned request remains open, the plugin must track its active streams and return an asynchronous disposer that waits for them. A draining policy rejects new requests, lets current streams finish, and resolves the disposer only when none remain.

Cordis awaits a disposer when it returns a promise. It marks the component inactive after the registered cleanup finishes.

After cleanup, the deepseek route, listener, timer, and provider metadata are gone. With the stricter asynchronous policy, every adapter-owned request has also settled before removal completes.

The paper calls this temporal composability. The runtime removes the component's changes while leaving state owned by other components in place.

Cleanup has limits.

It does not mean:

• Erasing the message the user already sent
• Removing model chunks already displayed or saved
• Pulling back bytes already sent to the DeepSeek API
• Reversing a file change made by an earlier tool call
• Restoring the entire process bit for bit

The saved session belongs to the session plugin, so adapter cleanup leaves it alone, while a file edit belongs to the tool system and needs its own recovery rule.

An API request is different because its bytes have already left the process, an event the paper calls an emission. The remote side is outside Cordis. The adapter can close the stream but cannot unsend those bytes.

Cordis can only track work performed through its context or paired with a correct disposer. If plugin code starts a raw timer and never returns a way to stop it, the runtime cannot discover that inverse later.

Framework helpers reduce this risk:

• Adding a listener returns a way to remove it.
• Registering a tool returns a way to unregister it.
• Mounting a child plugin returns a way to dispose it.
• Providing a service returns a way to withdraw it.

Plugin authors still have to write correct cleanup code because Cordis cannot prove that every custom disposer truly reverses its setup.

Spatial composability: react when a required service leaves

An operator may instead replace the plugin that provides the entire ctx.llm service.

The agent loop requires model access, tools, and sessions. Its dependency declaration is:

agentLoop.inject = ["llm", "tools", "sessions"]

Cordis calls this dependency injection. The plugin lists the services it needs instead of building them itself, and the loop starts only when those services are available. That makes it a consumer of the plugins that provide them.

If the llm provider starts leaving during the user's turn, Cordis does not delete ctx.llm immediately. It coordinates the dependency order:

LLM service announces that it is leaving
        |
        v
Agent loop no longer satisfies its llm requirement
        |
        v
Agent loop begins teardown and runs its cleanup
        |
        v
Old LLM service withdraws ctx.llm
        |
        v
Replacement provides ctx.llm
        |
        v
Agent loop can activate again

Consumers stop first. Cordis then withdraws the provider. The old service remains readable during consumer teardown, so the agent loop can cancel or release its work before the service disappears. That order prevents stale access.

The paper calls this spatial composability. Cordis checks the component's declared place in the dependency graph whenever a provider appears, disappears, or changes.

It does not mean:

• Moving an active DeepSeek stream into a different model
• Promising that the user sees an uninterrupted response
• Preserving half-finished model reasoning across providers
• Treating every internal adapter as a Cordis service dependency

Removing one adapter from the registry does not remove ctx.llm, so the agent loop still has its llm dependency while the service exists. A model request can still fail if no usable route remains.

Cordis reacts only to declared requirements. If route availability must drive activation, the application has to model it as a separate dependency.

Temporal and spatial composability side by side

An effect is what a component changes. A coeffect is what it requires from its environment.

Cordis calls tracked operations with cleanup revertible effects. It calls requirements that are checked again when the context changes reactive coeffects. Together, they provide spatiotemporal composability.

Both use ctx, which lets Cordis associate changes and requirements with the plugin that received that context. Cordis tracks context operations and cleanup that the plugin registered correctly. It is not a security boundary for untrusted code in the same Node.js process.

A mounted component becomes a fiber

Every plugin mount gets a runtime record. The paper calls that record a fiber, a term unrelated to a JavaScript fiber or an operating-system thread.

The fiber stores what Cordis needs to manage that plugin:

• The services the plugin requires
• The services the plugin provides
• Whether it is inactive, loading, active, unloading, or failed
• The disposers collected while it loaded
• The loading or unloading work currently in progress

A simplified lifecycle is:

The normal path is Inactive to Loading to Active. When a dependency leaves or the plugin is removed, the path continues through Unloading and returns to Inactive after cleanup.

In the failing-test example, the test still runs. Its tool fiber can remain active while the adapter fiber unloads because the tool system owns that process. Replacing the entire llm service is different. The agent-loop fiber loses a requirement and its target becomes inactive until model access returns.

The target is the lifecycle state Cordis wants a fiber to reach, stored along with any transition already running. The paper calls this rule inertia. Cordis finishes the current load or unload before moving toward a new target.

How Harness assembles the component graph

The Harness architecture assigns service keys to its main packages:

Harness assembles these plugins from configuration:

• A profile is a named Harness composition. The project ships web and headless profile templates, which stack bundles for a browser application or a one-shot runner.
• A bundle is a reusable group of plugin configuration rows. The base bundle supplies model access, tools, persistence, sandboxing, and other common parts.
• A patch overrides or inserts a configuration row. It lets a user replace one supplied plugin without editing the bundle that originally added it.

These rows form a plugin tree in which a parent can mount child plugins and unload every child it owns when the parent itself unloads.

When a patch changes the LLM setup, Cordis reconciles the affected part of this plugin tree. Replacing only an adapter can leave ctx.llm and its consumers active, while replacing the service follows the dependency teardown shown earlier. Cordis can limit that restart to affected fibers instead of restarting the entire Harness process.

An adapter switch can be smaller because ctx.llm remains present and acts as a broker, a stable entry point with adapters joining or leaving behind it. Consumers such as the agent loop can remain active without a full restart.

Hot module replacement uses the same lifecycle

Hot module replacement (HMR) applies a code change without restarting the whole process and lets developers update the running application by saving one plugin file.

During the failing-test turn, a developer might save a change to the DeepSeek adapter while the Harness process is still running.

The test keeps running because the tool plugin owns it. HMR replaces the affected adapter fiber and its owned routes or requests.

HMR replaces plugin code. It is different from selecting another model for the next request.

Cordis already knows which fiber belongs to each configured plugin and which source modules that plugin imported.

When one source file changes, the HMR system:

1. Finds the plugin entries that use the changed module. These entries are now stale, meaning their running code is older than the saved source.
2. Removes the affected modules from Node.js's module cache so the next import reads the new files.
3. Disposes the old fibers, which runs their recorded cleanup.
4. Imports the changed code.
5. Mounts fresh fibers with the same plugin configuration.
6. If an import fails, restores the previous cached modules and mounts new fibers from that previous code.

The module cache is Node.js's record of code it has already loaded, and importing the same path without clearing its entry could return the old in-memory module.

Step three applies the same ownership rule because disposing a fiber already withdraws its services and reverses its recorded effects. HMR doesn't need a second cleanup system.

The paper calls the reload transactional because all affected swaps must succeed together. Fibers stay disposed. If one import fails, Cordis restores the previous code and mounts it again in new fibers.

What the paper tested

The paper does not evaluate DeepSeek Harness itself. Its production case study is Koishi, a chatbot framework built on Cordis.

The paper reports more than 4,000 community plugins across messaging adapters, database drivers, consoles, and user features. Koishi can change plugins live. It can disable them and withdraw their context-mediated effects or reload their code while the host keeps its other connections and cache state alive.

The evidence has limits:

• It is one ecosystem in one host language, TypeScript.
• The study is observational, not a controlled comparison.
• It establishes that the model can support a large plugin ecosystem.
• It does not measure runtime overhead or developer productivity against a baseline.
• Koishi currently uses Cordis v3, while the paper presents the refined Cordis v4 model.

This evidence supports the Cordis component model, not separate claims about DeepSeek Harness as a product.

The conclusion names self-evolving agent harnesses as future validation, including an agent that replaces parts of its own harness while it continues serving work.

What Cordis cannot guarantee

Cordis manages component lifecycles. It does not make every plugin correct.

The temporal section showed two limits:

• Cordis cannot reverse output that has left the process.
• Cordis cannot discover cleanup that a plugin author forgot to register.

Three more limits matter.

1. One plugin must not remove another plugin's state

Take a model registry built as a simple array. DeepSeek registers first, a local model registers second, and DeepSeek's disposer removes the last item.

That disposer removes the local model by mistake.

A safe registry returns a handle that removes the exact deepseek entry. Then both operation orders work:

add DeepSeek, add local, remove DeepSeek  -> local remains
add local, add DeepSeek, remove DeepSeek  -> local remains

The paper calls these effects independent. Independence has two conditions:

• Every transformation from one effect must commute with every transformation from the other.
• Neither effect may disturb the inverse produced by the other.

Commutation is one part of independence, not another name for the complete property.

Removing DeepSeek produces the same result regardless of which adapter registered first.

Cordis can run cleanup in the required lifecycle order, but plugin operations still need this independence.

2. The name llm does not prove that two services are compatible

Names aren't contracts. The agent loop calls ctx.llm.stream(messages), but a replacement service named llm might implement only complete(prompt).

Cordis sees that ctx.llm exists and marks the dependency satisfied, but the agent loop still fails when it calls the missing stream method. A matching name is not a contract.

TypeScript types, package-version checks, and runtime validation can catch some mismatches, but Cordis alone cannot prove that two implementations behave the same way.

3. Circular dependencies cannot start

Cycles block startup. The agent-loop plugin waits for ctx.llm, while a badly designed LLM plugin waits for ctx.agentLoop before providing ctx.llm.

Both wait forever.

Cordis can report the cycle, but it cannot safely ignore either requirement. Developers must remove the cycle by letting the LLM service start without the loop or moving the optional connection into a third plugin.

Why agent systems need this

Agent harnesses are becoming long-lived systems. They hold sessions, terminals, model routes, tools, permissions, caches, and active tasks.

Process restarts are blunt. Restarting removes every component and throws away all process-local state, even when only one adapter changed.

Cordis lets the program replace one component instead.

For each component, the runtime wants answers to four questions:

1. What does it require?
2. What does it provide?
3. What did it change?
4. How is each change reversed?

Together, these answers define ownership.

Once those answers are part of the programming model, “everything is a plugin” means the runtime can reason about a component's whole life, not only place code in separate packages.

In DeepSeek Harness, the agent is the application. Cordis provides the rules for changing that application one live component at a time.

Sources

• A Programming Paradigm for Spatiotemporal Composability, Yifan Shi, Wei Zhang, and Tianyi Cui
• DeepSeek Harness repository
• DeepSeek Harness architecture
• DeepSeek Harness core subsystem
• DeepSeek Harness LLM streaming subsystem
• DeepSeek Harness tool execution pipeline
• Cordis primer for Harness plugin authors
• Cordis tutorial: Into the Harness
• DeepSeek Harness session subsystem
• Cordis repository
• Koishi
• Plugin Architecture
• AI Agents