What DeepSeek's Open-Source Agent Harness Gets Right

A few weeks ago, my dad and I spent an afternoon at the kitchen table trying to figure out what an "AI agent" actually is. We landed on four layers — prompt, context, harness, loop — and the clearest sentence to fall out of it was this one: an agent equals a model plus a harness.

Last week DeepSeek open-sourced a developer preview called, plainly, Harness. The landing page opens with three words: Agent = Model + Harness.

I didn't expect to see my own napkin math on a company's homepage. Most of my work weeks are spent building agent systems, so I read the thing properly, and it turns out the equation is the easy part — the interesting bit is how much further DeepSeek had to go to make it true.

DeepSeek Harness is an open-source, MIT-licensed framework (v0.1, developer preview, launched Aug 13, 2026) for building AI agent runtimes, built on a plugin kernel called Cordis. Its own tagline — "Agent = Model + Harness" — restates a definition I published a month earlier: an agent is a model plus everything around it that lets it act, remember, and recover.

You can run it yourself with one command:

npx @deepseek-ai/dsh web

or clone the source directly. I haven't run it in production — this is a read of the architecture against my own framework, not a review. Worth saying up front, because the rest of this post leans on that distinction.

The four layers, in one sentence each

If you didn't read the original post, here's the recap. An agent is built from four layers, and each one exists because the layer before it wasn't enough:

• Prompt engineering — one input, one output. The unit of work is a single call, and the skill is writing a sentence that carries everything the model needs for that call.

• Context engineering — curating what the model sees across a whole session, not just one message. The finding that changed how I think about this: more context isn't better context. Stuffed windows measurably degrade output — teams call it "context rot."

• Harness engineering — the layer this post is about. My original definition: "the harness is every piece of code, configuration, and execution logic that is not the model — the tools it can call, the memory it can read and write, the guardrails on what it's allowed to do, the orchestration logic that decides what happens next, the state that persists after the session ends." The etymology is on the nose: a horse is powerful on its own but useless for farming without a harness. Swap in a better model and the harness stays the same — it's a pluggable component underneath, not the star of the show.

• Loop engineering — the newest layer, still being named as people build it. The shift from a human typing "now do the next thing" at every step, to a system that reasons, acts, observes, and decides the next step on its own.

  

Figure 1 — each layer exists because the one below it wasn't enough on its own. Image from here.

DeepSeek's own framing of the harness layer: "The model is the soul of an agent. A harness lets an agent understand its environment, use tools, and keep working in real-world settings." Different words, same claim.

The proof isn't the tagline — it's the plugin list

Anyone can put "Agent = Model + Harness" on a landing page. What actually tests the claim is what happens when you ask: if the harness is separate from the model, can you prove it by swapping the model out and watching the harness not care?

DeepSeek Harness's answer is its plugin architecture. It's built on Cordis, a plugin kernel, and the capability list reads like this: models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI — nine plugin categories, and the model is just one of them, sitting in the list next to storage and scheduling, not above them.

That's the load-bearing detail. My post argued the harness doesn't make the model smarter — it's a pluggable component underneath. DeepSeek's architecture doesn't just agree with that sentence, it enforces it: "Developers can select, swap, or extend any capability in configuration without changing the DeepSeek Harness source code." The model isn't privileged in the codebase. It's a plugin like any other, which means the harness genuinely doesn't know or care which model is plugged into it.

graph TD
    subgraph HARNESS["Harness — Cordis plugin kernel"]
        MODEL["Model"]
        TOOLS["Tools"]
        SKILLS["Skills"]
        SESSION["Sessions"]
        SANDBOX["Sandboxes"]
        STORE["Storage"]
        LOOPS["Loops"]
        SCHED["Scheduling"]
        UI["UI"]
    end

Figure 2 — nine plugin categories, one kernel. Model sits in the list, not above it.

Cordis itself — the plugin kernel underneath all nine — is worth a separate mention. It's a general "meta-framework" for reversible, hot-reloadable plugin systems: unmount a plugin and every side effect it caused cleanly rolls back, not just the plugin's own code. One deep-dive on Cordis is worth reading if "everything is a plugin, including removal" is a new idea to you.

I didn't have a name for what that would look like in real code. Now there's a repo.

Two things I only had words for, and DeepSeek has running code for

Two pieces of the original post were more intuition than mechanism. DeepSeek's architecture gives both a concrete shape.

"The harness fakes continuity." I wrote that the model starts every call from zero, and it's the harness that pulls in yesterday's notes and hands them back as context — fake memory, manufactured by the layer around the model. DeepSeek's version of this is an append-only session log: every system prompt, every reasoning step, every tool call and result, every subagent handoff, every context injection, recorded in one event stream. Their "Trajectory view" lets you inspect it by source, and resume, fork, search, and replay all read from the same log. That's not a metaphor for continuity anymore — it's a data structure for it.

graph LR
    A["system prompt"] --> B["reasoning"]
    B --> C["tool call"]
    C --> D["result"]
    D --> E["subagent handoff"]
    E --> F["context injection"]
    B -.-> R1["resume"]
    C -.-> R2["fork"]
    D -.-> R3["search"]
    F -.-> R4["replay"]

Figure 3 — one append-only event stream; resume, fork, search, and replay all read from it.

This isn't a new idea in the abstract — agent observability tooling like LangSmith, Braintrust, and Datadog's LLM Observability already trace and replay multi-step agent runs for debugging. What's different here is where the capability lives: those are external tools bolted onto whatever agent you built. DeepSeek put the event log inside the harness itself, as one of the nine plugin categories from Figure 2, not a separate product you wire in afterward. It's the same instinct behind closed-loop verification in a multimodal agent I wrote up earlier — a trace only earns its keep if something downstream actually reads it back.

The fourth layer, as a literal plugin slot. My post treated loop engineering as the newest, least-settled layer — the shift from manual back-and-forth to a system that runs its own reason-act-observe cycle. DeepSeek's plugin list includes loops and scheduling as first-class, swappable capabilities, sitting right next to tools and memory. I spent a paragraph arguing loop engineering deserved to be treated as its own layer. DeepSeek's org chart already has a box for it.

One harness, four shapes

The other thing my original post glossed over: a harness isn't one fixed set of tools. Depending on what you're building, you want a different amount of scaffolding, and DeepSeek Harness ships that as a first-class choice instead of a config file you have to discover by reading source.

• Standard mode — the full toolset: file editing, shell, file and web search, skills, planning, goals, subagents, workflows. This is the "give it everything" harness.

• Code mode — same capabilities, but tools are exposed through a Code Mode SDK so the model can chain several tool calls inside one TypeScript program instead of one call per turn. Fewer round-trips, more of the orchestration logic living in generated code rather than in the loop.

• Minimal mode — two tools: a persistent shell and a str_replace_editor. Built for benchmarking a model in as thin a harness as possible, which is a genuinely useful idea I hadn't seen articulated this cleanly: if you want to know what the model can do, you strip the harness down until it can barely help.

• Creator mode — Standard mode's capabilities plus runtime inspection and in-memory plugin experiments, for building your own preset.

Minimal mode is the one that clarified something for me. My post argued the harness "doesn't make the model smarter." Minimal mode is that claim turned into a deliberate product feature — a harness thin enough that a benchmark result actually tells you about the model, not about how much scaffolding was doing the work underneath it.

Where the claim gets ahead of the product

Some of the press coverage — VentureBeat's launch writeup, for one — calls this an "open-source rival to Claude Code." I'd hold that a little more loosely than the headlines do. DeepSeek Harness is a framework for building agent harnesses — plugins, a kernel, runtime modes you compose yourself. Claude Code and similar tools are finished products built on top of that kind of infrastructure. Comparing the two directly is a bit like comparing a car chassis to a car.

The project is also explicit about where it stands: v0.1, developer preview, with compatibility-breaking changes promised as it evolves. That's not a knock — it's the right way to ship this kind of thing — but it means the honest comparison isn't "DeepSeek Harness vs. Claude Code" yet. It's "does this plugin architecture hold up once fifty community plugins are fighting over the same Cordis events," and nobody has that answer six days in.

TL;DR

• DeepSeek Harness's own tagline — "Agent = Model + Harness" — is close to verbatim the definition I published a month earlier, down to treating the model as a replaceable component and the harness as the load-bearing layer around it.

• The plugin architecture is the proof, not the tagline. Models sit in the same swappable-plugin list as storage and scheduling — nine categories, model included, none privileged.

• Two things I only had intuition for now have running code: an append-only session log for "the harness fakes continuity," and first-class loops/scheduling plugins for what I called the newest, least-settled layer.

• It's v0.1 and a framework, not a finished coding agent — MIT-licensed, npx @deepseek-ai/dsh web to try it, breaking changes promised. Worth watching, not yet worth comparing head-to-head against a shipped product.

This is a read of DeepSeek Harness's architecture against a framework from my earlier post, Prompt, Context, Harness, Loop: An Agent's Anatomy — not a hands-on review. If you've run it yourself, I'd like to hear what broke. If you liked reading an architecture this closely, I did the same thing recently with Kimi K3's attention mechanism.