I Argued the Harness was the Product. Then DeepSeek open-sourced theirs.
What’s actually inside dsh and what happens when the moat becomes open sourceThe agent harness, opened into its replaceable parts.In May, I argued that the model is not your product. The harness is.The scaffolding, tools, context management, retries, evals, permissions, and observability: models…
What’s actually inside dsh and what happens when the moat becomes open sourceThe agent harness, opened into its replaceable parts.In May, I argued that the model is not your product. The harness is.The scaffolding, tools, context management, retries, evals, permissions, and observability: models get rented. Harnesses get built. The harness is the part you own, and the part that compounds.Three months later, DeepSeek gave theirs away.On August 13, alongside the general release of DeepSeek V4 Pro, the company published DeepSeek Harness under an MIT license. This was not a paper or a wrapper demo. It was a large TypeScript monorepo with a web UI, headless runner, sandbox and execution layers, plugin framework, and unusually direct architecture documentation.The launch was enormous. The repository had roughly 95k GitHub stars after two days. As of September 16, it has more than 225k stars.So let’s open it up.What shippedThe command is dsh:npx @deepseek-ai/dsh webThat starts a local web UI on 127.0.0.1:3080. There is also a headless bundle for a single task without the web interface, the kind of surface you could connect to CI or automation.Although it comes from DeepSeek, the harness is not limited to one model family. It includes a direct DeepSeek route and a multi-provider adapter that can work with several model APIs and compatible gateways. The model provider is another replaceable service, not the identity of the system.That is an unusual move for a major AI lab: DeepSeek built infrastructure that remains useful even if you use someone else’s model.The whole project rests on one claim in the README: everything is a plugin.That sounds like marketing. It isn’t. It is a core design decision, and the rest of the project shows what it takes to make it work.No privileged core to patchUnderneath dsh sits Cordis, the framework that powers its plugin architecture. Its design is now formalized in A Programming Paradigm for Spatiotemporal Composability, a 92-page preprint from researchers affiliated with Peking University and DeepSeek AI.Cordis is built around a simple goal: plugins should be easy to add, replace, and remove while the application is running without leaving broken state behind.It does this through a few basic ideas:The context is a shared service registry. A plugin registers a capability under a stable name such as ctx.tools or ctx.llm. Other components can then use that capability without importing one specific implementation.Plugins declare what they need. They activate when their required services are available and deactivate when those services disappear.Components communicate through typed events. This gives plugins clear places to listen, respond, or modify behavior.Plugin changes can be reversed. When a plugin is removed, Cordis also removes the listeners, tools, services, and prompt sections that it added.This means there is less of a hard boundary between the “core” and its extensions.The model adapter is a plugin. The tool registry is a plugin. Session handling is built from plugins. Even the agent loop is a plugin. Instead of modifying the central codebase, you can add or replace a component beside the existing ones.The turn loop, unwrappedThis is the part every agent builder writes badly at least once.A step is one model request, and the tool calls it produces. A turn contains zero or more steps.“Zero” matters here. Even if the system rejects a request before calling the model, the attempt can still be recorded and inspected later instead of silently disappearing.Conceptually, the loop looks like this:One agent turn can contain multiple model-and-tool steps before it ends.Think of each line as a place where you can add controls or change behavior.The pre-step hook controls what the model receives. This is where you can remove personal information, enforce spending limits, apply content rules, add business context, or rate-limit requests, without rewriting the agent loop.The tool pipeline provides the natural boundary for approvals, timeouts, and audit records. The stopping hook owns a decision rather than another transformation stage.Events are divided into three groups:Session events record information that must survive a restart.Agent events describe work that is currently happening.Capability events let plugins control tools such as the filesystem without depending on the entire agent loop.This separation forces developers to answer an important question: does this information need to survive a restart?The rule I want to stealThe best sentence in the architecture document is four words:Model visible means logged.The session log is the source of truth for what the model was sent. deriveMessages() rebuilds the conversation from that log instead of relying on a separate copy of the message history.Anything sent to the model must be recoverable from the log, and the runtime checks that this rule is being followed. If a plugin wants to add new information to the model’s context, it must first record that information — or define a predictable way to rebuild it from recorded events.In other words, plugins cannot secretly add context through an unrecorded path.That extra work is useful. It means that when an agent produces a strange response, you can reconstruct what the harness actually sent to the model.So what changed?For years, the moat was the model. Then models started becoming more interchangeable: more open weights, falling prices, faster capability convergence, and more provider choice.The fallback argument was that the harness was the moat. That was my argument in May, and I still think it correctly identified where much of the engineering value sits.But DeepSeek has now published a serious harness under MIT, and the community started extending it almost immediately. So the argument needs an amendment.An open harness is a chassis, not a car.What dsh gives you is a clean set of extension points. But extension points are empty until you add behavior that matters to your users. ctx.tools becomes valuable only when you register tools that understand your domain. A pre-step hook does nothing until you add the policies your business needs. The session log can show what was sent to the model, but it cannot tell you whether the answer was useful.That judgment lives elsewhere:in the proprietary workflows your users actually need;in approval and escalation rules earned through incidents;in eval sets built from real failures;in integrations with messy, domain-specific systems;in the data, feedback loops, and trust that improve with use.An open-source project cannot build those things for you.The defensible part was never the plumbing by itself. It was the judgment encoded into the plumbing, and the evidence that the judgment works.What DeepSeek deleted is the excuse.You no longer get to spend six months rebuilding a generic turn loop and call it product differentiation. A strong version of that layer now exists in public, with inspectable architecture and an MIT license.Read the architecture document.The model is the loud part. The harness is the part that ships.And now, the harness is also the part you can inspect, fork, and replace.Repository: github.com/deepseek-ai/deepseek-harnessThis story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!I Argued the Harness was the Product. Then DeepSeek open-sourced theirs. was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.Source: Generative AI Pub — Published — Category: Image AI