Over the past year, the word “Agent” has been worn thin. Claude Code helps you edit code, OpenCode takes over the terminal, and OpenClaw strings together the tools on your computer into a personal assistant—these products solve “today’s task.”
But DeepSeek Harness (DSH) asks a different question: If you do not want to use someone else’s agent, but want to build your own, what do you actually need?
My answer: you need a composable, auditable, and extensible agent chassis. Not a ready-made hammer, but a machine tool that can be forged.
Why “chassis” and “product” are not the same thing
Claude Code is powerful. It stitches together the terminal, file system, LLM, and a fairly clever planning layer, and it works out of the box for coding tasks. But it is Anthropic’s finished product: the model is chosen by them, the workflow is chosen by them, and the extension mechanism is chosen by them. You can attach custom tools at certain boundaries, but you are essentially living in someone else’s building.
OpenCode and OpenClaw take a different path. The former is more open, the latter more personalized, but they are still agents with a specific form—they assume you know what you want to do, and then help you finish it.
DSH is different. It is not an agent with a concrete form, but a skeleton that lets models safely operate on the external world. It does not provide “best-practice workflows”; it provides:
- How models are plugged in (adapter seams)
- How tools are registered and executed (tool pipelines)
- How dangerous operations are gated (approval and sandboxing)
- How context is persisted and recovered (event logs)
- How the whole system is recomposed at runtime (plugins and Cordis)
None of these is exciting on its own, but together they answer a genuinely important question: What should an agent operating system look like?
Composable: no privileged kernel, everything is a plugin
DSH’s bottom-layer bet is Cordis, a plugin framework that emphasizes “reversible side effects.” In plain language: when a plugin is mounted, it registers its capabilities into a shared context; when it is unmounted, those registrations are automatically revoked.
This leads to a structural consequence: DSH has no “core,” only layers of plugins.
The default model adapter, file-system tools, approval policy, web UI, even the agent loop itself—all are plugins. Want to swap the approval policy? Write a plugin to replace ctx.approval. Want to add a custom tool? Call ctx.tools.register(). Want to migrate the entire file system to an E2B cloud sandbox? Replace the implementations of ctx.fs and ctx.subprocess, and tools like Bash, PTY, and LSP automatically move to the cloud with it—because they consume seams, not concrete providers.
This stands in sharp contrast to Claude Code’s closed architecture. Claude Code excels by taking one path to the extreme; DSH excels by returning power to the builder. You can assemble DSH into a Claude Code replacement, or into something completely different.
Auditable: the event log is the single source of truth
DSH has a design iron law: If the model can see it, it has been recorded. Anything that enters a model request must be reconstructible from the session log.
This looks like an implementation detail, but it is an architectural choice. Because all state is derived from the event stream:
- Fork: copy a prefix of the log.
- Crash recovery: replay events.
- Context compression: insert summary checkpoints into the log.
- Debugging: read the JSONL log directly.
- Audit: everything leaves a trace.
Claude Code and OpenCode also have logs and checkpoints, of course, but those are product features. DSH places the log at a deeper level: it is the source of system correctness, not just a record for post-mortems.
For systems that need long-running execution, multi-agent collaboration, or explainability, this is a more reliable foundation.
Extensible: agents can modify their own runtime
DSH’s extensibility has three layers:
The first layer is plugin development. You can write Cordis plugins in TypeScript to add tools, model adapters, and system-prompt fragments. This is conventional extension.
The second layer is the SDK. DSH provides Python and Node SDKs that let you start and drive a complete DSH runtime from within your own program. This means DSH can be embedded into larger systems, rather than existing only as a terminal tool.
The third layer is runtime self-extension. DSH provides tools like cordis_define / cordis_run / cordis_stop that let an agent define and mount new Cordis plugins at runtime. This is disabled by default because it is risky, but the capability is true self-reference—an agent does not merely use tools, it can change the set of capabilities available to itself.
Claude Code and OpenCode will not give you this level of freedom. They are for end users; DSH is for builders.
Security posture: fail-closed by default
The more an agent can do, the more conservative its security model needs to be. DSH’s approval seam returns only four results: allowed-once, rejected, cancelled, and unavailable. Only allowed-once permits the specific operation being asked about.
If the approval responder does not answer, throws an exception, or is misconfigured, the result is not “allowed” but unavailable—still a denial.
This differs from the default posture of many agent products: “start running first, block dangerous operations later.” DSH’s default posture is: if you do not explicitly allow it, I will not do it.
The permission design for sub-agents follows the same logic. When a sub-agent starts, its permissions are snapshotted by the parent and fixed at runtime; they cannot expand later. Delegation is not “inherit all my power and go do the work,” but “I give you this much power to finish this thing.”
What can it actually do today?
To be honest, DSH is still a developer preview. The project is not currently accepting external PRs, and the API may change as it evolves. It is not a direct Claude Code replacement today.
But it is a good fit for three kinds of people:
- Engineers who want to build their own agent infrastructure. If you need a deeply customizable agent runtime rather than an out-of-the-box product, DSH is a more worthwhile chassis to study.
- Teams that need auditable, recoverable systems. An event-log-centric design naturally supports auditing, replay, and crash recovery.
- Observers interested in AI infrastructure architecture. DSH’s design documents are high quality, and concepts like seams, scopes, and waterfall events are worth understanding.
One-sentence summary
Claude Code, OpenCode, and OpenClaw compete on the product form of agents; DSH is betting on the infrastructure layer of agents.
Its core claim is that the future of agents should not be defined by any single closed product, but by a composable, auditable, and extensible chassis—one on which anyone can assemble the agent they want.
DSH still requires builders to get their hands dirty today. But if you want to understand what the chassis of an agent should look like, it is worth a serious look.