DeepSeek Harness changes where you draw the agent boundary

Last month I wrote Building a production-ready AI agent around one claim: the model is the small part. The agent loop is a few lines; the product is the harness around it.

Then DeepSeek published an open-source runtime named exactly after that missing layer: DeepSeek Harness, or DSH.

GitHub’s repository metadata lists the DeepSeek Harness repository as created on August 13. When I checked on August 22, it reported roughly 184,000 stars and 20,000 forks. Those numbers do not prove production adoption. Nine days cannot prove production adoption. They do suggest that this boundary resonated with a lot of developers.

The interesting question is not what the Web UI looks like, how to install dsh, or whether one coding demo feels better than another. The interesting question is what its existence changes.

My recommendation today is straightforward. For a bounded agent inside a product, start with an agent SDK. For an open-ended workspace agent, evaluate a workspace-oriented harness. DSH is a serious candidate, but while it remains a developer preview I would pilot it behind a thin boundary I own, not make its native protocol or configuration the critical contract of my product. If several products need the same governance, I would consider a shared Agent Service separately; that is a deployment decision, not a reason by itself to choose DSH.

My thesis is narrower: DeepSeek Harness turns the reusable execution layer that teams keep rebuilding around agent SDKs into a runtime they can adopt. If its interfaces stabilize, teams can spend less time inventing session semantics, tool lifecycles, and compaction machinery, and more time on the part that is actually theirs: domain context, tools, policy, evaluation, and product experience.

This is an ownership decision before it is a tooling decision.

But that conclusion needs a boundary around it. DSH does not replace your application. It does not replace your business services. And it is not a complete multi-tenant agent platform that a company can safely expose by changing a config file.

It replaces a narrower box. That box is important enough to redraw the stack.

SDK and harness are not clean opposites

“Should I use an agent SDK or DeepSeek Harness?” sounds like a comparison between two products in the same category. It is not quite that.

An SDK describes a control surface. It gives application code types and functions for defining agents, registering tools, running the loop, streaming events, and inspecting results.

A harness describes a system responsibility. It is the execution environment surrounding the model: how requests are assembled, how tools run, how sessions evolve, how context is compacted, how effects are approved, how work resumes, and how the runtime is observed and extended.

Those categories overlap. An SDK can contain a lightweight harness. A harness can expose an SDK.

The current OpenAI Agents SDK, for example, is not merely a bag of low-level primitives. Its runner owns the model/tool loop and it includes sessions, tracing, guardrails, handoffs, and resumable approval flows. If I build on it, I am not writing the loop from scratch.

DSH demonstrates the other direction. Its Python SDK is a programmatic client for the harness; the runtime runs out of process and is driven over JSON-RPC. “SDK” is present on both sides of the comparison.

So feature-counting does not give us a durable definition. The better question is ownership:

How much reusable execution machinery does my application team want to compose, evolve, and operate itself?

With an SDK-first design, the SDK runner sits inside code I own. As requirements accumulate, I compose the surrounding harness: configuration, session persistence, context policy, tool authorization, artifacts, recovery, event translation, and runtime operations. That may be exactly what I want. It is also how a “small SDK integration” quietly becomes a custom agent engine.

With a harness-first design, I adopt more of those execution semantics as a runtime substrate. I still write an adapter and the domain agent. I own less of the generic machinery in the middle.

That is the real comparison: not primitive versus feature-rich, but compose the execution layer versus adopt one.

The missing middle becomes a product

DeepSeek’s important design choice is not any individual feature. Modern agent systems already have tools, skills, sessions, subagents, sandboxes, and streaming. DSH’s bet is that their shared execution semantics can be composed as infrastructure.

Its architecture documentation says the model adapter, tool registry, session log, and agent loop are all Cordis plugins. Profiles are ordered plugin trees. Persistence, sandbox policy, approvals, telemetry, the Web application, and the headless runner are compositions rather than one privileged core that must know about every capability.

That changes the extension model. In a typical SDK application, I add behavior by editing application code or installing hooks around the runner. In DSH, the intended move is to register or replace a capability at a documented seam. The loop is still there, but it stops being the place where every new concern accumulates.

The second important choice is the session model. A DSH session is an append-only event log. Model history is derived from that log rather than maintained as a separate mutable transcript. Prompt inputs, streamed chunks, tool calls, results, compaction events, and lifecycle facts share one canonical vocabulary.

This is more than persistence. Replay, projection, debugging, and compaction provenance derive from one execution record, which can also supply evidence to external evaluation systems. “What did the model see?” stops being an archaeological question assembled from application logs, provider traces, and database rows after the incident.

There are trade-offs. A plugin graph moves complexity; it does not delete it. Version compatibility, configuration layering, lifecycle interactions, and trust in third-party in-process code become first-class engineering problems. An event ledger still needs durable storage, retention, redaction, and operational projections. The advantage is that the seams are named and reusable instead of being rediscovered inside each application.

The larger possibility is one shared execution substrate supporting many materially different agents.

Where the boundary actually sits

The first sketch I made put an SDK at the bottom of one application stack and DSH in a separate large box. The instinct was right — DSH absorbs more machinery — but the diagram mixed two questions and erased two layers that never go away.

The corrected boundary looks like this:

The top two layers are yours in both designs.

The product-owned surface and controls define the user experience and the promises made to callers: a stable API, authentication, tenancy, quotas, rollout, and service-level behavior. They may live in one application or a shared platform.

The domain-agent definition owns what makes the agent different: its goal, prompt, knowledge, skills, allowed tools, output contract, model choice, approval rules, and compaction requirements. DSH can compose many of these concerns. Output validation, budgets, and evaluation gates may still belong to plugins or the surrounding platform. In either case, DSH cannot invent the correct policy for your business.

The execution plane is where the choice lives. Build it around an SDK, or place an adapter in front of a harness such as DSH.

And the box on the right is deliberately outside both lanes. The agent can propose a refund. A domain service decides whether the user is allowed to issue one and commits the transaction. Prompts express intent; runtime controls and domain services enforce authority.

What changes when the harness becomes infrastructure

If DSH’s seams stabilize, three practical things change.

Sessions can become shared operational evidence. Today, two teams may use the same SDK while disagreeing on what a session is, when history compacts, how a failed tool call is recorded, or what “cancelled” means. A shared harness can make those semantics consistent. Its event ledger can feed a live UI, replay a failure, show which context reached the model, and supply cases for evaluation. The thing being reused is behavior over time, not just helper functions.

Agent definitions can follow their own release cadence. A support agent and a research agent can share a runtime while selecting different prompts, skills, tools, model policies, and compaction strategies. I would not accept arbitrary DSH configuration with every request. I would compile a product-owned definition into an immutable, validated deployment and run it by id. Promotion, rollback, and evaluation gates are architecture I would build around DSH; they are not capabilities I assume DSH ships for me.

Runtime coupling gets one place to live. DSH’s architecture puts model adapters behind a replaceable service, and its pinned provider guide includes DeepSeek, OpenAI, Anthropic, cloud-hosted, and custom routes. This does not make sessions automatically portable. Provider-specific reasoning and replay state, tool semantics, and capability gaps still leak through. It does give a platform team one seam at which to contain those differences, along with upgrades, conformance tests, cost controls, and common runtime policy.

That organizational shift is an architectural prediction, not a measured DSH outcome. Product teams could concentrate on context, domain tools, workflows, evaluations, trust, and user experience while a platform team owns generic execution. The trade-off is a central dependency that must be operated like a product.

My ownership ledger

For the production harness I described last month, DSH could eventually let me delete bespoke loop wiring, session reconstruction, tool-registry plumbing, context compaction, and some plugin lifecycle code. That is the attractive part of the proposal.

I would retain the product API, identity and tenant boundary, durable run admission, agent registry, immutable deployment records, a product-facing cursor/resume contract, evaluation service, and every domain tool. I would also retain an adapter that translates product commands and runtime events without exposing DSH’s native schema to every caller. That adapter could be a small local module or subprocess client; it does not require a shared network service.

I would never delegate business authorization, source-of-truth data, or transactional invariants to a prompt or a general-purpose harness. The runtime may restrict which tool the agent can call. The service behind that tool must still decide whether the action is legal for this user, in this state, now.

Would I migrate today? No. I would run a pinned DSH pilot beside the current implementation and make it earn the replacement. That is a judgment about preview risk, not a rejection of the boundary.

There are two decisions, not one

The original “SDK or DSH?” question combines two independent axes.

The execution substrate determines which runtime semantics you adopt and which you build. The deployment topology determines whether that runtime is embedded, isolated in another process, or operated as a shared service.

An SDK does not require every application to operate its own agent. A company can put an SDK-built runtime behind a shared service. DSH does not require a separate enterprise platform. It ships Web and headless compositions, and its SDK can drive a runtime from another application.

This matters because the reasons to centralize are organizational, not merely technical. Several products may need one tool policy, one session model, one evaluation pipeline, and one cost ledger. That argues for a shared service regardless of which runtime sits inside it. One small product may need rich workspace execution but no central platform at all. That can argue for a harness without a shared service.

Choose the substrate and the topology separately.

When should you choose what?

First choose the execution substrate:

Then choose where to operate it:

A workflow engine is a separate boundary, not a competing row in either table. Use one when a deterministic or regulated process owns durable out-of-turn human work, distributed scheduling, compensation, and authoritative state; agents can perform bounded steps inside it. DSH does include durable session-local one-shot and fixed-rate schedules, but the original session must remain live. That is not a cold-session scheduler or a workflow engine with exactly-once semantics.

Choose an agent SDK when control is the product requirement

Use an SDK directly when the agent is one component inside an application, especially when it mainly calls narrow business APIs and the application already owns identity, state, deployment, and observability.

This path is strongest when the workflow is bounded and unusual. Code is a better representation than a generic configuration system when routing and stopping rules are specific to one product. It also gives the fastest access to provider-native features. If the application deliberately couples itself to one provider’s reasoning and context semantics, portability may be a distraction rather than a goal.

The cost is cumulative. Watch for the point where several teams independently add the same session persistence, compaction, tool policy, event model, approval flow, and recovery logic. At that point you are not “just using an SDK” anymore. You are funding several custom harnesses.

Choose a workspace-oriented harness when the workspace is part of state

A fuller harness becomes attractive when the recurring machinery is substantial: open-ended turns, persistent files, shell activity, skills, subagents, context compaction, approvals, replay, and several kinds of agent that should share the same runtime behavior.

DSH is not the only answer. OpenAI’s Agents SDK now has Sandbox Agents with command execution, files, packages, mounts, ports, snapshots, and resumable workspaces. Other mature coding-agent systems have their own harnesses. The decision to adopt this category should come before the product comparison inside it.

Decide separately whether DSH should be that harness

DSH is compelling when its particular design matches the system you want: Cordis plugin composition, an append-only session ledger, local or out-of-process operation, and a provider-adapter boundary you can own. The case is not that it has the longest feature list. The case is that you would otherwise design and maintain those same runtime semantics yourself.

If that match is weak, its plugin and configuration model add machinery. If the match is strong, it may let a team retire a meaningful portion of a custom harness.

Choose a shared Agent Service when reuse crosses product boundaries

The trigger for a shared service is not agent count. It is repeated governance.

If multiple applications need the same identity propagation, tool permissions, sessions, agent versions, eval gates, usage accounting, and recovery semantics, centralizing them can be worth the network boundary and platform ownership. Applications should request an approved agent and version through a stable internal API. They should not submit arbitrary plugins, prompts, or runtime configuration on every call.

Start with one or two real agents. A universal “agent operating system” designed before shared requirements exist will centralize guesses. A narrow service built around proven common needs can widen later.

What DSH does not replace

A harness can expose hooks for almost every production concern without becoming the authority for all of them.

DSH does not automatically provide:

• end-user authentication or tenant isolation;
• business authorization and source-of-truth validation;
• immutable release promotion and rollback policy;
• a durable distributed queue with worker leases and fencing;
• idempotent admission or exactly-once business side effects;
• a product-facing, cursor/resume-based durable delivery contract across worker, process, and network failure;
• durable out-of-turn human workflows, cold-session or distributed scheduling, or workflow-engine compensation;
• organization-specific retention, redaction, audit, and compliance controls.

Some of those capabilities have local implementations or plugin seams inside DSH. That is useful. It is not the same as production ownership.

The boundary test I use is failure. If a fact must survive a dead harness process, it needs an authoritative durable home outside that process. If an action can move money, delete data, or change a customer’s rights, a domain service must independently authorize it. If a control applies across tenants, deployments, and worker crashes, the platform must enforce it.

This is why I would put a company-owned contract at the runtime boundary. In a small product it can be a local module or subprocess client. In a multi-product organization it can become an Agent Service API. Either way, it preserves the decisions that should outlive a developer-preview runtime: who may run which agent version, under which limits and policy, and what durable events and artifacts come back.

The preview tax is real

The pinned official README calls DSH a developer preview and says compatibility-breaking changes will occur. The current prerelease, v0.1.1-rc.2, shipped on August 21. The npm version history moved through ten release candidates between August 10 and August 21. Ten release candidates in eleven days is evidence of churn as well as active development.

The security boundary deserves the same precision. DSH’s pinned sandbox documentation says its sandbox modes govern filesystem effects; network and process visibility are outside that vocabulary, and some platforms report partial enforcement. Its plugin publishing guide notes that package code executes outside the agent sandbox. In-process Cordis plugins should therefore be treated as trusted runtime code, not as untrusted tenant extensions. The local Web UI is not an enterprise control plane merely because it runs in a browser.

The MIT license makes evaluation easier. It is not an SLA. GitHub stars measure attention, and rapid release candidates show that the interface is moving. Production readiness is something each deployment still has to prove.

Adopt it with a measured pilot

I would not begin with a migration. I would begin with one adapter and one representative agent.

Pick a workload that exercises the reasons you care about DSH: a long session, real tool calls, compaction, a workspace, a restart, an approval, and at least one failure path. Run it beside the existing SDK implementation. Pin the DSH version and the complete agent definition. Then compare:

• output quality and reproducibility;
• context fidelity after compaction;
• replay and crash recovery;
• latency and model/tool cost;
• tool-policy and approval enforcement;
• engineering effort for one real feature change;
• operational complexity and failure isolation;
• upgrade stability, portability, and exit cost.

The proof is not that DSH can complete the happy-path task. Every agent demo can. The proof is that adopting the harness reduces the machinery your team must own without weakening the boundaries your product requires.

If it passes, widen the adapter to a second materially different agent. That is the real reuse test. If the second agent is mostly a versioned definition — prompt, skills, tools, policy, evals — on the same runtime semantics, the architecture is paying off. If every agent needs to fork the runtime, it is not.

The boundary I would keep

DeepSeek Harness does not make agent SDKs obsolete. It makes the build-versus-adopt line visible.

Choose an SDK when you want to compose and own the execution machinery. Choose a harness when coherent workspace and runtime semantics are worth adopting, whether for one product or many. Choose a shared Agent Service when several products need the same governance — but keep business truth, security policy, and the public contract outside the harness.

The shortest version is the line I keep coming back to:

Build the agent, not the harness — unless the harness is where your product is different.

DSH’s impact is not that everyone should use it. It gives teams a concrete alternative against which to evaluate the custom middle layer they would otherwise build.