> When plugin systems, agent frameworks, and hot-reload mechanisms all reinvent the wheel, cordiverse/cordis tries to turn "composability" itself into a programming paradigm.
GitHub: https://github.com/cordiverse/cordis Paper: https://github.com/cordiverse/paper
An Old Problem
Have you ever written a VSCode plugin? An Obsidian plugin, a Chrome extension, an agent tool? If so, you've probably hit these pitfalls:
- Dirty state left behind after uninstall — config files not cleaned, event listeners not detached, global variables still hanging around
- Plugin A depends on plugin B; B upgrades and A breaks
- Hot reload fails because the old instance's side effects can't be rolled back — you have to restart the whole app
- Two plugins modify the same file; ordering is pure luck
- Effects are what a component does to the environment (write files, make requests, mutate global state)
- Coeffects are what a component demands from the environment (a config must exist, a service must be available)
- Agents load new tools at runtime
- Agents compose temporarily to collaborate
- Tool versions upgrade while running
- Agents need rollback to prior states after failure
- Core library: effect tracking + coeffect resolution
- Declarative component loader: config reconciliation + hot module replacement
- Declare its effects and coeffects on load
- Automatically execute all inverse operations on unload
- Be automatically notified when dependencies change
- GitHub: https://github.com/cordiverse/cordis
- Paper: https://github.com/cordiverse/paper
- Language: TypeScript
- Status: preprint stage, unstable API
- 616 stars (listed 2026-08-15)
These look like engineering problems, but the cordiverse team argues they are actually theoretical problems — we have never formally defined what "composable" means.
Cordis's paper, *A Programming Paradigm for Spatiotemporal Composability*, was released as a preprint on August 13, 2026. It is not yet another framework but a meta-framework — it defines how frameworks themselves should be composed.
Two Orthogonal Dimensions
Cordis splits composability into two independent dimensions:
Temporal composability: when a component is removed, all side effects it produced can be fully rolled back.
Spatial composability: dependencies between components are declarative, and components are reactively notified when dependencies change.
These seem unrelated, but Cordis's core insight is that both can be solved with the same mathematical toolkit — effects and coeffects.
If those terms are unfamiliar:
These concepts have existed in programming-language theory for decades. But Cordis does something new: it lifts them from compile-time type systems into runtime mechanisms.
Revertible Effects and Reactive Coeffects
Concretely, Cordis formalizes two ideas:
Revertible effects: every context transformation carries an inverse function. The runtime tracks these inverses and executes them in reverse order when a component is removed.
It's like Git revert, but at the type-system level — you don't hand-write undo logic; the type system guarantees every operation has an inverse.
Reactive coeffects: each component declares its coeffect specification and is automatically notified when the context changes.
It's like React's useEffect dependency array, but generalized — not just internal state subscriptions, but cross-component dependency management.
The crucial step: Cordis unifies the effect context and coeffect context into a single context type. This is not mere concatenation but a mathematical unification — a calculus of dynamic composition extending composability from a single component to entire interleaved component systems.
Why This Matters Now
You might say these concepts sound academic. But the agent era makes dynamic composition a hard requirement:
In these scenarios, reversibility and reactive dependencies aren't nice-to-haves — they're prerequisites for not crashing.
The paper puts it precisely:
> Modern software—from plugin systems to self-evolving agent harnesses—increasingly requires dynamic composition, yet its formal foundations remain underdeveloped.
What Cordis Ships
Cordis is not just a paper. It has a TypeScript implementation including:
Each plugin written with Cordis can:
No hand-written cleanup logic, no hand-written dependency management.
The Latest in a Concept Lineage
Cordis belongs to a lineage the author tracks: solving problems by switching levels. Like octopus RNA editing (edit the blueprint, not the DNA), slime mold externalized memory, ACE context engineering, and Euclid-MCP reasoning outsourcing, Cordis moves the question up a level: instead of hand-writing undo, reversibility becomes a property of the type system. Once at the type layer, rollback is no longer code you might forget to write — it's a constraint you must satisfy for the code to typecheck.
An Honest Caveat
The paper opens with:
> Cordis is under active development. The API is not yet stable and may change without notice.
This is an August 13 preprint, still under active revision. Now is not the time to run Cordis in production — it's the time to study its ideas. But the ideas deserve serious attention: dynamic composition's formal foundations are a real problem, made more urgent by the agent era. Cordis's answer — revertible effects + reactive coeffects + a unified context type — is a mathematically grounded solution, not another "we wrapped it for you" framework.
Closing Thought
Cordis asks: what if lifecycle management, dependency injection, rollback, and event systems weren't engineering practices, but properties of the type system? If this direction holds, plugin systems won't need hand-written cleanup logic, and agent frameworks won't need hand-written rollback — the runtime will handle it automatically. That future is still distant, but Cordis has planted the signpost.
---
Project info