TL;DR Of why dsh/cordis is a big deal: LH tasks and harness meta tuning

The core idea is that long-horizon tasks might need a harness to run for days, and Cordis enables support for two scenarios: a component of the harness crashes, and we want to recover without having to restart it and lose the state. an additional component, e.g., a new MCP that was not loaded, is requested by the orchestrator. Cordis enforces a set of guidelines for how plugins should be designed to support these two scenarios: they all communicate via a shared context that is passed around. they declare a schema specifying how they change the context. they should declare their dependencies on changes to context they publish an undo change for each change they make to the context. These all together mean you will have a reversible, tracked dependency between all the changes and components, managed via a versioned context. So, for the two scenarios above: if a plugin crashes, you track each of its dependents and notify them, and they either suspend themselves or degrade gracefully aka temporal composability via revertible effects. you add a new plugin, and it updates the context, triggering a chain of updates downstream aka spatial composability via reactive updates. I suspect this is how they're achieving cache hits close to 100%: no more than what is mathematically necessary of the state is thrown away when a tool call fails, an MCP crashes, etc. See the paper here https://github.com/cordiverse/paper p.s. It's not too dissimilar to how React/redux manages shadow dom using immutable state updates, but I digress.