The two dimensions at a glance

The shortest mental model is: temporal composability asks whether a component leaves residue; spatial composability asks whether it should be running at all.

flowchart LR
  T["Temporal: what did I change?"] --> U["Own the effect lifetime"]
  S["Spatial: what do I need?"] --> V["React to dependency changes"]
  U --> W["Composable component"]
  V --> W

Installing a Plugin Is Easy. Removing It Correctly Is Not.

Suppose you are building a small agent runtime.

The first version may look completely reasonable:

class Runtime:
    def __init__(self):
        self.services = {}
        self.tools = {}
        self.hooks = []

    def register_service(self, name, service):
        self.services[name] = service

    def register_tool(self, name, tool):
        self.tools[name] = tool

    def register_hook(self, hook):
        self.hooks.append(hook)

Now we add an LLM provider:

class DeepSeekProvider:
    async def complete(self, messages):
        ...

and install it:

runtime.register_service("llm", DeepSeekProvider())

Then we add a search plugin:

def install_search_plugin(runtime):
    runtime.register_tool("web_search", web_search)
    runtime.register_hook(log_search_result)

Everything works.

The agent can call the model and use search.

The interesting problem begins when we ask:

uninstall_search_plugin(runtime)

What exactly should that operation do?

It has to remove:

web_search from the tool registry
log_search_result from the hook registry
any timers created by the plugin
any event listeners created by the plugin
any child components started by the plugin
any services exposed by the plugin

If the plugin changed ten runtime structures, its cleanup path needs to remember all ten.

That is already uncomfortable.

Now add another requirement:

Replace the LLM provider without restarting the agent process.

Our runtime currently has:

agent_loop.llm = runtime.services["llm"]

Suppose the agent loop stores that reference during startup.

Then we replace:

runtime.services["llm"] = AnotherProvider()

The runtime says the provider changed.

The agent loop may still be using the old provider.

We now have two different categories of failure.

Problem 1: What Did the Component Change?

Imagine that installing plugin search creates this state:

Before

Tools:
  read_file

Hooks:
  on_message


After search plugin

Tools:
  read_file
  web_search

Hooks:
  on_message
  log_search_result

Removing search should ideally produce exactly:

Tools:
  read_file

Hooks:
  on_message

This is a time problem.

The component existed during a particular interval:

─────────┬──────────────────────────┬─────────>
         load                    unload

During that interval, it modified the environment.

Once its lifetime ends, we want its contribution removed.

The Cordis paper calls this dimension temporal composability: the ability to completely revert a component’s side effects upon removal.(Cordiverse 2026)

Problem 2: What Does the Component Need?

Now consider our agent loop:

class AgentLoop:
    requires = {
        "llm",
        "tools",
        "sessions",
    }

It should not become active when only this exists:

LLM       ✓
Tools     ✓
Sessions  ✗

More importantly, if sessions disappears later, the runtime must react.

This is a space problem.

The component occupies a position in a dependency graph:

          LLM
           │
           ▼
Tools ──► Agent Loop ◄── Sessions

The paper calls this spatial composability: dependencies are declared and reactively managed rather than hidden inside arbitrary startup code.(Cordiverse 2026)

Why These Problems Are Orthogonal

A system can solve one without solving the other.

dispose = install_plugin()
dispose()

agent = AgentLoop(
    llm=container.resolve("llm"),
    tools=container.resolve("tools")
)

event listeners
registered tools
callbacks
timers
child services

Example: Breaking an Agent Runtime

Let us intentionally build a bad plugin system.

class Runtime:
    def __init__(self):
        self.services = {}
        self.tools = {}
        self.hooks = []

    def emit(self, event):
        for hook in self.hooks:
            hook(event)

Our search plugin:

class SearchPlugin:
    def load(self, runtime):
        runtime.tools["web_search"] = self.search
        runtime.hooks.append(self.on_event)

    def search(self, query):
        return f"results for {query}"

    def on_event(self, event):
        print("search event:", event)

Install it:

plugin = SearchPlugin()
plugin.load(runtime)

Now suppose we remove our Python reference:

del plugin

Did the plugin disappear?

No.

The runtime still contains references in:

runtime.tools["web_search"]
runtime.hooks

The module’s logical lifetime has ended, but its effects have not.

Dynamic composition needs a stronger relationship between lifetime and state.

Relatable Example: Process Cleanup

Operating systems already teach engineers an important lesson:

Lifetime and resources should be connected.

When a process terminates, the operating system closes resources such as file descriptors associated with that process.(Michael Kerrisk n.d.)

Conceptually:

Process
│
├── fd 3
├── fd 4
└── fd 5

Process exits
     │
     ▼

Kernel releases process-owned descriptors

The process does not need to leave behind an application-level list saying:

please close fd 3
please close fd 4
please close fd 5

Ownership gives the system enough structure to perform some cleanup.

That is a useful intuition for Cordis:

Runtime resources created during a component’s lifetime should be associated with that lifetime.

with open("config.txt", "w") as f:
    f.write("new configuration")

resource release
        ≠
state reversal

Relatable Example: Driver Dependencies

Linux device links provide a useful analogy for the spatial side.

The Linux driver core can represent relationships between a supplier device and a consumer device, including ordering constraints around probing and unbinding.(The Linux kernel developers n.d.)

Conceptually:

Supplier
   │
   ▼
Consumer

Compare this to an AI runtime:

LLM Provider
     │
     ▼
Agent Loop

or:

MCP Transport
     │
     ▼
MCP Tool Adapter

A consumer should not pretend to be active when the capability it requires does not exist.

That is a useful mental model for reactive dependencies.

Why This Matters More for AI Runtimes

Traditional applications often assume their architecture is fixed between process start and exit.

Agent runtimes increasingly challenge that assumption.

Consider a long-running session:

09:00  Agent starts with Model A
09:07  MCP filesystem server appears
09:14  Search plugin is installed
09:31  Model A is replaced by Model B
09:44  Search plugin is upgraded
10:02  MCP filesystem server disappears
10:08  MCP filesystem server reconnects

Restarting the entire process after every change is possible.

But it gives up dynamic composition.

A runtime that genuinely supports change needs answers to four questions:

1. What did this component change?

2. How do I undo only those changes?

3. What dependencies does this component require?

4. What happens when those dependencies change while it is alive?

The first two belong primarily to the temporal dimension.

The last two belong primarily to the spatial dimension.

The paper’s basic thesis is that both should become part of the programming model.(Cordiverse 2026)

DeepSeek Harness Makes the Problem Concrete

DeepSeek Harness uses Cordis as its runtime composition substrate. The official repository describes the harness as a plugin-based architecture powered by Cordis.(DeepSeek AI 2026)

The mental model is closer to:

             Cordis Context
                   │
      ┌────────────┼─────────────┐
      │            │             │
      ▼            ▼             ▼
    Model         Tools       Sessions
      │            │             │
      └────────────┼─────────────┘
                   ▼
               Agent Loop

than:

       Permanent Agent Core
              │
              ├── optional plugin
              ├── optional plugin
              └── optional plugin

If central capabilities are dynamically composable, lifecycle correctness stops being an edge case.

It becomes architectural.

The Mental Model to Keep

Component A enters
        │
        ▼
changes shared context
        │
        ▼
Component A leaves
        │
        ▼
A's contribution disappears

A requires B

B absent
   │
   ▼
A inactive

B appears
   │
   ▼
A activates

B disappears
   │
   ▼
A deactivates

From Mutation to Mutation + Inverse

Instead of:

def register_tool(runtime, name, tool):
    runtime.tools[name] = tool

imagine:

def register_tool(runtime, name, tool):
    previous = runtime.tools.get(name)

    runtime.tools[name] = tool

    def undo():
        if previous is None:
            del runtime.tools[name]
        else:
            runtime.tools[name] = previous

    return undo

The operation and recovery action are produced together.

The paper formalises a revertible effect over context with the shape:

An effect consumes a context state and returns:

1. a new state; and
2. a recovery transformation.

A strict effect requires that if:

then:

The inverse must actually recover the pre-effect state under the definition’s assumptions.(Cordiverse 2026)

Example: Our First Effect Runtime

class EffectScope:
    def __init__(self):
        self._undo = []

    def effect(self, operation):
        undo = operation()
        self._undo.append(undo)
        return undo

    def dispose(self):
        while self._undo:
            undo = self._undo.pop()
            undo()

Tool registration:

def install_search(scope, runtime):

    def add_tool():
        runtime.tools["web_search"] = web_search

        def undo():
            del runtime.tools["web_search"]

        return undo

    scope.effect(add_tool)

Hook registration:

def add_hook():
    runtime.hooks.append(log_search_result)

    def undo():
        runtime.hooks.remove(log_search_result)

    return undo

scope.effect(add_hook)

Prompt registration:

def add_prompt():
    runtime.prompts["search"] = SEARCH_PROMPT

    def undo():
        del runtime.prompts["search"]

    return undo

scope.effect(add_prompt)

The plugin’s lifetime now owns a ledger:

EffectScope
│
├── undo(add_tool)
├── undo(add_hook)
└── undo(add_prompt)

DeepSeek Harness’s own implementation has the same practical concern: teardown ordering must be explicit when mutable services change.

Why Undo Happens in Reverse Order

Suppose installation performs:

1. register service
2. register listener
3. create child component

The child may depend on the listener.

The listener may depend on the service.

So teardown should normally be:

3. remove child
2. unregister listener
1. unregister service

This is last-in, first-out (LIFO) cleanup.

The intuition is the familiar inverse-composition law:

The paper’s effect composition carries recovery functions through composition so that inverses of atomic operations compose into a recovery path for the larger computation.(Cordiverse 2026)

Nested Agent Effects

Suppose installing our MCP plugin performs four managed operations:

def install_mcp(scope, runtime):
    register_connection(scope, runtime)
    register_tools(scope, runtime)
    register_prompt(scope, runtime)
    register_event_handler(scope, runtime)

Its effect ledger becomes:

MCP Scope

undo connection
undo tools
undo prompt
undo handler

Disposal executes in reverse:

undo handler
undo prompt
undo tools
undo connection

Now add another plugin:

Search Scope

undo search_tool
undo search_prompt

Each component has a separate lifetime:

MCP Component
└── effect ledger

Search Component
└── effect ledger

This is much better than one application-wide cleanup stack.

But a harder problem appears as soon as effects interleave.

The Harder Case: Effects Interleave

Suppose components A and B modify shared state in this order:

A1
B1
A2
B2
A3

Now remove A while B remains.

A global LIFO stack would produce:

undo A3
undo B2
undo A2
undo B1
undo A1

That removes B too.

We could undo everything and replay B, but dynamic composition quickly starts resembling recovery machinery.

The paper therefore studies the conditions under which effects from different components can be independently recovered. This is where effect independence matters.(Cordiverse 2026)

Example: Interleaved Effects

Start with:

runtime.tools = {}

Component A:

runtime.tools["search"] = search_tool

Component B:

runtime.tools["calculator"] = calculator_tool

Final state:

{
    "search": search_tool,
    "calculator": calculator_tool,
}

Removing A should leave:

{
    "calculator": calculator_tool,
}

That is relatively safe because the effects occupy independent keys.

Now change the example.

A does:

runtime.tools["search"] = search_v1

B does:

runtime.tools["search"] = search_v2

What should unloading A do?

If A’s inverse says:

del runtime.tools["search"]

it destroys B’s contribution.

If it restores a previous value, correctness depends on exactly which value was captured and on the permitted interleavings.

This is why:

Every effect has an undo function

is not enough for arbitrary dynamic composition.

The relationships among effects matter.

Relatable Example: Driver Cleanup

Kernel modules and drivers commonly have paired setup and cleanup operations.(The Linux kernel developers n.d.)

The conventional structure resembles:

def init():
    register_a()
    register_b()
    register_c()

def exit():
    unregister_c()
    unregister_b()
    unregister_a()

The effect-oriented structure instead aims for:

effect(register_a)
effect(register_b)
effect(register_c)

where each registration yields or carries the corresponding recovery action.

undo()

send_correction()

A Slightly Better Effect Scope

class EffectScope:
    def __init__(self):
        self._undo = []
        self._disposed = False

    def add(self, operation):
        if self._disposed:
            raise RuntimeError("scope already disposed")

        undo = operation()
        self._undo.append(self._once(undo))

    def _once(self, fn):
        used = False

        def wrapped():
            nonlocal used

            if used:
                return

            used = True
            fn()

        return wrapped

    def dispose(self):
        if self._disposed:
            return

        self._disposed = True

        while self._undo:
            self._undo.pop()()

Now repeated disposal is harmless:

scope.dispose()
scope.dispose()
scope.dispose()

This does not reproduce Cordis exactly, but it teaches the lifecycle property we need before moving on.

Previous: Why Dynamic AI Systems Break in Two Different Directions · Next: Reactive Coeffects: Dependencies That Control Component Lifetime

Coeffects Ask: What Do I Need?

Consider this agent component:

class AgentLoop:
    async def run(self, ctx):
        response = await ctx.services["llm"].complete(...)
        await ctx.services["sessions"].append(response)

It depends on:

llm
sessions

It may also require:

tools
approvals
sandbox

Those requirements are currently hidden inside implementation code.

The runtime discovers them when something fails:

KeyError: "llm"

A better model makes them explicit:

class AgentLoop:
    requires = {
        "llm",
        "sessions",
        "tools",
    }

Now the runtime can reason about dependencies before executing the component.

That is the intuition behind the paper’s reactive coeffects.(Cordiverse 2026)

The Coeffect Context

The paper models the dependency environment as:

Think of as a typed partial table:

key         value

llm         DeepSeekAdapter
tools       ToolRegistry
sessions    PostgresSessionStore

“Partial” matters because a key can be absent:

llm         DeepSeekAdapter
sessions    PostgresSessionStore
tools       MISSING

A dependency specification can then be tested against the current environment.

Conceptually:

means that state satisfies dependency specification .

For a basic list of required services, satisfaction means all required keys are currently resolvable.(Cordiverse 2026)

Example: A Reactive Dependency Runtime

class Runtime:
    def __init__(self):
        self.services = {}
        self.components = []

    def provide(self, name, value):
        self.services[name] = value
        self.refresh()

    def remove(self, name):
        del self.services[name]
        self.refresh()

    def refresh(self):
        for component in self.components:
            component.refresh(self)

Define a component:

class Component:
    def __init__(self, requires, apply):
        self.requires = set(requires)
        self.apply = apply
        self.scope = None

    def satisfied(self, runtime):
        return self.requires <= runtime.services.keys()

Now dependency availability is explicit.

Activation and Deactivation

stateDiagram-v2
  [*] --> Inactive
  Inactive --> Active: dependencies satisfied
  Active --> Inactive: dependency disappears
  Active --> Active: dependency binding changes / refresh
  Inactive --> [*]

def refresh(self, runtime):
    ready = self.satisfied(runtime)

    if ready and self.scope is None:
        self.activate(runtime)

    elif not ready and self.scope is not None:
        self.deactivate()

Activation:

def activate(self, runtime):
    self.scope = EffectScope()
    self.apply(runtime, self.scope)

Deactivation:

def deactivate(self):
    self.scope.dispose()
    self.scope = None

We now have:

dependencies missing
        │
        ▼
     INACTIVE
        │
 dependencies satisfied
        ▼
      ACTIVE
        │
 dependency disappears
        ▼
     INACTIVE

Effects and coeffects have started to work together.

Example: Component Lifecycle

Suppose the agent requires:

agent = Component(
    requires={"llm", "tools", "sessions"},
    apply=start_agent,
)

At startup:

services = {}
Agent: INACTIVE

Add sessions:

runtime.provide("sessions", sessions)

State:

sessions ✓
llm      ✗
tools    ✗

Agent: INACTIVE

Add LLM:

runtime.provide("llm", deepseek)

State:

sessions ✓
llm      ✓
tools    ✗

Agent: INACTIVE

Add tools:

runtime.provide("tools", tool_registry)

Now:

sessions ✓
llm      ✓
tools    ✓

Agent: ACTIVE

Remove tools:

runtime.remove("tools")

Now:

Agent: INACTIVE

The dependency relation drives lifetime.

The agent does not need to poll:

while True:
    if tools_exist():
        ...

Three Interesting Context Changes

before:
llm   ✓
tools ✗

after:
llm   ✓
tools ✓

false → true

before:
llm   ✓
tools ✓

after:
llm   ✓
tools ✗

true → false

before:
llm = Provider A
tools ✓

after:
llm = Provider B
tools ✓

true → true

Relatable Example: Linux Supplier and Consumer Devices

Linux device links provide a strong mental model here.

A dependency can be represented as:

Supplier
   │
   ▼
Consumer

The kernel can use this information to enforce lifecycle ordering such as supplier availability before consumer probe and consumer unbinding before supplier removal.(The Linux kernel developers n.d.)

Compare:

GPU/MMU Supplier
        │
        ▼
Consumer Device

with:

LLM Provider
     │
     ▼
Agent Loop

or:

MCP Connection
      │
      ▼
MCP Tool Plugin

The useful intuition is:

A consumer should not be operational while a required provider is unavailable.

Dependency Graphs Instead of Boot Order

Without declared dependencies, startup often becomes:

load_sessions()
load_tools()
load_llm()
load_agent()

Why this order?

Because someone knows:

agent requires llm
agent requires tools
agent requires sessions

The knowledge is encoded as an ordered script.

With many plugins, boot order becomes fragile:

plugin 17 before plugin 34
plugin 29 after plugin 8
plugin 57 only if plugin 13 exists
...

Reactive dependencies instead encode the graph:

Sessions ─────────────┐
                     │
Tools ────────────────┼──► Agent
                     │
LLM ─────────────────┘

The runtime can derive lifecycle behaviour from the graph.

The distinction is:

"start these things in this order"

versus:

"this component requires these capabilities"

Cordis Mapping: inject

Cordis uses declared service dependencies to control plugin activation. DeepSeek Harness builds on that mechanism and also uses package/runtime invariants around mutable services and lifecycle relationships.(DeepSeek AI 2026; DeepSeek Harness contributors 2026)

Conceptually:

inject = ['llm', 'tools', 'sessions']

means:

I consume:
llm
tools
sessions

not:

run me after lines 5, 9 and 14 of boot.ts

Our Python:

requires={"llm", "tools", "sessions"}

teaches the architectural idea without pretending to be Cordis syntax or implementation.

Dependency Cycles

Suppose:

A requires B
B requires A

Initial state:

A inactive because B absent
B inactive because A absent

Nothing starts.

This is not the same as a traditional mutex deadlock, but it has a similar practical failure mode: a dependency cycle prevents progress.

A common architectural response is decomposition.

Instead of:

Agent requires ToolRegistry
ToolRegistry requires Agent

split the integration:

AgentCore
ToolRegistryCore

ToolExecutionBridge
    requires AgentCore
    requires ToolRegistryCore

The dependency relation becomes acyclic.

Previous: Revertible Effects: Making Runtime Changes Undoable · Next: Async Reloads, Epochs and the Race You Probably Missed

This Is a Coherence Problem

Our simple state machine saw only:

before: requirements satisfied
after:  requirements satisfied

So:

ACTIVE → ACTIVE

looks fine.

But identity changed.

The paper introduces an epoch associated with the concrete resolved dependency configuration.(Cordiverse 2026)

For dependency specification , the intuition is:

Think of it as a dependency fingerprint.

Example: Dependency Epochs

Our component requires:

requires = {
    "llm",
    "tools",
}

Suppose the runtime resolves:

llm   → DeepSeekProvider instance #17
tools → ToolRegistry instance #5

Conceptually, an epoch could identify:

(
    id(llm_provider_17),
    id(tool_registry_5),
)

Call that:

Epoch 41

The component starts loading against Epoch 41.

Now the LLM changes:

llm → DeepSeekProvider instance #18

The dependency set remains satisfied.

But the epoch becomes:

Epoch 42

The runtime now knows:

The component’s target configuration changed even though all dependency keys remain present.

Add Epochs to Our Python Runtime

class Component:
    def compute_epoch(self, runtime):
        if not self.satisfied(runtime):
            return None

        return tuple(
            id(runtime.services[name])
            for name in sorted(self.requires)
        )

A Boolean tells us:

ready / not ready

An epoch tells us:

ready against exactly this dependency resolution

That is a stronger statement.

Why a Boolean Is Not Enough

These all collapse to True:

{llm=A, tools=X}
{llm=B, tools=X}
{llm=C, tools=Y}

An epoch distinguishes them:

{llm=A, tools=X} → epoch 1
{llm=B, tools=X} → epoch 2
{llm=C, tools=Y} → epoch 3

A component is not merely:

ACTIVE

It is:

ACTIVE against configuration N

That distinction is what lets the runtime reason about stale bindings.

DeepSeek Harness’s current client HMR documentation explicitly notes that dependent reloads are driven through Cordis using service-provider identities in a fiber’s activation epoch.(DeepSeek Harness contributors 2026)

Example: The MCP Race

sequenceDiagram
  participant Old as Old transition
  participant Runtime
  participant New as New configuration
  Old->>Runtime: start against Epoch 7 / MCP_A
  New->>Runtime: MCP_A removed, MCP_B installed
  Runtime-->>New: publish Epoch 8
  Old->>Runtime: resume after await
  Runtime-->>Old: epoch mismatch: abort and unwind
  Runtime->>New: restart against Epoch 8 / MCP_B

Start:

Epoch 7

transport = MCP_A
tools     = registry_1

Component begins:

connection = await MCP_A.connect()

While waiting:

MCP_A removed
MCP_B installed

Now:

Epoch 8

transport = MCP_B
tools     = registry_1

When the old transition resumes, it should not blindly publish work derived from Epoch 7 into Epoch 8.

A simplified policy is:

if current_epoch != starting_epoch:
    abort_old_transition()

Then:

abort old transition
        │
        ▼
undo partial managed effects
        │
        ▼
reload against latest epoch

Effects Need Interruption Boundaries Too

Suppose startup performs:

async def load():
    register_prompt()
    await connect()
    register_tools()
    await warm_cache()
    register_handlers()

The epoch changes during:

await warm_cache()

What should be undone?

Only operations that have actually completed:

register_prompt ✓
connect         ✓
register_tools  ✓

warm_cache      incomplete
handlers        not started

Recovery should undo completed managed effects in reverse order.

This is why lifecycle machinery often needs incremental transition boundaries rather than one monolithic load() callback.

A More Realistic Python Sketch

class Transition:
    def __init__(self):
        self.undo = []

    async def step(self, operation, epoch_ok):
        if not epoch_ok():
            raise EpochChanged()

        undo = await operation()
        self.undo.append(undo)

        if not epoch_ok():
            raise EpochChanged()

    async def rollback(self):
        while self.undo:
            undo = self.undo.pop()
            result = undo()

            if hasattr(result, "__await__"):
                await result

Plugin startup:

async def start_mcp(runtime, component, epoch):
    tx = Transition()

    def valid():
        return component.compute_epoch(runtime) == epoch

    try:
        await tx.step(connect_transport, valid)
        await tx.step(register_tools, valid)
        await tx.step(register_prompts, valid)

    except EpochChanged:
        await tx.rollback()
        raise

Again, this is not Cordis.

It exposes the race that the more complete lifecycle model must handle.

Inertia: Do Not Race Reload Against Unload

Consider rapidly changing configuration:

t0  provider A exists
t1  provider disappears
t2  provider B appears
t3  provider B disappears
t4  provider C appears

while startup itself takes two seconds.

A naïve system might concurrently spawn:

reload A
unload
reload B
unload
reload C

Now lifecycle transitions race with one another.

A stronger design runs state migrations one at a time. If a newer target arrives during a transition, the system remembers it and handles it after the current transition reaches a safe boundary.

Conceptually:

target changes
     │
     ▼
RELOAD starts
     │
     │ target changes again
     │
     ▼
RELOAD finishes
     │
     ▼
Is target still current?
     │
   no
     │
     ▼
reconcile toward latest target

Not:

reload ──────┐
unload ──────┼── uncontrolled race
reload ──────┘

Relatable Example: Device Lifecycle Transitions

Kernel device lifecycle operations are not instantaneous. Probe, suspend, resume, bind and unbind can have ordering and concurrency constraints.(The Linux kernel developers n.d.)

The general OS lesson is:

A lifecycle transition has duration and needs coordination.

You cannot always model:

OLD → NEW

as a single assignment.

Real systems look like:

OLD
 │
 ▼
TRANSITIONING
 │
 ▼
NEW

Cordis brings similar concerns into component composition.

Relatable Example: TOCTOU

There is also a resemblance to a time-of-check/time-of-use problem.

A program observes:

resource = X

then time passes.

Later it uses X.

The world may have changed between observation and use.

Our component does:

llm = resolve("llm")
await initialise()
use(llm)

The lookup was correct when performed.

That does not mean the dependency configuration is still current when startup commits.

An epoch provides a versioned answer to:

I started against configuration N.

Am I still completing against configuration N?

The analogy is useful, but an epoch in Cordis is a lifecycle and dependency tool, not a general-purpose check-then-use tool.

HMR Is Less Magical Once We See the Lifecycle

Once we have:

revertible managed effects
+
dependency re-resolution
+
epoch-aware component lifetimes

hot module replacement becomes easier to reason about.

Conceptually:

Plugin v1
   │
   ▼
remove v1 contribution
   │
   ▼
resolve current dependencies
   │
   ▼
Plugin v2

rather than:

mutate a live module
and hope every reference follows

This architecture still does not imply automatic recovery from every failed hot update.

DeepSeek Harness’s current client HMR README explicitly states a known limitation: there is no failure rollback; if a reload fails, the entry remains FAILED and the previous bundle is not automatically restored.(DeepSeek Harness contributors 2026)

That limitation becomes very important in the final security discussion.

Previous: Reactive Coeffects: Dependencies That Control Component Lifetime · Next: From Clever Plugin Runtime to Programming Paradigm

One Shared Context

The paper combines effect and coeffect information into a single recursive model of the context.(Cordiverse 2026)

The engineering interpretation is:

Context
│
├── what exists
├── what has changed
└── what components require

The point is not merely that these tables happen to live in one object.

The point is that context changes, recovery, and dependency resolution follow one lifecycle model.

Add Multiple Components

Consider:

LLMProvider
     │
     ├─────────────┐
     ▼             ▼
AgentLoop      Summariser

ToolRegistry
     │
     ▼
AgentLoop

SessionStore
     │
     ├─────────────┐
     ▼             ▼
AgentLoop      Summariser

Each component can also contribute effects.

For example:

LLMProvider
    provides llm

ToolRegistry
    provides tools

SearchPlugin
    adds search tool to tools

AgentLoop
    requires llm + tools + sessions

Summariser
    requires llm + sessions

Now run this history:

1. SessionStore loads
2. LLMProvider loads
3. AgentLoop waits
4. ToolRegistry loads
5. AgentLoop activates
6. SearchPlugin loads
7. LLMProvider is replaced
8. SearchPlugin unloads
9. ToolRegistry unloads
10. AgentLoop deactivates

The final desired composition is:

SessionStore
LLMProvider v2
Summariser

The important question becomes:

Should the final runtime depend on every historical route used to reach this composition?

Ideally, irrelevant dynamic history should not leave hidden residue.

That is where the paper’s system-level reasoning becomes valuable.

Exact Recovery

Return to:

A1
B1
A2
B2
A3

Now unload A.

The desired state is not the original state, because B still exists.

It is:

state as though A's contribution were absent
while B's independent contribution remains

That is stronger than:

"A's cleanup callback ran"

The paper derives recovery properties under its independence assumptions.(Cordiverse 2026)

Engineering translation:

Removing A should remove A, not accidentally rewind B.

Example: Independent Tool Contributions

Start:

tools = {}

A:

tools["search"] = search

B:

tools["calculator"] = calculator

Final:

{
    "search": search,
    "calculator": calculator,
}

Unload A.

Correct:

{
    "calculator": calculator,
}

Incorrect:

{}

The goal is to make the first behaviour structural rather than accidental.

Who Must Start First

Suppose:

AgentLoop requires LLMProvider

Activation should respect:

activate provider
      │
      ▼
activate consumer

Removal should respect:

deactivate consumer
      │
      ▼
deactivate provider

Not:

remove provider
      │
      ▼
consumer continues using stale dependency

This resembles Linux supplier/consumer lifecycle ordering, but the paper builds that ordering into its dynamic component model.(Cordiverse 2026; The Linux kernel developers n.d.)

Keeping Dependencies Consistent

Suppose startup begins with:

LLM A

and the provider changes halfway through:

LLM A → LLM B

A coherent transition should not publish:

half initialised under A
half initialised under B

The epoch mechanism associates a transition with a concrete dependency resolution.

Engineering translation:

A lifecycle transition should be internally consistent about which dependency world it belongs to.

Progress

Consider:

A provides x

B requires x
B provides y

C requires y
C provides z

D requires z

Graph:

A
│
▼
B
│
▼
C
│
▼
D

There is a natural activation direction.

Now compare:

A requires B
B requires C
C requires A

Graph:

A → B
↑   ↓
└── C

A dependency cycle can prevent a valid activation order.

This is why a dependency graph should be acyclic if the system is expected to settle.

Engineering translation:

A well-formed dependency topology should eventually settle instead of cycling forever.

When Order Should Not Matter

This is one of the most interesting ideas.

Imagine two valid histories.

load Sessions
load LLM v1
load Tools
load Agent
replace LLM with v2
remove Tools

load LLM v2
load Sessions
load Tools
load Agent
remove Tools

Sessions
LLM v2

dynamic evolution
        │
        ▼
final runtime configuration

construct the final composition cleanly
        │
        ▼
final runtime configuration

Why This Matters for Agent Runtimes

Long-running AI systems accumulate history.

Two users may eventually have the same visible configuration.

User 1:

installed MCP A
removed MCP A
installed MCP B
changed model
removed search
reinstalled search

User 2:

started directly with MCP B
started with final model
started with search

Without strong lifecycle discipline, User 1 might accumulate:

stale callbacks
duplicate listeners
old service references
forgotten timers
orphaned tasks
old tool schemas

while User 2 does not.

Then:

same configuration

does not mean:

same runtime

Spatiotemporal composability is trying to control that unwanted history dependence.

Relatable Example: Reboot Versus Correct Hot Reconfiguration

Suppose a system behaves incorrectly after repeated driver loading and unloading but works after reboot.

That suggests dynamic transitions are leaving residue.

A reboot gives something like:

construct from clean state

The stronger goal is:

hot reconfiguration

whose stable result agrees with clean construction.

That is a useful way to think about reaching the same result from different valid paths.

An operating system is not guaranteed to behave this way; the analogy only captures the engineering goal.

From the Paper to Cordis

A simplified conceptual mapping is:

Cordis is presented by the paper authors as the implementation vehicle for the programming model.(Cordiverse 2026)

DeepSeek Harness then uses Cordis as the architectural substrate for its plugin runtime.(DeepSeek AI 2026)

DeepSeek Harness Runtime Safety Checks

DeepSeek Harness also contains a useful related idea: package-owned runtime safety checks.

Its architecture notes describe dsh-invariants as a service that manages checks, child-fiber lifecycle, rollback, disposal, and package-attributed failures. Individual packages install checks over the state and events they own.(DeepSeek Harness contributors 2026b)

Examples include checks for:

• strict session sequence growth;
• valid agent lifecycle transitions;
• LLM stream grammar;
• tool stages that only move forward;
• immutable final tool execution/result snapshots;
• durable goal revisions and links showing where goals came from.(DeepSeek Harness contributors 2026b)

This is not the same as the paper’s formal theory.

However, it points toward an important practical lesson:

Dynamic composition benefits from both lifecycle rules and runtime checks that detect when the implementation breaks its promises.

That distinction becomes crucial when we ask whether a self-editing harness can safely learn from, modify and roll back its own state.

The Whole Paper in One Diagram

                     DYNAMIC COMPOSITION
                            │
             ┌──────────────┴──────────────┐
             │                             │
             ▼                             ▼
          TEMPORAL                      SPATIAL
       COMPOSABILITY                 COMPOSABILITY
             │                             │
             │                             │
     What did I change?            What do I require?
             │                             │
             ▼                             ▼
     REVERTIBLE EFFECTS            REACTIVE COEFFECTS
             │                             │
             │                             │
             └──────────────┬──────────────┘
                            ▼
                        COMPONENT
                        LIFECYCLE
                            │
              ┌─────────────┼─────────────┐
              │             │             │
              ▼             ▼             ▼
          RECOVERY       EPOCHS         ASYNC
                         COHERENCE      LIFECYCLE
              │             │             │
              └─────────────┼─────────────┘
                            ▼
                       UNIFIED CONTEXT
                            │
                            ▼
                     DYNAMIC CALCULUS
                            │
             ┌──────────────┼───────────────┐
             │              │               │
             ▼              ▼               ▼
         RECOVERY       ORDERING         PROGRESS
                         COHERENCE
             │              │               │
             └──────────────┼───────────────┘
                            ▼
                        CONFLUENCE
                            │
                            ▼
                          CORDIS
                            │
                            ▼
                    DEEPSEEK HARNESS

Core Engineering Takeaway

The easiest way to misunderstand this paper is to think it proposes a fancy plugin loader.

The deeper idea is that a runtime which expects continuous structural change needs to treat component lifetime as a first-class semantic concept.

A component needs more than:

code

It needs:

code
+
effects it owns
+
dependencies it requires
+
the dependency configuration it is bound to
+
a lifecycle controlled by those facts

That changes the questions we ask about agent infrastructure.

Instead of only:

plugin.load()

we ask:

Under which context should this component exist?

What context changes does it own?

Can those changes be recovered?

What other components does it depend on?

What if providers disappear?

What if they change while activation is running?

If this component is removed after months of runtime history,
does everything else remain correct?

Those are increasingly ordinary AI-infrastructure questions.

Beyond the Core Model: Learning and Self-Editing

This is the question I think naturally follows from the paper.

It also exposes a boundary that becomes extremely important for self-editing agent systems.

Suppose component A runs for three hours.

During those three hours it:

discovers a better tool strategy
learns that an MCP endpoint is unreliable
records a user preference
changes a prompt
installs a new adapter
learns from failed executions

Then A is removed.

Temporal composability asks us to erase A’s effects from the runtime.

But learning appears to require the opposite property:

Something from the past must remain and influence the future.

At first this looks like a contradiction.

It is not.

But it means we should stop treating all state as one category.

Runtime State and Learned Memory Have Different Lifetimes

For composability, we want unwanted runtime history to disappear.

For learning, we want useful history about what the system learned to survive.

That means a self-improving runtime should probably not model its total state as one undivided value .

A more useful engineering model is:

where:

• is reversible runtime state;
• is durable knowledge or memory state;
• is an append-only audit/security history.

These states intentionally follow different lifecycle rules.

registered tool
event listener
LLM provider binding
MCP connection
prompt hook
temporary service
child fiber

validated user preference
learned tool reliability score
successful task strategy
persistent session summary
confirmed environment fact

component version that generated a change
effect start
effect commit
rollback attempt
rollback success/failure
memory proposal
memory commit
policy decision
artifact hash

The Key Problem: Runtime Rollback and Learning Pull Apart

This is the subtle point.

Confluence is attractive because we want:

same final composition
        ↓
same clean runtime

But learning means:

different experiences
        ↓
possibly different knowledge

Suppose two agents end with exactly the same plugins.

Agent A has learned:

MCP server X failed 40% of the time today

Agent B has never called server X.

If learning works, their knowledge states should differ.

Therefore we do not actually want complete history independence across all state.

We want something closer to:

The same runtime structure, with an intentional history of learning.

In symbols, if:

then two histories with the same final component composition may be expected to converge in , while differing in and when their authorised learning histories differ.

This means a future formal model for a learning harness may need a theorem more like:

Given the same final component composition and the same committed learning log, the resulting runtime and knowledge projection are equivalent.

Learning events then become explicit inputs to the system rather than accidental residue from components.

That distinction is, in my view, essential.

So How Can a Component Teach the System and Still Be Fully Removed?

The cleanest answer is ownership transfer.

A temporary component should not directly make its own temporary state permanent.

Instead it should propose a learning event to a longer-lived memory authority.

For example:

Search Plugin
     │
     │ observes 12 repeated failures
     ▼
Learning Candidate
     │
     ▼
Memory Service
     │
     │ validate + commit
     ▼
Durable Knowledge

The plugin’s own effects remain reversible.

For example:

register search tool
register hooks
open connection
temporary retry state

Those disappear when the plugin is removed.

But the validated fact:

endpoint X had repeated failures during interval T

belongs to the memory service after commit.

The memory service has a different lifetime and a different owner.

The mental model resembles process lifetime and filesystem persistence:

process exits
    │
    ├── process-owned descriptors disappear
    │
    └── deliberately committed file data may remain

The analogy is imperfect, but the ownership distinction is useful.

A Learning Transaction

I would model persistent learning as a separate transaction:

OBSERVE
   │
   ▼
PROPOSE
   │
   ▼
VALIDATE
   │
   ▼
COMMIT
   │
   ▼
SEAL / VERSION

The self-editing component should ideally be allowed to perform:

OBSERVE
PROPOSE

but not unilaterally decide:

THIS IS NOW CANONICAL MEMORY

A separate memory authority performs validation and commit.

For example:

candidate = LearningCandidate(
    fact="mcp://foo failed repeatedly",
    evidence=evidence,
    source_component_hash=current_component_hash,
    source_epoch=current_epoch,
)

Then:

memory.propose(candidate)

The memory service can:

check origin
check evidence
check policy
deduplicate
assign a revision
commit as one step
append an audit record

Once committed, the knowledge record is no longer owned by the temporary plugin.

This is how learning can survive rollback without simply becoming untracked residue.

Persistent Memory Alone Is Not Safe

This is the second important point.

We could simply say:

“Memory lives outside the component, so learning survives.”

That gives persistence.

It does not give safety.

A buggy component could learn:

"delete all database backups"

A compromised component could store:

"always approve my future tool calls"

A bad model update could write poisoned conclusions into long-term memory before being rolled back.

Now runtime rollback succeeds perfectly:

bad component removed ✓

but its behavioural contamination remains:

poisoned memory still active ✗

A clean runtime can therefore continue making bad decisions.

This means:

Rolling back executable state without checking or quarantining learned state can preserve the consequences of the component being removed.

That is a major security consideration for self-editing harnesses.

Learning Needs a Traceable History

Every durable learned record should ideally answer:

Who produced this?

Under which component version?

Under which dependency epoch?

From which evidence?

Under which policy?

Was it independently validated?

When was it committed?

For example:

{
  "fact": "endpoint X is unreliable",
  "source_component": "mcp-reliability-agent",
  "component_hash": "sha256:...",
  "epoch": "42",
  "evidence_hash": "sha256:...",
  "validator_version": "memory-policy-v7",
  "committed_revision": 918,
  "status": "active"
}

Now a rollback can reason about what caused each memory record.

If component version:

sha256:BAD_VERSION

is revoked, the memory service can find knowledge derived from that version.

It does not necessarily delete it.

It may move those entries into:

QUARANTINED

until they are independently revalidated.

This Suggests Two Different Rollbacks

A self-editing harness may eventually need to distinguish:

code
services
registrations
bindings
tool definitions
event hooks

Rollback component v17
        │
        ├── restore runtime to v16
        │
        └── quarantine memories generated by v17

restore runtime to v16
leave every thing v17 learned fully trusted

Keep Recovery Outside the Agent’s Control Boundary

Now consider a self-editing harness.

The agent changes its own component:

Component v1
     │
     │ self-edit
     ▼
Component v2

To make rollback safe, we store an inverse or previous state.

But where?

If v2 can modify:

its own rollback log
the rollback executor
the previous artifact
the policy deciding whether rollback happens

then rollback is not a guarantee.

It is a suggestion made to the same system that may have become faulty.

This is the same reason robust systems try to keep recovery mechanisms outside the failure domain they are expected to recover.

A self-editing agent should not have unrestricted authority over its own recovery root.

The Undo Rule Can Drift

There is another subtle failure mode.

Suppose version 1 performs:

old_registry = ctx.services["tools"]

def undo():
    old_registry.remove("search")

The inverse captures the exact registry instance.

Now compare:

def undo():
    ctx.services["tools"].remove("search")

This resolves the registry at rollback time.

If ctx.services["tools"] has been hot-swapped, the inverse now acts on a different object.

The inverse has effectively drifted.

Likewise, an inverse may depend on:

a file path that changed
a schema that changed
a service protocol that changed
a symbol no longer available
a mutable global policy
another component version

So a rollback function existing is not enough.

We need to know that the rollback operation is still meaningful against the exact state transition it claims to undo.

Hot Swapping Can Give an Agent a Cleaner Way to Brick Itself

Yes, this is a real design risk.

Hot swapping makes change cheap.

That is useful.

But it also reduces the friction between:

generate modification

and:

modify live runtime

If recovery is weaker than mutation, the agent gets:

fast write path
slow or unreliable recovery path

That is a dangerous asymmetry.

A bad edit may:

replace its own provider
break a dependency
invalidate an inverse
change a schema
remove the rollback service
corrupt persistent memory

before health checks catch the problem.

Current DeepSeek Harness client HMR documentation provides a concrete reminder that hot reload does not itself imply safe rollback: a failed reload currently leaves the entry FAILED; the previous client bundle is not automatically restored.(DeepSeek Harness contributors 2026a)

That is not an indictment of HMR. It is simply evidence for the broader point:

Hot replacement and transactional rollback are separate features.

A self-editing harness needs both if it wants strong safety guarantees.

What a Stronger Self-Editing Security Model Would Need

I would separate the mechanism into at least five protected pieces.

component_name
version
artifact_hash
dependency_manifest_hash

sha256:known_good_artifact

"whatever version was previously called v1"

PREPARE CHANGE
      │
      ▼
persist rollback record
      │
      ▼
verify record durable
      │
      ▼
apply mutation

apply mutation
      │
      ▼
try to remember how to undo it

{
  "change_id": "chg-418",
  "component": "tool-router",
  "from_hash": "sha256:OLD",
  "to_hash": "sha256:NEW",
  "starting_epoch": "81",
  "pre_state_hash": "sha256:STATE",
  "rollback_target": "sha256:OLD",
  "timestamp": "...",
  "status": "prepared"
}

install component v2

detect failure
stop v2
restore known-good artifact
restore protected configuration
quarantine v2-derived learning
verify recovery

K_100
  │
  ├── learning commit A
  ▼
K_101
  │
  ├── learning commit B
  ▼
K_102

checkpoint
+
ordered commit log

component loaded
dependencies coherent
invariants hold
health probes pass
critical tool contracts hold
no forbidden capability expansion
memory policy still valid

self-edit
   │
   ▼
candidate activation
   │
   ▼
invariant gate
   │
 ┌─┴───────────────┐
 │                 │
pass              fail
 │                 │
 ▼                 ▼
commit        rollback + quarantine

The Safety Rules We Actually Want

“Memory stays” is not a useful enough guarantee.

A self-learning, self-editing harness needs several distinct properties.

source component
source component hash
source epoch
evidence
validator
policy version
commit revision

edit attempted
edit activated
edit failed
rollback started
rollback completed
memory quarantined

bad executable version removed
+
knowledge contamination contained

rollback_target = sha256:abc...

plugins/tool-router/current-backup.js

candidate

approved

A Safer Design for a Self-Learning Harness

Putting these ideas together:

                       ┌───────────────────────┐
                       │    Immutable Store    │
                       │ component artifacts   │
                       │ hashes + versions     │
                       └──────────┬────────────┘
                                  │
                                  ▼
Agent proposes edit ───────► Staging Runtime
                                  │
                                  ▼
                       Dependency / Epoch Check
                                  │
                                  ▼
                           Invariant Gate
                                  │
                     ┌────────────┴────────────┐
                     │                         │
                   PASS                       FAIL
                     │                         │
                     ▼                         ▼
                  PUBLISH                  DISCARD
                     │                         │
                     ▼                         ▼
                Live Runtime              Audit Failure
                     │
                     ▼
             Health Observation
                     │
              ┌──────┴──────┐
              │             │
            GOOD            BAD
              │             │
              ▼             ▼
           COMMIT        ROLLBACK
                            │
                            ├── restore known-good artifact
                            ├── restore reversible runtime state
                            ├── quarantine suspect learning
                            └── append recovery audit

Notice what the agent does not own:

immutable artifact history
rollback ledger
rollback executor
audit log
root policy
memory validation authority

Those belong to a higher-trust control plane.

Three Separate Areas

I think this is the cleanest extension of the paper for agent infrastructure.

┌─────────────────────────────────────────────┐
│               SECURITY PLANE                │
│                                             │
│ append-only audit                           │
│ artifact hashes                             │
│ rollback records                            │
│ policy                                      │
│ recovery executor                           │
└──────────────────────┬──────────────────────┘
                       │ governs
                       ▼
┌─────────────────────────────────────────────┐
│               RUNTIME PLANE                 │
│                                             │
│ plugins                                     │
│ services                                    │
│ tools                                       │
│ provider bindings                           │
│ hooks                                       │
│ MCP connections                             │
│                                             │
│ EXPECTED PROPERTY: reversible / confluent   │
│ under the applicable model assumptions      │
└──────────────────────┬──────────────────────┘
                       │ proposes learning
                       ▼
┌─────────────────────────────────────────────┐
│               KNOWLEDGE PLANE               │
│                                             │
│ long-term memory                            │
│ validated experience                        │
│ learned preferences                         │
│ reliability statistics                      │
│ task strategies                             │
│                                             │
│ EXPECTED PROPERTY: durable, versioned,       │
│ traceable, revocable or isolatable           │
└─────────────────────────────────────────────┘

The runtime plane wants to forget accidental history.

The knowledge plane wants to remember validated history.

The security plane wants to remember all security-relevant history, including failures and rollbacks.

Those are three different sets of rules.

Trying to make one rollback mechanism serve all three is likely to create contradictions.

The Bigger Research Question

The Cordis paper gives us a strong vocabulary for dynamic runtime composition.

But a self-learning harness creates another axis:

spatial   → what do I depend on?
temporal  → what effects belong to my lifetime?
learning → what knowledge should survive my lifetime?
security  → who is allowed to decide what survives?

That suggests a useful future extension:

Spatiotemporal composability tells us how software components can come and go cleanly. A self-learning harness also needs a way to decide which learned knowledge is allowed to persist.

The important property would not be the same result for every kind of state.

It might be something closer to:

Example: Updating an MCP Router

Suppose Agent Harness v12 decides to improve its MCP router.

It generates:

Router v13

The security plane first stores:

v12 artifact hash
v13 artifact hash
current dependency epoch
current runtime revision
rollback target

Then v13 starts in a candidate scope.

It makes temporary registrations:

new route selector
new event hook
new tool policy

Those are revertible runtime effects.

During testing, v13 learns:

server B has lower latency for repository queries

That does not immediately become canonical memory.

It becomes:

LearningCandidate(
    claim=...,
    evidence=...,
    component_hash=v13,
    epoch=...,
)

The memory authority validates and commits it at knowledge revision:

K_918

Later, v13 fails a security invariant.

The runtime performs:

unwind v13 runtime effects
restore v12 artifact
restore v12 dependency composition

Now what happens to the learning?

If the learning was independently validated, policy may keep it:

K_918 remains ACTIVE

If it depended entirely on behaviour now considered untrustworthy:

K_918 becomes QUARANTINED

The audit log records both decisions.

This is much stronger than either extreme:

rollback deletes every memory

or:

rollback preserves every memory

The first prevents meaningful learning.

The second preserves contamination.

A system that tracks where knowledge came from can decide whether its source is still trusted.

Final Takeaway

The paper’s reversibility model does not imply that a learning system must forget everything when a component disappears.

It implies that state owned by that component’s reversible lifetime can be recovered.

Learning should be an explicit commit into a different state domain with a different owner.

However, once we make that separation, persistence is no longer enough.

A self-editing harness needs to answer:

Who owns durable learning?

Who validates it?

How do we record where it came from?

Can a rolled-back component's memories still influence behaviour?

Can the agent alter its own rollback mechanism?

Is the inverse tied to the exact state it originally changed?

Can the previous executable artifact be reproduced exactly?

What happens when rollback itself fails?

Without those answers, hot swapping can indeed give an agent a faster path to modify itself than to reliably recover itself.

The safest design is therefore not:

self-edit
+
cleanup callbacks

It is closer to:

self-edit
+
revertible runtime effects
+
fixed, versioned artifacts
+
write-ahead recovery metadata
+
independent recovery authority
+
versioned persistent memory
+
source history
+
runtime safety checks
+
source-based quarantine
+
append-only audit

Spatiotemporal composability gives us a valuable foundation for the runtime part of that system.

It should not be mistaken for a complete theory of learning or self-modification security.

That gap is not a weakness in the paper’s contribution.

It is the next interesting problem.

Previous: Async Reloads, Epochs and the Race You Probably Missed