DeepSeek Harness Agent Teams: Teammates, Tasks & Mailboxes

Agent Teams is an experimental, opt-in DeepSeek Harness subsystem for coordinating persistent child agents. It gives a lead session a named roster, a shared task board and durable peer messages. Official experimental packages are available from npm starting with v0.1.5-alpha.2, while bundled Profiles keep the feature disabled by default.

Source: official Agent Teams subsystem documentation

Agent Teams versus ordinary subagents

An ordinary subagent is primarily a delegated run: the parent starts work, receives the result and may never address that worker again. A Team member has a stable name and child Session identity, can receive later messages and can own tasks recorded in the Team log.

The durable model

The Team is identified by the root Lead Session. It does not need a separate creation event. Durable state begins when the first member, message or task event is appended.

• Roster: immutable teammate names and lifecycle state.
• Mailbox: queued peer messages that survive immediate delivery failure.
• Task board: tasks with dependencies and compare-and-set ownership updates.
• Replay: the Lead Session event log reconstructs the Team state.

This follows the broader Harness invariant that model-visible facts must be logged and replayable.

Install it in v0.1.5-alpha.2

Start with a Profile that contains @deepseek-ai/dsh-base, then add the official experimental Team Profile explicitly:

dsh plugin --profile headless add @deepseek-ai/dsh-experimental-agent-team-profile
dsh --profile headless "Use Agent Teams to split this task between two teammates, wait, and summarize."

The Profile composes the Team domain, Team-scoped tools, and their UI/runtime dependencies while retaining one-shot subagent and subagent_fork. Bundled CLI, Web, SDK, ACP, and Python Profiles do not enable it automatically.

Pin every experimental package to the DSH Runtime version. Package names, patches, and configuration can continue to change, so upgrades should follow the README attached to the installed tag.

Current limitations

1. The roster is flat. It is a Lead plus direct teammates, not an arbitrary organization tree.
2. Only the Team Lead creates or interrupts teammates.
3. Names are immutable and not reused after a failed provision.
4. Members may share one checkout. Parallel shell commands, generators and external writers can still collide even when file-edit tools detect stale content.
5. Team tools are deliberately opt-in so simple sessions keep a smaller tool catalog.
6. The subsystem remains excluded from normal stable-release expectations.

When it is useful

Agent Teams fits work where named roles must continue across several turns: a researcher and verifier, implementation and QA, or a modeling role and paper-writing role. It is excessive for a small task whose result can be produced by one bounded subagent call.

The safest pattern is to give teammates disjoint responsibilities and preferably disjoint output paths. The Lead should integrate results and wait for required work before answering.

Persistent organizations are a different problem

A long-lived company-like directory—members remembered across unrelated root sessions, routed by accumulated domain knowledge—is not the same as Agent Teams. The current experimental design is rooted in one live Lead Session and optimized for coordinated work, not a permanent organization spanning projects.

FAQ

Is Agent Teams an official stable DSH feature?

It is official source code and documentation, but the packages are experimental, opt-in and not a stable default feature.

Is it the same as a community agent-team plugin?

No. Several community projects use similar names. Check the repository owner, package name and composition before comparing behavior.

Does it prevent teammates from overwriting each other's files?

No. The shared task board coordinates intent, not every filesystem writer. Separate output paths or worktrees remain important.