How an "everything is a plugin" architecture reframes what an AI agent actually is — and what it teaches builders of any agent stack.
1.
The Agent Is More Than the Model There's a persistent shorthand in agent engineering: take a capable LLM, give it a system prompt and a handful of tools, and call the result an "agent." That shorthand works for demos.
It falls apart the moment an agent needs to run for more than a few minutes, survive a restart, call a sub-agent, recover from a failed tool call, or let a human inspect what it actually did three hours ago.
Once you cross that line, an agent needs a lot of infrastructure that has nothing to do with the model itself: a place to execute tools safely, a way to keep state across turns, a policy for what context the model sees on each call, a mechanism for delegating work to other agents, a sandbox to contain what the agent can touch, a way to recover from partial failures, and a record of what happened that a person — or an evaluation harness — can replay later.
Collectively, this surrounding machinery is often called the agent harness: the runtime that sits between the model and the world, and that actually determines how the agent behaves in practice.
Two agents built on the same underlying model can behave completely differently depending on the harness wrapped around it — how it manages context, what tools it exposes, how it recovers from errors, and how it schedules work.
DeepSeek Harness (), an open-source project released by DeepSeek AI in developer preview under the MIT license, is a useful concrete example of where this thinking leads when taken seriously.
It didn't invent the idea of an agent harness — Anthropic's Claude Code, OpenAI's Codex CLI, and various open-source agent frameworks have been converging on similar territory.
What makes DeepSeek Harness worth a close read is how far it pushes a single architectural commitment — "everything is a plugin" — and what that commitment forces the rest of the design to look like.
2.
What Is DeepSeek Harness?
In plain terms: DeepSeek Harness is a runtime for building and running coding/automation agents.
You install it, point it at a model provider, and get a working agent — with file editing, shell access, web search, sub-agents, and a web UI — out of the box.
It's explicitly model-agnostic: alongside DeepSeek's own models, the provider catalog covers Anthropic, OpenAI, AWS Bedrock, Azure, and Google's Gemini Enterprise Agent Platform, plus custom OpenAI-compatible endpoints.
Nothing in the design ties the harness to DeepSeek's own models — a telling signal about what the project is actually trying to be.
Technically, the separation is stricter than "the code happens to support multiple providers." DeepSeek Harness is built on a general-purpose plugin framework called Cordis, whose composition model is described in a paper titled "A Programming Paradigm for Spatiotemporal Composability" by researchers from Peking University and DeepSeek.
Cordis provides plugins with a shared context (), through which they contribute services, typed events, and — notably — reversible effects.
According to the project's own architecture documentation, "every part of the product is a plugin, including the model adapter, the tool registry, the session log, and the agent loop itself." There is, by design, no privileged core to patch: extending the harness means mounting a new plugin beside the existing ones, and every registration is an effect that cleanly unwinds when its plugin unloads.
This separation matters for a simple reason: it turns the model into an interchangeable component rather than the organizing principle of the system.
The runtime doesn't just call an LLM — it owns the session, the tool pipeline, and the execution history independently of which model happens to be answering right now.
That's the practical meaning of "model-vs-harness separation," and it's the assumption that makes the rest of the architecture legible.
3.
The Architecture At boot, a running instance is a plugin tree assembled from ordered layers.
A profile (the docs ship and templates) lists which bundles it stacks; a bundle is a distribution unit of Cordis configuration plus the code it mounts. is the foundational bundle every profile includes — model adapters, tools, persistence, sandbox and approval policy, credentials, telemetry — and or add a browser UI or a one-shot runner on top.
Layering is deterministic and inspectable: you can run and see the exact plugin tree your machine will boot, then override any row with your own patch file.
A handful of core packages anchor this tree (each owning a distinct piece of , the shared plugin context): Package Owns The append-only session-event log and in-memory store Prompt-section and tool-schema assembly The scoped tool registry and guarded execution pipeline The interface, live registry, and lifecycle events The default driver implementing that interface Message/stream vocabulary and the model-adapter seam Zoom out from the package table and the shape is straightforward: a Cordis kernel sits at the center, and the agent loop, the model adapter (), the tool registry (), skills, the subagent runtime (), the sandbox and filesystem layer, and the session log () all hang off it as sibling plugins.
The tool registry talks to the sandbox to actually execute anything; the session log receives events from everywhere else and is what fork, resume, and the trajectory UI all read from.
Crucially, the agent loop itself is just one more plugin in that list, not a privileged core the others report to — which is precisely the point.
The runtime has no single "agent class" you subclass; it has a composition of independently swappable services.
4.
The Plugin Architecture: Why Bother?
It would be easy to read "everything is a plugin" as an engineering slogan.
The more interesting question is what problem it actually solves.
A monolithic agent framework typically hard-wires its tool list, its context-management policy, and its loop logic into one execution path.
That's fine until you need to change one dimension without touching the others — swap the sandbox for a remote one, add a new model provider, or give a subset of sessions a different toolset.
In a monolith, those changes ripple through shared code paths and are hard to test in isolation.
DeepSeek Harness's answer is what its docs call a capability seam: a swappable capability defined by three roles — a Service Definition (the interface), a Service Provider (an implementation), and a Consumer (typically a model-facing tool).
Filesystem and subprocess access are one seam; because Bash, PTY access, and code-navigation tools all consume that same seam, pointing it at a remote sandbox moves all three together, with no need to fork any of the individual tools.
Subagents are a different seam — one where multiple provider implementations coexist by name in the same context (a locally spawned child, a forked child sharing conversation history, a delegated Claude Code or Codex session), because different delegation strategies are genuinely useful side by side, not mutually exclusive.
This is the architectural difference from a typical monolithic framework: capabilities aren't conditionally-compiled features of one big class, they're independently loaded plugins that contribute to a shared context and can be added, removed, or replaced without touching the runtime's source.
The project's own extension guidance is concrete about this — adding a model provider means registering an adapter on ; adding a model-facing capability means registering on ; confining spawned processes means providing a backend that tool consumers wrap around before spawning.
None of these require modifying the agent loop.
5.
The Agent Loop DeepSeek Harness's documentation describes execution in terms of turns and steps, not a single flat request-response cycle.
A step is one model request plus whatever tools it calls; a turn is zero or more