Blog · Guide
DeepSeek Harness subagent on rc.8: multi-agent without leaving the harness
August 20, 2026 · dshbase · aligned to 0.1.0-rc.8
DeepSeek Harness is still, at its core, a single-agent loop — but 0.1.0-rc.8 made the multi-agent story much louder: Claude Code and Codex show up as subagent / worker options in community coverage, and the plugin directory already has verified bridges and role presets to match. The result is not one blessed spawn_subagent() API so much as presets, forks, message channels, and external-agent bridges that compose. Below is what actually fits together, with install boundaries called out.
Why dsh still has no single “spawn” command
If you come from a framework with a built-in spawn API, dsh will feel different — deliberately. The kernel is a plugin system, not an orchestration runtime, so multi-agent behavior is assembled from primitives. The same fork that powers a throwaway side chat also underlies messaging handoffs; the same preset that defines a data agent can define a Claude Code–shaped worker. Nothing is handed to you pre-wired — you assemble the pieces.
Claude Code / Codex as subagents (rc.8 framing)
rc.8 coverage often says you can treat Claude Code and Codex as subagents. In practice that means one of three shapes — pick explicitly, don’t mix the marketing labels:
- Role presets inside dsh — dsh-plugin-product-subagents ships role-based Codex / Claude Code / ACP subagent presets (verified). You stay in the harness; the “Claude/Codex” part is the persona + tool policy, not necessarily a second binary.
- Dispatch from Claude Code / Codex into dsh — dsh-crew lets Claude Code / Codex push work to DSH agents (progress, in-host workers, tier presets). The inverse bridge dsh-plugin-cc embeds DSH into Claude Code for review and delegation. DeepSeek-Harness-Skill is the skill-side “send this task to DSH” entry for Codex/Claude.
- Config / CLI bridges — dsh-plugin-claude-bridge pulls Claude Code memory, skills, and config into DSH; dsh-codex-bridge exposes Codex CLI host tools and a web conversation tab. These are migration / interoperability seams, not magic shared memory.
Install & boundary notes: each bridge needs its own credentials (Anthropic / OpenAI / ChatGPT OAuth — whatever that plugin documents). Keep workspace permission levels honest (read-only vs full access) when an external agent can write files. Prefer verified directory pages for install commands; a high-star pending plugin is not the same as a clean-profile pass. For model-aware child calls inside dsh itself, see dsh-delegate.
Agent presets: subagents by role
The cleanest in-harness entry is still the preset. dsh-data-agent defines a dedicated Data Agent that queries, updates, and analyzes data. You don’t bolt every skill onto one coding persona — you switch into a purpose-built agent when the task is data-shaped. Product-subagents extends the same idea toward Claude/Codex-shaped roles.
Fork-based side conversations
For lightweight parallel work, dsh-sidechain adds /side (persistent) and /btw (one-off) chats that “run in a temporary fork without writing to the main session history.” The main append-only log stays auditable; the fork inherits parent context. Verified in the directory (often git-build rather than npm).
Cross-session and cross-instance messaging
- dsh-crosstalk — any session on the machine can list and message any other, Claude Code-style.
- dsh-interconnect — cross-instance message and event handoff via an interconnect service plus tools.
Together they turn a fleet of dsh instances into something that can delegate and report back without copy-pasting between tabs.
Shared memory across agents
dsh-sgme bridges “multi-agent shared long-term memory via HTTP.” Messaging moves tasks; shared memory keeps handoffs coherent. Still early (low stars) but verified — and still the clearest multi-agent memory slot in the directory.
Model switching: the other “multi” lever
A “subagent” can mean same harness, different model: cheap/fast for routing, stronger for deep work, switched per session or per task. Combine with presets (and with Claude/Codex bridges when you truly need another runtime) and you get a practical division of labor without pretending everything is one spawn API.
Putting it together on rc.8
- Need Claude/Codex-shaped workers inside dsh → dsh-plugin-product-subagents (+ optional dsh-delegate).
- Need Claude Code / Codex to dispatch into dsh → dsh-crew / DeepSeek-Harness-Skill / dsh-plugin-cc.
- Need throwaway parallel work → dsh-sidechain forks.
- Need agents to talk → dsh-crosstalk (local) / dsh-interconnect (cross-instance).
- Need shared memory → dsh-sgme.
All of the above are Cordis plugins (or skills) on the kernel — which is why the multi-agent story moved so fast between rc.6 write-ups and rc.8. For install commands and current verified status, start at the plugin directory.