Blog · Guide

DeepSeek Harness subagent: multi-agent patterns without leaving dsh

August 14, 2026 · dshbase

DeepSeek Harness is, at its core, a single-agent loop. But a harness that can only ever run one brain gets cramped fast, and the official repo's discussions — plus a wave of community plugins — have been quietly filling in the multi-agent story. The result isn't a rigid "spawn a subagent" API so much as a toolkit of presets, forks, and message channels that compose together. Here's how the pieces actually fit, verified against dsh 0.1.0-rc.6 and the plugins that ship today.

Why dsh has no single "spawn" command

A word on expectations. If you come from a framework with a built-in spawn_subagent(), dsh will feel different — and deliberately so. The kernel is a plugin system, not an orchestration runtime, so multi-agent behavior is assembled from primitives rather than exposed as one blessed API. The upside is that the primitives are genuinely composable: the same fork mechanism that powers a throwaway side chat also underlies the messaging handoff, and the same preset mechanism that defines a data agent can define any other role you invent. The downside is that nothing is handed to you pre-wired — you assemble the pieces, which is why the patterns below matter more than any single plugin.

Agent presets: subagents by role

The cleanest entry point is the preset. Rather than a single monolithic assistant, dsh lets a plugin declare a distinct agent role with its own tools and instructions. The concrete example in the plugin directory is dsh-data-agent, which "defines a dedicated Data Agent preset that lets AI query, update, and analyze data for you." You don't bolt data skills onto your coding agent — you get a second, purpose-built agent and switch into it when the task is data-shaped. That's the subagent idea in its simplest form: specialization via presets, not one bloated persona.

Fork-based side conversations

For lightweight parallel work, dsh-sidechain is the plugin to know. It adds /side for persistent side chats and /btw for one-off side questions, both of which "run in a temporary fork without writing to the main session history." That matters for two reasons: the main session's append-only log stays clean (so your trajectory stays auditable), and the fork inherits the parent's context so the side task can see where you left off. It's the closest thing to a native "spawn a subagent for this small thing" affordance we verified — git-build status on dsh 0.1.0-rc.6, i.e. it builds from source rather than npm.

Cross-session and cross-instance messaging

Once you have more than one agent, they need to talk. Two plugins cover the two scales:

dsh-crosstalk — "any session on the machine can list and message any other, Claude Code-style." Local, same-machine fan-out.
dsh-interconnect — "cross-instance message and event handoff" via an interconnect service plus tools. This is the one that reaches across processes and machines.

Together they turn a fleet of dsh instances into something that can delegate and report back — a supervisor sending work to workers, workers posting results, all without copy-pasting between browser tabs.

Shared memory across agents

Messaging moves tasks between agents; memory keeps them coherent. dsh-sgme is the bridge that gives "multi-agent shared long-term memory via HTTP." If each subagent only remembers its own session, you lose context at every handoff. With a shared SGME-backed store, what agent A learns is queryable by agent B. It's still early (low stars), but it verified ok on dsh 0.1.0-rc.6 and is the only memory plugin aimed squarely at the multi-agent case.

Model switching: the other "multi" lever

Subagents aren't only about how many agents — they're also about which model each one runs. dsh's model picker is provider-agnostic by design, so the natural multi-agent pattern is a cheap/fast model for routing and a strong model for the deep work, switched per session or per task. Because models in dsh are first-class and swappable (the picker is a core feature, not a plugin), a "subagent" can mean "same harness, different model" just as much as "same model, different role." Combine this with presets and you get a practical division of labor: a routing agent on a small model, a data agent on a mid model, and a coding agent on the biggest one.

Putting it together

There's no single command that gives you a fully-fledged subagent system yet — the pieces are still community-grown and uneven. But the pattern is already workable on dsh 0.1.0-rc.6:

Define roles with presets (dsh-data-agent).
Run throwaway parallel work in forks (dsh-sidechain).
Wire agents together with messaging (dsh-crosstalk locally, dsh-interconnect across instances).
Give them shared memory (dsh-sgme) and per-role models.

None of this requires forking the core — it's all plugins on the Cordis kernel, which is exactly why it appeared so fast. For the current, test-verified lineup of these and related plugins (with install commands), start at the plugin directory.

All articles →