Cordis and Spatiotemporal Composability, Explained

"A meta-framework of spatiotemporal composability" is not a phrase that immediately explains itself. It sounds closer to something out of a physics paper than a GitHub README for a TypeScript plugin loader. But the phrase is precise, not decorative, and once you unpack the two halves — spatial and temporal — it names a real, specific problem that most plugin and dependency-injection systems quietly get wrong.

Cordis is the meta-framework built around that idea. It's not a household name — it doesn't ship a product of its own — but it sits underneath a four-year-old chatbot framework with over 4,000 community plugins, and as of August 2026, it's also the plugin architecture DeepSeek chose for its own agent harness.

TL;DR

The two halves of "spatiotemporal"

Start with what the word is standing in for, because it's doing real conceptual work rather than sounding impressive.

The temporal half is about time: can you cleanly undo something? Any plugin system eventually needs to remove or replace a component while the rest of the system keeps running — a hot reload, a version upgrade, a feature toggle. The hard part isn't loading a plugin; it's unloading one without leaving behind a stale event listener, an open timer, a half-registered route, or state nothing else knows to clean up. Cordis's answer is what its research paper calls revertible effects: every change a component makes to the shared context carries an inverse the runtime tracks automatically, so removing the component undoes exactly what it did, nothing more and nothing less.

The spatial half is about structure: does the rest of the system react correctly when something changes? Components don't exist in isolation — a feature plugin might depend on a database driver, which might depend on a connection pool. When one of those changes (a driver reconnects, a dependency unloads and reloads), everything that depends on it needs to react correctly, not silently hold a stale reference or crash. Cordis's answer here is reactive coeffects: a component declares exactly what part of the context it needs, and the runtime notifies it specifically when that declared dependency changes — not on every unrelated update, and not never.

The paper's actual contribution, per its own framing, is unifying both into a single context type rather than bolting a reactivity system onto a separate DI system — the claim being that treating "can this be undone" and "does this react correctly" as two faces of the same underlying mechanism is what makes both properties hold together reliably, instead of one breaking the other under real-world hot-swapping.

Why this is a harder problem than it sounds

Most dependency injection frameworks solve half of this. A typical DI container wires up an object graph once at startup — component A gets component B injected because A declared it needs B — and that's the entire job. It's a static, spatial-only solve: correct wiring, assembled once, rarely revisited.

That's fine until you need components to come and go while the system keeps running — which is exactly what a plugin ecosystem is. A chatbot framework where users install and uninstall community plugins on a live bot. An agent harness where a developer wants to swap the model adapter or the sandbox implementation without restarting the whole process. In both cases, "wire it up correctly once" isn't the hard part anymore — cleanly tearing a component back out, without corrupting the state of everything that depended on it, is. Most plugin systems either don't guarantee this at all (memory leaks and zombie listeners are the norm, not the exception, in long-running Node.js plugin hosts) or bolt on ad-hoc cleanup code that every plugin author has to remember to write correctly themselves. Cordis's bet is that clean removal should be a property the framework guarantees structurally, not a discipline every plugin author has to reinvent.

The proof: four years, one chatbot framework, 4,000+ plugins

The paper is recent, but Cordis itself isn't a new idea being tested for the first time. It's been the foundation of Koishi, a cross-platform chatbot framework, for four years — and Koishi's community has built more than 4,000 plugins on top of it: instant-messaging platform adapters, database drivers, admin consoles, and assorted bot features, all composing and decomposing on live, running bots. That's the kind of sustained, community-scale stress test that validates a plugin architecture's cleanup guarantees far more convincingly than a benchmark suite — four years of real plugins being installed, removed, and reinstalled by people who never read the underlying paper, on infrastructure that mostly didn't fall over.

That track record is part of why DeepSeek's decision to build its own agent harness on Cordis, rather than writing a bespoke plugin system, reads as a considered choice rather than a novelty pick. DeepSeek Harness, released in developer preview on August 13, 2026, is built around the claim that "everything is a plugin" — the model adapter, tools, session state, the sandbox, and the agent loop itself all sit behind Cordis-composed services. An agent harness with that design genuinely needs the temporal guarantee Cordis provides: if you can hot-swap the model adapter or the sandbox implementation while a session is running, you need those swaps to clean up completely, or you accumulate exactly the kind of stale listeners and leaked state that make long-running agent processes unreliable over time.

What Cordis actually gives a developer, mechanically

Stepping back from the paper's framing, a Cordis-based system is organized around a few concrete pieces that map directly onto the two halves above. A context is the shared object every component operates against — think of it as the live, current state of the running system. A service is something a component registers into that context — a database connection, a logger, a config object — that other components can then declare as a dependency. When a plugin declares it needs a service via ctx.inject, Cordis's loader resolves that dependency, and if the service isn't available yet, the plugin simply waits rather than crashing — that's the reactive half in practice. When the plugin unloads, Cordis walks back every context mutation it made and every service it registered, using the tracked inverse from the revertible-effects mechanism — that's the temporal half in practice.

The declarative component loader on top of this handles configuration reconciliation: when a plugin's config changes, Cordis can determine whether the change requires a full reload or can be applied in place, and the hot module replacement layer means a developer can edit a plugin's source file and see it take effect on a running system without restarting the whole process and losing every other plugin's state in the process. None of these individual pieces are unheard of — hot reloading and dependency resolution both exist elsewhere — but Cordis's paper argues the pieces only compose reliably because they're built on the same unified context type from the start, rather than layered on top of each other as separate subsystems that each make their own assumptions about lifecycle.

Who should actually care about this

If you're building a chatbot, an agent harness, or any long-running system where plugins or extensions come and go while the process keeps running, Cordis's underlying paradigm is worth understanding even if you don't adopt the framework directly — "does my plugin system guarantee clean removal, or does that rely on every extension author remembering to clean up after themselves" is a question worth asking about whatever you're currently using. If you're just consuming DeepSeek Harness or Koishi as an end user, the practical upshot is simpler: the plugin architecture underneath both has a four-year track record and a formal paper behind its cleanup guarantees, which is a meaningfully different starting point than a fresh plugin system with no such history.

Related on explainx.ai

• DeepSeek Harness v0.1: run the plugin-first agent stack — Cordis in production, powering an entire agent runtime
• What is an agent harness? Complete guide
• Top 10 open- and closed-source agent harnesses
• What are agent skills? Complete guide
• What is MCP? Model Context Protocol guide

Primary sources: cordiverse/cordis on GitHub · cordiverse/paper — "A Programming Paradigm for Spatiotemporal Composability" · koishijs/koishi on GitHub

Repository statistics (stars, forks, dependents) reflect the cordiverse/cordis GitHub page as of this post's publication date and will drift over time — check the repository directly for current numbers. Cordis's own README notes the API is not yet stable and may change without notice.