DeepSeek recently released DeepSeek Harness, an open-source agent harness built around a simple idea: everything is a plugin. It is currently in developer preview and is MIT licensed.[1]
The easiest way to understand it is:
DeepSeek Harness is closer to an open-source version of something like Claude Code than to a traditional agent SDK.
But what exactly does a harness do?
The model is not the agent
When you use a coding agent such as Claude Code, the language model itself is not directly running commands on your computer.
The model is deciding what should happen next.
Something else has to turn those decisions into actions.
For example, you might tell the agent:
"Fix the failing tests."
The model might decide to run pytest.
Something on your computer has to actually start that process, capture its output, provide that output back to the model, let the model inspect files, make changes, and continue the task.
That surrounding system is the harness.
DeepSeek describes the relationship simply as:
Agent = Model + Harness.
The model is the reasoning component. The harness gives it an environment, tools, state, and a mechanism for continuing to work.[2]
That distinction is important because a model by itself is largely just generating responses. The harness is what turns those responses into an agent that can operate in a real environment.
So what does DeepSeek Harness actually provide?
This is where DeepSeek Harness becomes interesting.
A harness is not just an agent loop.
The runtime can provide things such as:
- Model adapters
- Tool registration and execution
- Sessions
- Persistent storage
- Shell and filesystem access
- Sandboxing
- Scheduling
- Agent loops
- UI components
DeepSeek explicitly lists models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI as plugin-based capabilities.[2]
So rather than building all of this infrastructure around a model yourself, you get a runtime designed to host agents.
A simplified mental model looks like this:
Your application
│
▼
DeepSeek Harness Runtime
│
┌───────────────┼────────────────┐
▼ ▼ ▼
Model Agent Loop Tools
│
┌────────┴────────┐
▼ ▼
Shell Filesystem
│
▼
SandboxThe important part is that these pieces are not meant to be one giant hard-coded system.
They are plugins.
What does "everything is a plugin" actually mean?
This is more than a marketing phrase.
DeepSeek Harness is built on Cordis, where plugins contribute services, typed events, and effects to a shared context. The architecture documentation says that the model adapter, tool registry, session log, and agent loop are all plugins, meaning they can be replaced through configuration.[3]
That changes the architecture considerably.
In a traditional application, the agent loop might look something like:
while not finished:
call_model()
execute_tools()
update_state()The loop is part of your application.
With DeepSeek Harness, the loop itself is a component that can be replaced.
The same applies to the model adapter, tool system, session system, and other runtime capabilities.
So you can think of the harness as a collection of interchangeable runtime components rather than a single monolithic agent implementation.
The agent loop
At the center of any coding agent is still a loop.
A simplified version looks like this:
User request
↓
Build model context
↓
Call model
↓
Model produces text or tool calls
↓
Execute tools
↓
Record results
↓
Build next context
↓
Call model againWhat DeepSeek makes interesting is that the agent loop itself is configurable.
Its architecture describes agents in terms of turns and steps, with the loop coordinating model calls, tool execution, events, and continuation.[3]
This matters because the loop defines how the agent behaves.
You can change when tools run, how context is assembled, how execution continues, and potentially replace the default control logic without rebuilding the entire runtime.
That is a much deeper level of customization than simply adding another tool to an agent.
Sessions are part of the runtime too
A useful agent cannot just forget everything after every model call.
It needs to know what happened previously.
DeepSeek Harness therefore treats the session log as an important runtime component. The architecture makes the session log itself replaceable, rather than treating history as an implementation detail buried inside the application.[3]
This becomes important for things like:
Resume: continue a session later.
Replay: reconstruct what happened.
Forking: branch from an earlier state.
Telemetry: inspect the agent's execution.
This is one of the differences between a simple model wrapper and a real agent runtime.
The runtime is responsible for maintaining the environment in which the agent continues operating.
How is this different from the OpenAI Agents SDK?
The OpenAI Agents SDK takes a different starting point.
In the SDK, an Agent is a configured language model with instructions, tools,
and optional behavior such as guardrails, handoffs, and structured outputs. A Runner
manages turns, tools, handoffs, and sessions.[4]
For example, conceptually:
Your application
↓
Agent
↓
Runner
↓
Model + Tools + HandoffsThis makes it straightforward to create custom agents inside an existing application.
You might build:
Customer Support Agent
↓
┌───┴────┐
▼ ▼
Refund Booking
Agent AgentThe SDK gives you abstractions for defining those agents and orchestrating them. OpenAI supports both manager-style agents-as-tools and handoffs between specialized agents.[4]
DeepSeek Harness can also be used to build custom agents.
The difference is where the abstraction boundary sits.
With the Agents SDK, you are primarily building the agent and its orchestration inside your application.
With DeepSeek Harness, you are also getting a separate, composable runtime around that agent.
That runtime can own sessions, tools, storage, sandboxing, the agent loop, and other environment-level capabilities.
What about LangGraph?
LangGraph is another useful comparison, but for a different reason.
LangGraph describes itself as a low-level orchestration framework and runtime for long-running, stateful agents. Its core abstractions revolve around explicit state and graph-based execution. It provides persistence, durable execution, human-in-the-loop control, and recovery from failures.[5]
A simplified LangGraph architecture might look like:
Graph
│
┌────────┼────────┐
▼ ▼ ▼
Node A Node B Node C
│ │ │
└──── State ──────┘This is especially useful when you care about controlling the workflow itself.
For example:
Research
↓
Generate draft
↓
Human approval
↓
PublishLangGraph lets you explicitly model and persist that stateful execution. Its persistence system stores checkpoints that enable memory, human interruption, time travel, and fault-tolerant resumption.[6]
DeepSeek Harness is less about expressing your workflow as a graph and more about providing a composable agent environment.
So the difference is subtle but important.
LangGraph: How should this agent workflow execute?
DeepSeek Harness: What runtime should this agent operate inside, and which parts of that runtime should be replaceable?
The runtime is a real process
There is another technical detail that makes DeepSeek Harness especially interesting.
Its Python SDK can communicate with the Harness runtime as a separate process through a JSON-RPC protocol.
Conceptually:
Your Python application
│
│ JSON-RPC
▼
DeepSeek Harness process
│
┌──────┼─────────┐
▼ ▼ ▼
Agent Tools Session
│
▼
SandboxThis means your application does not necessarily need to contain the entire agent runtime itself.
It can act as a client that drives the runtime.
That makes the analogy to a remote control useful.
The runtime is the thing doing the work. Your application can send it instructions and consume its results.
Why does this architecture matter?
At first glance, it can seem like an unnecessary distinction.
After all, can't you just build an agent using the OpenAI Agents SDK or LangGraph?
Yes.
The basic agent loop is not particularly difficult.
What becomes difficult is everything around it.
You need to deal with:
- Persistent sessions
- Tool execution
- Real terminals
- Filesystem access
- Sandboxes
- State recovery
- Logging
- Context management
- Long-running execution
- Approvals
- Process isolation
And all the edge cases that appear when an AI agent starts interacting with the real world.
That is what a harness is really solving.
It provides the environment in which the agent exists.
A better mental model
The easiest way to compare these systems is to ask what abstraction you are starting from.
OpenAI Agents SDK
You start with an application and define agents inside it.
LangGraph
You start with a workflow and explicitly control stateful agent execution.
DeepSeek Harness
You start with an agent runtime and compose the pieces that runtime is made from.
None of these approaches is universally better.
They optimize for different levels of control.
If you are adding an agent to an existing product, an SDK can be exactly what you want.
If you need explicit stateful orchestration and complex workflows, LangGraph is designed for that.
If you want to build or modify the runtime that an agent itself runs inside, DeepSeek Harness is a particularly interesting approach.
And that is why calling DeepSeek Harness simply "another agent SDK" misses the main idea.
The interesting part isn't that it lets you build an agent.
It's that it lets you customize the machinery that turns a model into an agent.