By Grego
During a good part of the career of coding agents we discussed the most visible variable: the model. Claude versus GPT, DeepSeek versus Gemini, open weights versus proprietary APIs. But if the last few months made anything clear, it’s that the model explains only part of how an agent behaves.
The rest lives around it.
The agent loop. The tools. Memory. How context is built. How a session persists. What happens after a tool call. When the agent reasons again and when it decides it’s finished.
All of that forms the harness.
And on August 13, DeepSeek made a pretty interesting bet on that layer: it released DeepSeek Harness (dsh), an open source framework under MIT license whose central architectural principle can be summed up in four words:
Everything is a Plugin.
It’s not just marketing. In dsh, even the agent loop itself can be replaced.
That makes the project something quite different from another open source clone of Claude Code.
First: what exactly is an agent harness
A model by itself is not a coding agent.
You can give code to an LLM and ask it to generate a patch. But for that model to be able to inspect a repository, run commands, read results, modify files, run tests, reason again, and decide what to do next, you need a layer that coordinates all that process.
Simplifying, the loop looks like this:
user
↓
model
↓
decides to use a tool
↓
runtime executes the tool
↓
result comes back to the model
↓
model reasons again
↓
another tool / final response
Claude Code has one.
Codex has one.
Cursor has one.
OpenCode has one.
And there’s increasing evidence that the differences between those harnesses can be as important as the differences between the models running inside them.
DeepSeek Harness takes that idea one step further: instead of giving you a monolithic harness that you can configure, it tries to convert the fundamental pieces of the harness into interchangeable components.
“Everything is a Plugin”
The architecture of dsh is built on Cordis, a modular framework based on services and plugins.
DeepSeek divides the system into components that can be registered and replaced.
Among them:
- model adapters;
- tool registration and execution;
- session persistence;
- interfaces;
- additional capabilities;
- and the agent loop.
That last point is the important one.
In many frameworks you can add tools to the agent. You can change the model. Maybe you can plug in a different memory implementation.
But you reach a point where you touch the framework’s core: this is how our agent thinks and executes; if you want something else, start modifying internals.
DeepSeek is trying to eliminate that boundary.
The loop is also a plugin.
Why would you want to replace the agent loop
Because not all agents should work the same way.
Imagine a simple coding agent. It can use a ReAct-style loop:
reason
→ execute tool
→ observe
→ reason
→ execute tool
→ observe
Perfectly reasonable for many tasks.
But maybe you’re building a code review agent and you want a different architecture:
analyze diff
→ search for context
→ generate hypothesis
→ verify each hypothesis
→ discard false positives
→ produce review
Or an agent for migrations:
plan
→ create checkpoint
→ modify module
→ run tests
→ verify
→ continue
→ rollback if it fails
Or maybe you want a system where multiple agents work in parallel and a supervisor decides which results to accept.
Those aren’t just different prompts.
They’re different loops.
If the loop is hardcoded inside the framework, building them means fighting with the framework.
If the loop is a plugin, it becomes an explicit architectural decision.
That’s where the really interesting part of dsh is.
The model also stops being the center
The same principle applies to the provider.
A model adapter is another plugin.
That means the architecture doesn’t need to be conceptually tied to DeepSeek. You can build a profile where the model is a replaceable piece of the system, the same way you swap out a storage implementation or a tool.
That separation matters especially for teams building agent infrastructure.
Over the last two years we’ve seen too many systems where the entire architecture ends up reflecting the quirks of the chosen provider’s API from the start.
Then a better or cheaper model comes along and migrating turns out to be much harder than expected.
A truly modular harness changes that relationship:
Agent
├── Model Adapter
├── Tool Registry
├── Session
├── Agent Loop
├── Interface
└── Custom Plugins
The model is still extremely important.
But it stops being the architecture.
Profiles and bundles: compose instead of fork
Another useful idea from dsh is separating agent composition from framework code.
Profiles describe what combination of components you want to run.
Bundles let you group sets of plugins and reusable configurations.
Conceptually, this allows you to have something like:
coding-agent
model
filesystem
git
terminal
coding-loop
security-agent
model
filesystem-readonly
scanner
security-loop
review-agent
model
git
diff-analyzer
review-loop
```Everyone can share the same infrastructure without becoming a single "super agent" full of conditionals.
For platform teams, this separation is especially attractive.
Instead of maintaining separate forks of the runtime, you maintain separate compositions.
## **How to Try It**
DeepSeek Harness is published as an open source project and is currently in **developer preview**.
The official repository is:
`deepseek-ai/deepseek-harness`
The project documentation includes updated setup and examples for launching the harness and working with its profiles and plugins.
And it's worth respecting a warning from DeepSeek itself: **this is still not a stable production framework.**
The API can change.
Plugins can break compatibility.
The configuration structure can evolve.
If you're going to try it today, think of it as an opportunity to understand the architecture and build experiments, not as a dependency you necessarily want to freeze immediately within critical infrastructure.
## **The Ecosystem Has Already Started to Emerge**
Perhaps the most interesting signal came after the launch.
In just days, community projects began appearing around `dsh`: additional plugins, interfaces, integrations with containers, and directories for discovering extensions.
It's too early to declare that a mature ecosystem exists.
But it does demonstrate something important about the architecture.
When a project declares that "everything is a plugin", the real test isn't in the README. It's whether third parties can build interesting things without modifying the core.
The early signals indicate that's happening.
## **This Doesn't Mean DeepSeek Has "Solved" Agents**
You have to separate an interesting architecture from a finished product.
DeepSeek Harness is in developer preview. Claude Code, Codex, Cursor, and other products have spent much longer accumulating optimizations around retrieval, tool use, permissions, sandboxing, context management, UX, and agent behavior.
A more open architecture doesn't automatically mean a better agent.
In fact, modularity has a cost.
The more pieces you allow to be substituted, the more combinations you need to test. One plugin can assume behaviors that another doesn't guarantee. Two different loops might require different interfaces. Observability and debugging become more important.
Architectural flexibility always trades freedom for complexity.
But `dsh` doesn't need to beat Claude Code as a product today to be interesting.
The bet is elsewhere.
## **The Harness Is Becoming the Product**
Two years ago, many AI coding tools could be described roughly like this:
Pretty UI
+
Frontier model API
That changed.
The most advanced products now have enormous amounts of engineering around the model: context retrieval, memory, sandboxes, tool orchestration, subagents, permission systems, compaction, hooks, specialized skills and loops.
The model is progressively becoming a component within a much larger machine.
DeepSeek Harness takes that conclusion to its logical extreme:
**if the harness matters this much, make it programmable.**
And if you really want to make it programmable, it's not enough to let someone add a tool.
You have to let them change how the agent works.
## **Why This Matters for Teams in Latin America**
There's an especially interesting angle for teams that don't want to build their entire infrastructure around a single provider.
An open and modular harness allows you to experiment with different combinations of models, tools, and runtimes without starting from scratch each time.
That could mean using a commercial model for certain tasks, a self-hosted open-weight model for others, and specialized loops for workloads where behavior matters more than general intelligence.
Not every team needs to build their own coding agent.
Probably most shouldn't.
But companies that are building internal agents—for engineering, operations, security, support, or business-specific workflows—are starting to need exactly this kind of abstraction.
Not a chatbot.
Not another wrapper.
An **agent execution layer you can control**.
## **The Signal Worth Following**
For a long time we asked:
**What model does your agent use?**
Then we started asking:
**What tools does it have?**
The next question is probably going to be:
**What harness runs underneath?**
DeepSeek seems to have arrived at that conclusion early.
`dsh` is still young, experimental, and probably going to change quite a bit. But the idea behind the project is much more important than its current version.
DeepSeek didn't just open-source another coding agent.
**It open-sourced the pieces you can use to build your own.**
And when even the agent loop becomes a plugin, the model definitively stops being the only place where innovation happens.