dsh-agent-teams: a captain-and-members plugin for DeepSeek Harness

The problem dsh-agent-teams solves inside a single DSH session

A single DeepSeek Harness session is one conversation with one model context. When a goal has three independent angles, such as a performance review, a security review and a product review of the same commit range, the usual answer is to run three prompts and merge the output by hand. The README frames the plugin as the alternative: the current session becomes a captain that assembles sub-agents, splits the goal into tasks with owners and dependencies, and consolidates the result. The audience is therefore narrow and specific. You must already run DeepSeek Harness, because the plugin is installed as a Harness plugin into a profile, and its members are described as continuable DSH sub-agents. This is not a general multi-agent framework that you can point at any model endpoint. The README's own example prompt asks the team to review commits after v0.5.3 from performance, security and product perspectives and return one consolidated report, which is the shape of work the project targets: a bounded goal with parallel perspectives and a single deliverable.

Captain, members, mailbox and the shared task scheduler

The mechanism is a protocol the captain follows from its system instructions rather than a separate engine. According to the README, the captain continues an existing team and calls agent_teams_status when it needs current state; when no team exists, the goal is staged as a plan for review. Members are continuable sub-agents, so an idle member can be woken for a focused follow-up turn instead of being recreated. Tasks carry owners and explicit dependencies and move through states the README names as running, idle and ready, and the shared scheduler claims a task atomically from that real state. The dependency rule is the part worth noting: a task cannot be claimed before its dependencies finish. Reassignment revokes stale attempts before new work starts, and cold recovery retries stranded open attempts. Messaging is direct, through durable mailbox messages to teammates or the captain, with no relay. The plugin ships 13 coordination tools and persistent state, and the Web UI combines segmented progress, a collapsible roster and an interactive task DAG. Running tasks display the member's model, and completed archives retain member and task history.

Plan before execution, and why Approve and Run is a gate

A normal /agent-teams run does not spawn members immediately. The README states that it stages an unspawned roster and DAG first, and that the Web panel uses the host model catalog for member routes. Returning to chat stops the planning turn, asks what should change, and revises the same draft. Discarding archives the draft, aborts the turn and explicitly prevents automatic recreation. Only Approve and Run enables scheduling, at which point each member starts with its first ready task. This is a deliberate cost control: nothing is spent on sub-agent turns until a human has looked at the roster and the dependency graph. The trade-off is friction. If you wanted the team to form and start working from a single sentence, this design makes you confirm a plan first, and the README does not describe a configuration switch that skips the staging step.

Installing the plugin into a Harness profile

The README gives a two-step install and a version pairing. First install DeepSeek Harness globally at the recommended version, then add the plugin into a profile. The README notes that Harness itself remains a prerelease and that the recommended pair is Harness 0.1.5-rc.1 with AgentTeams 0.1.17.

npm install --global @deepseek-ai/dsh@0.1.5-rc.1
dsh --version

The version check should print the installed Harness version. Then install the plugin into the web profile, replacing the profile name if yours differs. The exact-version form pins the plugin rather than following the npm latest tag.

dsh plugin --profile web add --save-exact @nanmicoder/dsh-agent-teams@0.1.17

After installation the README instructs you to stop and restart Harness for that profile, then refresh the browser. Two constraints are easy to miss. Installing the plugin does not upgrade the host, so the Harness version you already have is the one you keep. Desktop users must check the app's embedded Harness core, because upgrading the global CLI does not upgrade it. The repository's package.json requires Node ^22.19.0 or >=24. Once the panel is live, the README's first real use is a natural-language request, for example asking the team to review commits after a tag from several perspectives and return one consolidated report.

Quality gates are opt-in, and scope control is an audit

The README describes opt-in quality tasks supporting a requirements, implementation, verification, review and integration contract chain, with automatic repair and re-review and an explicit resume path. The limitation is stated plainly in the same row: scope control is a completion-time audit, not host write interception. That means the plugin does not sit between a member and the filesystem to block an out-of-scope edit while it happens. It evaluates scope when the work is reported complete. If your concern is preventing a sub-agent from touching the wrong path in the first place, this is the wrong layer, and the README points to docs/quality-gates.md for the details rather than claiming enforcement. Quality gates are also opt-in, so a default run does not get the contract chain at all.

What the README does not settle

Several things a reader would want are absent from the README. There is no documented rollback procedure for a partially completed team run, and no documented command for tearing down a team and releasing its members. The README covers discarding a staged plan before execution, which is a different operation. Cost behaviour is also unquantified: the README says members are continuable sub-agents and that the scheduler claims ready tasks, but it gives no figure for how many host turns a typical team consumes, and no token or latency numbers appear anywhere in the README. The compatibility matrix lives in compatibility.json and the maintenance guide, not in the README body, so version support has to be read from those files. Finally, the plugin's own repository is a JavaScript and TypeScript package with a client bundle, and the README does not describe what happens to persisted team state when you uninstall the plugin or move to a different profile.

How this differs from Claude Code subagents and agent teams

The closest comparison a reader will reach for is Claude Code's subagents and agent teams, and the difference is architectural rather than cosmetic. Claude Code's subagents are a feature of that host, configured and invoked within it. dsh-agent-teams is a plugin that installs into a DeepSeek Harness profile through the dsh plugin command, so it inherits the host's model catalog for member routes and its locale service for the UI. The coordination primitives are the visible difference: an explicit task DAG where a task cannot be claimed before its dependencies finish, atomic claiming from running, idle and ready state, mailbox messaging between members, and a staged plan that requires Approve and Run before any member spawns. A generic orchestrator library such as LangGraph or CrewAI takes the opposite approach: you write the graph or the crew in code and run it as your own process, with no host session and no Web panel. That is more portable and more work. If you are not on DSH, dsh-agent-teams is not an option at all.

Editorial conclusion

Adopt dsh-agent-teams if you already run DeepSeek Harness and want one session to split a goal across durable sub-agents with explicit task dependencies and a Web UI you can watch. Skip it if you are not on DSH, or if you want a standalone orchestrator that runs outside the host: the plugin installs into a Harness profile and its scheduling depends on the host. Before committing, verify that your Harness build is the recommended 0.1.5-rc.1 pair, confirm that the profile you install into is the one you actually launch, and check docs/quality-gates.md if you intend to rely on the opt-in quality tasks, since the README states that scope control is a completion-time audit rather than host write interception.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NanmiCoder/dsh-agent-teams on GitHub
4. README
5. Releases