The model gets the headline. The harness gets the margin.
That pattern showed up again this week when DeepSeek Harness hit the AI newsletter circuit as a trending open-source repo. Tagline: Everything is a Plugin.
I have shipped enough agent projects to know the boring truth. Clients rarely fail because they picked the wrong foundation model. They fail because the loop around the model is opaque, brittle, or owned by a vendor who can change pricing tomorrow.
An open harness is not automatically better. It is inspectable. For some teams, that is the whole game.
What "everything is a plugin" implies
Closed agent products bundle tools, memory, browser access, and sandboxes behind one brand. DeepSeek's framing pushes those concerns to the edge of a plugin boundary.
Conceptually:
| Layer | Typical responsibility |
|---|---|
| Core loop | Plan, act, observe, retry |
| Tool plugins | APIs, databases, browsers, file systems |
| Memory plugins | Short-term scratch, long-term retrieval |
| Runtime plugins | Sandboxes, credentials, execution policy |
| Model backend | Swappable LLM provider |
You have seen variants of this diagram in Claude Code, Cursor, and Cognition's Devin routing story. The difference is ownership. When the harness is open source, your compliance team can read the retry logic. Your platform team can patch the sandbox defaults.
Why this landed in the same week as turf wars and Ultrafast
The Rundown AI digest that flagged Harness also covered Anthropic's multi-agent sabotage study and OpenAI's Ultrafast preview. Those stories look unrelated. They are the same market maturing on three axes:
- Speed (Ultrafast, Flash-tier models)
- Coordination risk (multi-agent failures)
- Harness commoditization (open plugin stacks)
When inference gets faster and cheaper, you run more agent steps. When you run more steps, harness quality dominates outcomes. When harnesses open up, differentiation moves to your plugins and your evals.
That is good news for applied engineers. Bad news for "we just resell API tokens" shops.
Closed vs open harness: a honest comparison
| Dimension | Closed vendor harness | Open plugin harness |
|---|---|---|
| Time to first demo | Fast | Slower |
| Custom tool wiring | Limited to supported integrations | You build plugins |
| Model choice | Often bundled | Usually swappable |
| Compliance review | Black box | Code review possible |
| Upgrade risk | Vendor roadmap | Your merge conflicts |
| Best for | Teams optimizing speed | Teams optimizing control |
I am not anti-Cursor or anti-Claude Code. I use them. I also have clients in regulated or data-sensitive environments where "trust the vendor sandbox" is not an acceptable architecture slide.
How I would evaluate DeepSeek Harness in a real project
Before recommending any open harness, I run the same due diligence:
1. Plugin API stability
How often do plugin interfaces break? Do examples ship for the tools you already use (Postgres, Slack, S3, internal REST)?
2. Sandbox defaults
Anthropic's turf war paper is a reminder that shared environments need least privilege. Read the default execution policy before you connect production credentials.
3. Observability hooks
Can you export structured traces per tool call? Without that, debugging a 40-step loop is guesswork.
4. Model routing
Does the harness assume DeepSeek models only, or can you point at OpenAI, Anthropic, Google, and local endpoints? Vendor-neutral routing future-proofs spend.
5. Your eval harness
Clone your top ten production tasks. Run them on the open harness vs your current stack. Measure pass rate, cost, and wall-clock. Marketing stars on GitHub are not a benchmark.
Where Harness fits in a sensible agent roadmap
For most SMEs I work with, the order still looks like this:
- One agent, one workflow, one owner (after-hours voice, invoice extraction, lead chase)
- Observability and human escalation
- Routing across model tiers (cost per task thinking)
- Only then multi-agent fan-out with explicit conflict policies
Harness is infrastructure for step 3 and 4. If you are still on step 1, do not fork a repo because it trended on Hacker News.
If you are at step 4, read Anthropic's multi-agent research first. Plugins multiply capability. They also multiply ways to step on each other.
Open source agent stacks are having a moment
DeepSeek Harness landed beside other open tooling noise this month: coding agents, routing libraries, and harness-adjacent projects across GitHub. The pattern is familiar from web frameworks in the 2010s. Standards emerge after a Cambrian explosion.
My bet: winning teams compose open harness + proprietary plugins + private eval data. The harness becomes boring infrastructure. Your plugins encode domain logic. Your evals encode quality bars.
Practical next steps
If Harness is relevant to your stack:
- Star and read the repo: github.com/deepseek-ai/deepseek-harness
- Prototype one internal workflow with a single plugin you control
- Compare trace logs against your current vendor agent for the same task
- Decide whether ownership savings beat integration cost over 12 months
If not, still steal the architectural lesson. Treat tools, memory, and sandboxes as replaceable plugins, even inside a closed product. That mindset makes future migrations cheaper.
Want help designing an agent harness that matches your ops reality? Book a free discovery call.