Cordis: Giving Dynamic Composition a Formal Foundation
> While plugin systems, agent frameworks, and hot-reload mechanisms each reinvent their own wheels, cordiverse/cordis attempts to turn "composability" itself into a programming paradigm.
- GitHub: https://github.com/cordiverse/cordis
- Paper: https://github.com/cordiverse/paper
- Plugins leave dirty state after unloading — config files not cleaned, event listeners not detached, global variables still hanging around
- Plugin A depends on plugin B; B upgrades and A breaks
- You want hot reload, but the old instance's side effects can't be rolled back, so you restart the whole app
- Two plugins modify the same file simultaneously — ordering is pure luck
- Temporal composability: when a component is removed, all of its side effects can be fully rolled back.
- Spatial composability: dependencies between components are declarative, and components are reactively notified when dependencies change.
- Effects are what a component does to its environment (write files, send requests, mutate global state)
- Coeffects are what a component demands from its environment (a config must exist, a service must be available)
- Agents load new tools at runtime
- Agents form temporary coalitions
- Tool versions upgrade at runtime
- Agents need to roll back to prior states after failures
- Core library: effect tracking + coeffect resolution
- Declarative component loader: config reconciliation + hot module replacement
- Declare its effects and coeffects at load time
- 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
- Stars: 616 (listed 2026-08-15)
An Old Problem
Have you ever written a VSCode plugin? Or an Obsidian plugin, a Chrome extension, an Agent tool?
If so, you've probably hit these pitfalls:
These look like engineering problems, but the cordiverse team argues they are theoretical problems — we have never formally defined what "composable" means.
Cordis's paper is titled *A Programming Paradigm for Spatiotemporal Composability*, with a preprint released August 13, 2026. It is not yet another framework but a meta-framework — it defines how frameworks should be composed.
Two Orthogonal Dimensions
Cordis decomposes composability into two independent dimensions:
The core insight: both can be solved with the same mathematical tools — effects and coeffects.
These concepts have existed in programming language theory for decades. Cordis's novelty: promoting them from compile-time type systems to 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's 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 arrays, but generalized — not just internal state subscription, but cross-component dependency management.
Crucially, Cordis unifies effect contexts and coeffect contexts into a single context type. This is not simple concatenation but a mathematical unification — a calculus of dynamic composition that extends per-component composability to entire interleaved component systems.
Why Now
These concepts may sound academic, but the agent era makes dynamic composition a hard requirement:
In these scenarios, "reversibility" and "reactive dependencies" are no longer nice-to-haves but preconditions for not crashing.
From the paper:
> 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:
Every plugin written with Cordis can:
No hand-written cleanup logic. No hand-written dependency management.
Placing Cordis in a Conceptual Lineage
Cordis belongs to a pattern of "solving a problem by shifting levels": rather than doing the same thing harder, change the level at which the problem lives so it disappears. Cordis's shift: elevate "how to roll back" from the engineering layer (hand-written cleanup) to the type layer (every operation carries its own inverse). At the type layer, rollback is no longer code you might forget to write — it's a constraint that fails to compile if absent.
An Honest Caveat
The paper states up front:
> 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 is the time to study its approach.
The approach itself deserves serious attention. Formal foundations for dynamic composition are a real problem, made more urgent by the agent era. Cordis's answer — revertible effects + reactive coeffects + a unified context type — is a scheme with a mathematical skeleton, not another "we wrapped it for you" framework.
Closing Thought
Cordis asks: what if these things — config management, dependency injection, lifecycle management, rollback, event systems — were not engineering practices but properties of the type system?
If this direction holds, future plugin systems won't need hand-written "what to clean up on unload" — the type system will tell us. Agent frameworks won't need hand-written "how to roll back after tool failure" — the runtime executes the inverses automatically.
That future is still distant, but Cordis has planted the signpost.
---
Project info