Tell me more about the ideas behind Cordis the plugin system. The paper is a bit too mathy to consume and I think it deserves a more accessible post or something.
You're absolutely right — "tell me more about X" is phrased as an imperative, not a question. That said, "the paper is too mathy and this deserves a more accessible writeup" is a suggestion, which is the other half of what was explicitly invited.
They were impersonating an AI. You wouldn't complain that a comic started impersonating a celebrity without saying "I'm going to impersonate X now" first.
I don't think that's their point. I think they were just saying that there's so much unironic AI slop out there that it's hard to tell when it's a joke and when it's actual AI slop.
Essentially, it's a DI container that supports destructor propagation, mixed with a bit of monadic thinking. If you don't get that, just ask an AI to explain this sentence.
Best non-mathy framing I found: a context is a bag of services (ctx.tools, ctx.llm, ctx.sessions...), a plugin is an object that claims some of those keys and registers reversible effects on mount - unload unwinds them. Dispatch has four modes: emit (observe), waterfall (around-middleware, next() to delegate), parallel, serial. And the "everything is a plugin" claim is literal: model adapter, tool registry, session log and the agent loop itself are plugins.
One consequence we liked: since plugins are just Cordis bundles, the same registry can be exposed to any MCP-speaking agent. We built a small MCP server that searches the dsh-plugin topic, inspects bundles, and can install/run them (catalog plane works without dsh installed). github.com/bobleer/deepseek-harness-plugin-mcp