From Clever Plugin Runtime to Programming Paradigm

Agents
Systems
Distributed Systems
How Cordis combines reversible changes, dependencies, consistency, and safe recovery.
Author

Chirag Sehra

Published

August 17, 2026

Local Tricks Are Not the Interesting Part

At this point it is tempting to summarise the paper as:

cleanup functions
+
dependency injection
+
version identifiers

That misses the central question.

The paper asks:

If many independently developed components perform effects and depend on one another, what can we say about the behaviour of the whole dynamic system?

That moves us from:

one component

to:

many interleaved components

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.

History A

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

History B

load LLM v2
load Sessions
load Tools
load Agent
remove Tools

Suppose both end with:

Sessions
LLM v2

The question is:

Do both valid histories converge to an equivalent stable runtime configuration?

That is the idea of reaching the same result even when the steps happen in a different order.

Conceptually:

dynamic evolution
        │
        ▼
final runtime configuration

should agree with:

construct the final composition cleanly
        │
        ▼
final runtime configuration

under the model’s assumptions.(Cordiverse 2026)

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:

Paper concept Cordis / Harness concept
Context ctx
Revertible effect ctx.effect(...) and higher-level tracked registrations
Effect recovery disposer / ordered teardown
Coeffect provider service exposed through context
Dependency specification inject
Component runtime instance fiber
Resolved dependency identity activation epoch
Composition plugin/context mounting
Reconciliation loader lifecycle
Runtime replacement unload + reload / HMR

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 \Gamma.

A more useful engineering model is:

S = (R, K, A)

where:

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

These states intentionally follow different lifecycle rules.

Runtime state R

Examples:

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

These are exactly the kinds of things that should normally disappear when their owning component disappears.

Knowledge state K

Examples:

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

These may need to survive component teardown.

Audit state A

Examples:

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

This history should generally be harder to delete than either runtime or ordinary memory state.

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:

S=(R,K,A)

then two histories with the same final component composition may be expected to converge in R, while differing in K and A 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:

Runtime rollback

Restore:

code
services
registrations
bindings
tool definitions
event hooks

to a known-good version.

Learning rollback or quarantine

Find knowledge linked to the bad version and stop it influencing future behaviour until it is checked again.

Conceptually:

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

That is much safer than:

restore runtime to v16
leave every thing v17 learned fully trusted

The second system can have its runtime restored while remaining compromised.

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.

1. Immutable version identity

Every deployed component should have an immutable content identity:

component_name
version
artifact_hash
dependency_manifest_hash

Rollback should target:

sha256:known_good_artifact

not:

"whatever version was previously called v1"

Names drift.

Hashes do not.

2. Write-ahead rollback records

Before applying a self-edit, record enough information to recover.

Conceptually:

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

Not:

apply mutation
      │
      ▼
try to remember how to undo it

A rollback record might include:

{
  "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"
}

This is conceptually similar to the reason databases use write-ahead or versioned recovery information.

The record must exist before the risky transition is allowed to become official.

3. A recovery executor outside the self-modifiable domain

The agent can propose:

install component v2

but should not control the minimal mechanism responsible for:

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

That recovery executor is part of the trusted computing base.

If the self-editing model can rewrite it, the model can remove the guarantee.

4. Versioned persistent state

Durable memory should have explicit revisions.

DeepSeek Harness’s session-persistence design uses revision identities when preparing and reusing persisted sessions, and rejects stale prepared state when the durable revision has changed.

That is a useful pattern.

For learning state, we would want something like:

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

A committed learning state should be reconstructable from:

checkpoint
+
ordered commit log

This gives recovery and source tracking.

It still does not tell us whether the learned fact is true.

That requires validation policy.

5. Runtime safety checks and post-deploy health checks

After a self-edit, do not immediately declare success.

Require:

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

DeepSeek Harness already has an architecture for package-owned runtime safety checks over mutable state and event protocols.(DeepSeek Harness contributors 2026b)

A self-edit security layer could extend this idea:

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.

Safety rule 1: Runtime recovery

For a managed reversible effect:

rollback_R(e(R)) = R

under the effect model’s conditions.

This is the kind of property temporal composability is concerned with.

Safety rule 2: Keep approved learning

Once an authorised learning transaction is committed:

commit(K_t, l)=K_{t+1}

then rolling back unrelated runtime state should not silently erase K_{t+1}.

Conceptually:

rollback_R(R',K_{t+1})=(R,K_{t+1})

The learning survived because it has a different owner and lifecycle.

Safety rule 3: Know where learning came from

Every committed knowledge item must be traceable to:

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

If the source cannot be checked, the memory should not be treated as fully trusted.

Safety rule 4: Audit history only grows

The security log should be append-only.

If:

A_t

is the audit history at time t, then later history should extend it:

A_t \preceq A_{t+1}

A self-edit can add:

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

but should not be able to erase the fact that those events occurred.

Safety rule 5: Isolate learning from revoked versions

If version v is revoked, knowledge derived exclusively from v should no longer influence future action unless independently revalidated.

That is stronger than persistence.

It gives us:

bad executable version removed
+
knowledge contamination contained

rather than only the first half.

Safety rule 6: Rollback targets cannot change

A rollback should restore a fixed, known-good artifact.

rollback_target = sha256:abc...

not a mutable path such as:

plugins/tool-router/current-backup.js

that the self-editing system can overwrite.

Safety rule 7: Publish changes as one step

A new component version should move from:

candidate

to:

approved

only after its required checks pass.

This resembles a publication boundary in session preparation: a prepared session is kept private until it is successfully published or rolled back, with revision checks preventing stale state from being attached to a newer durable revision.

The same style of thinking can be applied to self-edits.

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:

Same structure, same result

The runtime converges according to the final component composition.

Learned memory continues

Authorised committed learning survives runtime replacement.

Know where memory came from

Every learned state transition can be linked to an unchanging source and evidence trail.

Revoke knowledge by cause

Knowledge derived from a revoked component can be quarantined or revalidated.

Recovery still works

The mechanism that restores a previous version cannot itself be rewritten by the version being evaluated.

Together, those properties begin to address the problem that simple persistent memory cannot solve.

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

References

Cordiverse. 2026. A Programming Paradigm for Spatiotemporal Composability. https://github.com/cordiverse/paper.
DeepSeek AI. 2026. DeepSeek Harness. https://github.com/deepseek-ai/deepseek-harness.
DeepSeek Harness contributors. 2026a. @Deepseek-Ai/Dsh-Client-Hmr. https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/client/hmr/README.md.
DeepSeek Harness contributors. 2026b. Meaningful Package Invariant Contracts. https://github.com/deepseek-ai/deepseek-harness/blob/master/.agents/notes/implemented/architecture/2026-07-19-package-invariant-runtime-contracts.md.
The Linux kernel developers. n.d. Device Links. https://docs.kernel.org/driver-api/device_link.html.