What is Different About A Harness That Uses Plugins?

The brouhaha about the just-released open-source harness from DeepSeek has caused a stir, but I found most explanations lacking.

Hi, I'm Tat. I teach AI, machine learning, and how to interact with AI, which I call prompt composition. To teach anything well, one must learn to understand the topic deeply in order to internalize it and really feel its importance.

So, I dug into DeepSeek's Cordis meta-framework for agentic workflows. Most everyone is touting the fact that it's based on a plugin architecture, which is true. But the real gem is how they've implemented it.

One of the issues with advanced agentic systems is reversibility. When a workflow creates, updates, or deletes an entity like a database record, it's no easy feat to reverse or roll it back. Now add to that dependencies, like how deleting a sales record also deletes a record in your finance and ERP app. These dependencies and the need to respect transaction atomicity add even greater complexity and risk.

And how are the various nodes talking to each other as they traverse their own edges (workflow paths)? What is in charge of orchestration for things like memory, context, and state? Each plugin requires specific inputs to generate an output. A mechanism must be created to pause and reverse related actions to a point in time where everything is in the correct state relative to other node states. Because not all nodes need to run serially, other agents can continue on their merry way until they need an output from a dependent agent. For this, Cordis uses a shared context (Context Paradigm), which acts like a communication bus for all agents in the system. Context and plugin definitions for input requirements, outputs, and dependencies are stored there.

This is the key problem to be solved; otherwise, plugins are not that useful. So, let me explain the spatial and temporal components as described in DeepSeek's math-heavy paper, "Spatiotemporal Composability." The spatial part is *where* something happens, and the temporal part is *when* it happens. You can combine components as plugins, and they will still work together.

If you think of an agentic system like a complex flowchart, you can easily visualize a graph with different agents doing different things in different parts of the graph at different times, sometimes stopping and waiting for another agent to pass them something they need to continue. Think of cars, trains, buses, and pedestrians all moving toward their destinations in a smart city. There are traffic lights, speed governors, waypoints with connection points, and other factors, like the weather, that affect what's happening all over the city.

AI is simply about transforming A to B. In an agentic system, it's: "Given what is happening here, what happened before, and what is happening nearby, predict what will happen here or elsewhere next." Just like you have to transform data when doing data engineering for machine learning, transformations are required to reconcile resolution, coordinate systems, timestamps, causality (where applicable), and uncertainty. If you were to substitute one plugin for another, do they both have the same input and output specifications? And even if they do, how and where is all the information up to that plugin swap stored so that it can be preserved going forward? This information contains elements of space and time—the "where" and "when" in the context of the overall workflows in the agentic system.

So, let's bring back "composability." Spatial composability refers to things that can be combined across locations, and temporal composability refers to things that can be combined across time. Finally, spatiotemporal composability refers to things that can be combined across both space and time while preserving their relationships.

That is the elegance of the Cordis meta-framework. In the context of modern AI, where the progression is Prompt → Context → Specification → Workflow → Agent → Environment/World, spatiotemporal composability addresses the tail end of that progression. The AI begins to understand its environment beyond simple text and static information; it is reasoning about states, events, entities, locations, and changes over time.

And how it manages changes over time is truly innovative. Each transformation carries with it its inverse so that information (state) is revertible. That's the role of the spatial component. Think of the chain rule in calculus going backward. It's like rolling back a series of partial differential equations, but it's far more than that. The temporal component has a map of all the dependencies—a topological map so that it understands the "coeffects" and is reactive. Both have access to a shared context.

Let's go back to our smart city example. The components for a smart city implementation might include statistical models, ML models, simulations, sensors, agents, databases, rules, external APIs, human decisions, and more. Some are interconnected, some are dependent, and all are happening in different places at different times.

But the real world is far more complicated, and we can understand it when we see the real world in its higher-order dynamic states: acceleration, diffusion, curvature, propagation, local interactions (local minima and maxima), and rates of change of rates of change. Throw in MoEs (Mixture of Experts), and you have subsystems within systems.

If all this works as intended, then what we could have are self-evolving agent harnesses that can dynamically compose tools, execution environments, memory, permissions, subagents, and workflows, and potentially modify their own components while continuing to operate.

Now let's go back to why plugins matter. The paper, “A Programming Paradigm for Spatiotemporal Composability,” proposes a way to dynamically add, remove, and replace software components (plugins) in a running system while automatically managing both their dependencies and the side effects they leave behind, providing a way to revert to a known stable state.