Preface¶

DeepSeek Harness (dsh) treats models, tools, sessions, sub-agents and interfaces as replaceable plugins, officially described as “everything is a plugin”. The standard capabilities already support spawning/forking sub-agents, but a complex goal often lacks a few key elements: who will act as the team lead, the order of tasks, whether idle members can automatically take on new tasks, and whether old results will overwrite new progress after an interruption.

dsh-agent-teams fills this gap. It does not build a separate workflow engine, but turns the current session into a team lead, recruits resumable sub-agents by role, splits goals into tasks with dependencies, and connects everything using persistent mailboxes and a shared scheduler. This article is organized after cross-checking the community plugin directory, GitHub repository README, docs/usage.md and package.json, covering what it is, installation commands, usage methods and its limitations.

The community plugin directory deepseek-harness-plugin.com is an independent site and has no official affiliation with DeepSeek or Magic Square. The official discovery channel remains the GitHub dsh-plugin topic tag. The directory page facilitates searching and copying installation commands, while the actual behavior shall prevail based on the repository source code.

What it is¶

dsh-agent-teams is a workflow and automation plugin for DeepSeek Harness. Its GitHub repository is NanmiCoder/dsh-agent-teams, maintained by NanmiCoder (the author field in package.json lists developer Ajiang Relakkes). It uses the MIT license, is primarily written in TypeScript, and its npm package name is @nanmicoder/dsh-agent-teams. As of 2026-08-17, GitHub shows 421 stars; the community directory page previously listed 291 stars, so the star count on the repository shall prevail.

The problem it solves can be summarized in one sentence: When you propose a goal in natural language, the current dsh session acts as the team lead, organizing multiple resumable sub-agents into a team with task dependencies, direct messaging, and persisted state.

The repository README states that the plugin provides team protocols, 10 collaboration tools, persistent state, automatic shared task scheduling, and a real-time activity panel on the Web interface. In package.json, the client declares its platform as web, and the activity panel uses the Web UI; you need to have already installed DeepSeek Harness before using it. The Node engine requirement is ^22.19.0 || >=24. The current npm version is 0.1.6 (based on package.json).

Core features¶

Team Lead, Members, Tasks, and Mailboxes¶

The working method can be broken down into six steps according to the README:

1. The current session creates a team and becomes the team lead. One team lead can only lead one active team at a time.
2. The team lead adds members by role. Members are DSH resumable sub-agents (startContinuable), not one-off disposable child processes.
3. The goal is split into tasks with explicit assignees and dependencies.
4. The shared scheduler, based on the members’ real running / idle / ready status, atomically assigns a ready task to each idle member and wakes them up. If a task is still open after an interruption or process restart, a new attempt will be created to rerun it.
5. When a member updates a task, they must include the current attempt_id. Task reassignment or team lead takeover will first invalidate the old attempt, wait for the original member to stop working, then create a new attempt, preventing outdated old results from overwriting new progress.
6. The team lead aggregates the results, calls the termination interface to archive the entire team, rather than directly deleting the history.

The task state machine is clearly documented in docs/usage.md: pending → claimed → in_progress → completed | failed | cancelled. Tasks cannot be claimed until their dependencies are completed, and one member cannot hold two unfinished tasks at the same time.

The team state is stored in the workspace directory, and the panel reads this on-disk source of truth:

<workspace>/.agent-teams/<teamId>/
├── team.json
└── inbox/
    ├── captain.jsonl
    └── <member>.jsonl

Members send messages to each other through their respective JSONL mailboxes, directly delivering and waking up the recipient without going through the team lead for forwarding. Messages that cannot be delivered temporarily will remain in the mailbox and be delivered again when the next state boundary is reached.

10 Collaboration Tools¶

The plugin registers 10 agent_teams_* tools into ctx.tools, following the same registration path as DSH’s built-in tool-workflow. Models call them according to the protocol in the prompt section, and users usually only need to state the goal without memorizing the tool names. The responsibilities of the tools are as follows:

By default, adding members is zero-interaction: the plugin will snapshot the LLM provider, model, and thinking intensity that the team lead is actually using at this current step, and subsequent resumable runs will use this snapshot. Only when you explicitly specify “use Model X from Provider A for the backend and Model Y from Provider B for the frontend” will you pass the provider + model parameters to that member. There will be no pop-up windows for model selection one by one.

There is a easily confused naming here: the configuration item memberProvider refers to the sub-agent runtime backend (spawn / fork), not the LLM vendor. Cross-model routing is handled by the optional provider + model parameters in agent_teams_add_member.

Web Activity Panel¶

After being installed into the Web profile, creating a team will expand an activity panel (body portal overlay) in the upper right corner: team lead information, segmented progress, collapsible member tree, and interactive task DAG. The DAG uses SVG to connect dependencies, you can view upstream and downstream relationships by hovering or keyboard focusing, and clicking a node will display the assignee, unmet prerequisites and downstream unlock status. Member rows show their role, real-time status and current task, and clicking will open the sub-session for that member.

The panel only displays teams for the current session (matched by captainSessionId). The panel will collapse when you create a new session, and expand again when you switch back to the original session. When terminating a team, agent_teams_delete will archive it: members, tasks, dependency graphs and mailboxes will remain intact in archive/, and you can still view the original member tree and DAG when opening the historical session.

docs/usage.md also lists limitations: the panel polls and renders based on disk status every 1 second; sometimes a model completes a task but does not call agent_teams_update_task, at which point the panel will not “automatically” mark the task as complete, and the team lead should use agent_teams_status and the files on disk as the source of truth.

Installation and Activation¶

The installation command given on the community directory page is:

dsh plugin add github:NanmiCoder/dsh-agent-teams

For reproducible installations, the directory page requires pinning a specific commit:

dsh plugin add github:NanmiCoder/dsh-agent-teams#<commit>

Replace <commit> with the full commit hash from the repository, do not use floating branch names for version locking.

The repository README, targeted at the Web interface, documents npm package installation (note the profile):

dsh plugin --profile web add @nanmicoder/dsh-agent-teams

The activity panel depends on the Web UI. If you only install it into the default profile without enabling the web profile, the tool protocol may still be registered, but the README verification steps require checking the Web configuration and starting the Web server:

dsh --profile web --dump-config
dsh web

To install from source code (when modifying the plugin or tracking the latest commits):

git clone https://github.com/NanmiCoder/dsh-agent-teams.git
cd dsh-agent-teams
pnpm install
pnpm build
dsh plugin --profile web add .

You need to run pnpm build again after modifying the source code. Local installation will create a symlink to the current checked-out directory.

Both the directory page and the repository remind users that the plugin runs with the permissions of the current dsh process and may execute code during installation. Before installing, you should read the source code and the MIT license, and confirm that the repository is indeed NanmiCoder/dsh-agent-teams.

Typical Usage¶

After installing and restarting the Web interface, you do not need to write YAML manually. The example from the README uses natural language directly:

Use AgentTeams to review commits after v0.5.3, divide the work from performance, security and product perspectives respectively, and finally output a consolidated report.

Following the protocol, the model will: create a team → recruit members by role → split tasks and declare dependencies → the scheduler assigns tasks to idle members and wakes them up → the team lead monitors progress, reassigns or takes over tasks when blocked → aggregates results and calls agent_teams_delete to archive the team.

You can keep the default configuration unchanged. If you want to override member behavior in a trusted profile, the repository provides an example written in cordis.patch.yml:

- id: agent-teams
  config:
    stateDir: .agent-teams
    memberProvider: spawn
    memberModel: deepseek-v4
    memberMaxDepth: 1
    maxMembers: 8

The meanings are as per the documentation:
- stateDir: The name of the state directory under the workspace, default is .agent-teams
- memberProvider: spawn or fork, not the LLM provider name
- memberModel: Default model for all members; takes effect preferentially if a member has its own provider/model specified
- memberMaxDepth: Reassignment depth for members, 0 means prohibition of further reassignment
- maxMembers: Maximum number of team members, the example uses 8

The priority of生效顺序 is: explicit provider + model for the member → memberModel → the team lead’s current routing. The thinking intensity inherits the team lead’s by default; if the target provider/model is incompatible, member creation will fail instead of silently downgrading. The final effective provider, model, and thinking intensity will be written to team.json for querying and cold recovery.

For more detailed tool parameters, UI behavior and verification steps, see the repository’s docs/usage.md. The same repository also includes an Agent Skill dsh-plugin-development for plugin development, which is separate from team orchestration, and should be viewed separately when you need to write DSH plugins.

Applicable Scenarios and Notes¶

It is more suitable for work where the goal can be divided by role, there are sequential dependencies between steps, and you want the process to be observable, resumable and archivable. The official example itself is a multi-perspective code review and summary. Members are resumable sub-agents, suitable for tasks that cannot be completed in one round and need to be awakened again with context retained.

The documentation also lists scenarios that are not suitable, do not skip them:
- One team lead can only have one active team at a time. To start a new team, first terminate and archive the current one.
- Scheduling is event-driven, not resident polling. The team lead cannot perform cold recovery for members when offline; tasks and messages will remain on disk and be delivered again after the team lead comes back or calls the status tool.
- State is persisted at the file level, with file locks for serialization within the same dsh process; simultaneous modifications to the same team by multiple processes are not guaranteed to be consistent.
- Member personas will replace the default persona, but members still retain the full toolset including bash, file system, internet access, etc., with the same permissions as the team lead’s process.
- The activity panel reflects the disk truth; if the model forgets to call the update tool, the task status on the interface may remain in the old state.
- The plugin runs with the permissions of the current dsh process. Check the source code, license and repository address before installing; for production or shared workspaces, it is recommended to pin the version with #<commit>.

docs/usage.md also mentions that there was a rename of service keys in the beta version: the npm latest version (0.0.1-rc.1) used ctx.httpServer / ctx.workspace, while the subsequent next version (rc.2) changed them to ctx.webServer / ctx.workspaceRegistry. The plugin detects both sets of keys, prioritizing the new keys and falling back to the old ones. If the panel route is not mounted, first check the DSH version and confirm that the plugin is actually installed into the web profile via --dump-config.

Summary¶

dsh-agent-teams packages DSH’s existing sub-agent capabilities into an observable team: the team lead is in the current session, members are resumable, tasks have dependencies, messages go through mailboxes, state is written to .agent-teams/, and you can view the DAG and progress on the Web. It is not an “official plugin” in the official app store, but a MIT-licensed community project maintained by NanmiCoder; the directory page only handles收录 and provides installation commands.

Community directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-agent-teams/

GitHub repository: https://github.com/NanmiCoder/dsh-agent-teams