dsh-experimental-tool-agent-team gives the model a team toolset on top of the team domain package: create named teammates, send them messages or follow-up work, see who is available, wait for progress, interrupt a stuck teammate, and manage a shared task board — ten tools in total. A short policy section in every member's prompt teaches the model when to form a team (only when you ask for one) and how to coordinate on a shared workspace. Mounting it replaces legacy subagent controls with the same tool names, so a composition that wants both must disable the legacy definitions. It is experimental: excluded from official releases, carries no stability promise, and creates teammates only when you explicitly ask for a team.

Use this package
Understand the implementation
Further Exploration
Model Experience
Known Limitations and Deferred Work
Dev Note

Use this package

Add this package on top of @deepseek-ai/dsh-experimental-agent-team when the model should run a team through tools. Once mounted, every team member — the Lead and each teammate — gets the same ten tools plus a policy paragraph that states its own role and name.

When to choose it

Choose it when the model should create and coordinate teammates by itself rather than a human driving subagent controls. Avoid it when the legacy global subagent tools with the same names must stay available: the team tools replace them for team members, so a composition that wants both must disable the legacy definitions. The fixed policy creates teammates only when you explicitly ask for a team or teammates, so ordinary tasks never trigger delegation on their own.

Smallest working example

The smallest addition to an existing composition is the two-package fragment from the agent-team README: durable session storage, the team domain package, and this package. The plugin itself takes two optional settings:

- id: tool-agent-team
  name: '@deepseek-ai/dsh-experimental-tool-agent-team'
  config:
    freshProvider: spawn
    forkProvider: fork

Field	Default	Meaning
`freshProvider`	`spawn`	Provider that starts fresh teammates
`forkProvider`	`fork`	Provider that starts fork teammates

The generated configuration catalog is the exhaustive source for every accepted field and its JSDoc.

Try it by asking the Lead model: "create a teammate named reviewer to check the diff, then send reviewer the change summary". The model calls the creation tool and then the messaging tool.

What the model can do

The ten tools group into four capabilities:

Create a teammate — spawn_teammate takes a name, a description, and the initial task; only the Lead can call it.
Send messages — send_message delivers information without waking an idle teammate; followup_task makes the message the recipient's next turn and wakes it when needed.
See and wait — list_agents shows the roster with live status; wait_agent waits for the next team change; interrupt_agent stops a teammate's current turn (Lead only).
Manage the task board — team_task_create, team_task_list, team_task_get, and team_task_update add, browse, read, and update shared tasks.

Any member can message any other member and use the task board; only the Lead creates and interrupts teammates. Task updates keep the domain's owner and revision checks, so an outdated edit is rejected instead of overwriting newer work.

What success and failure look like

Sending a message succeeds as soon as it is safely stored: the result is accepted (delivered now) or queued (waiting), and a queued message must not be resent. wait_agent returns noProgress right away when no other member is running or provisioning, telling the caller to wake a teammate first; otherwise it waits for the next change and the caller re-reads state afterward. Task edits based on an outdated revision are rejected rather than overwriting newer work.

Understand the implementation

Implementation internals — click to expand

This section explains the design decisions behind the adapter and points at the code that realizes them; the observable behavior is fully covered in Use this package.

Design philosophy

The adapter is built on three commitments:

Scoped, not global. Every registration lives on the member Agent's own ctx; nothing is installed for non-Team subagents or the host.
Declared results, compact JSON. Every tool declares its complete result schema and renders that value as compact JSON, so the compiler checks execute against what the model is promised and no result spends tokens on indentation.
The domain owns authority. Tools delegate to ctx.agentTeams, which enforces Lead authority and revision checks; the adapter adds no weaker path.

The Agent Teams Agent Note owns the model-facing and scoping decisions.

Source map

File	Role
`src/index.ts`	Plugin entry: config, the fixed policy text, and the ten scoped tool registrations
`src/invariant.ts`	Invariant companion (no runtime invariant; delegation is observable only through `ctx.agentTeams`)

Policy and tools

One team:policy section on the member scope teaches each member its role and the coordination rules; the fixed text and the ten tool registrations are declared in src/index.ts. The ten tool schemas appear only in Team member scopes, so non-Team subagents keep the default catalog. Scoped registrations with the same names as the legacy global continuable-subagent controls shadow those globals for team members only.

Scoped registration and teardown

maybeInstall runs for every live Agent and subscribes to agent/created; it skips Agents without Team membership. Disposal of an Agent runs the installed disposer, and plugin HMR disposes every installed scope before reinstall. Each disposer unwinds registrations in reverse order, so a failed install cannot leave a partial scope.

Further Exploration

Read these pages when the package-level contract is not enough. They move from the domain service to the exact schemas and the decisions behind the design.

agent-team package — the ctx.agentTeams domain service behind these tools.
Agent Teams subsystem — durable Team types and service API.
Generated tool catalog — every tool schema the model receives.
Agent Teams Agent Note — model-facing, scoping, and isolation decisions.

Model Experience

Team policy and tools

What the model sees

One stable policy section states the exact Team role/name/id, the explicit-delegation requirement, shared-cwd behavior, filesystem stale-version recovery, Bash/formatter/codegen risk, task and write-scope coordination, quiet versus waking delivery, the no-retry mailbox rule, and the Lead's duty to wait before answering. The ten Team schemas from spawn_teammate through team_task_update appear only in Team member scopes.

Token effect

Fixed policy and schema cost on every Team member request. Tool calls add compact JSON roster, task, wait, or receipt results. Peer content is retained by the Team domain in the target's history.

KV Cache effect

Prefix-stable while the Team plugin generation, configuration, member role/name, and schemas remain unchanged. The per-member identity line differs across Agents. Tool results and peer messages append after the reusable request prefix.

Known Limitations and Deferred Work

These limits describe what the policy and tools cannot guarantee for a team. They are current package constraints, not a comparison with other collaboration surfaces.

Prompt policy is coordination, not confinement — it cannot stop Bash or external processes from writing overlapping files.
No autonomous team creation — ordinary tasks do not trigger delegation unless the user explicitly requests it.
No Web controls — browser roster and task-board presentation is outside this runtime package.
Experimental prototype with no stability promise — the package is private, excluded from official releases, and its schemas change freely while it incubates.

Dev Note

Working context for maintainers — click to expand

None.

README.md

@deepseek-ai/dsh-experimental-tool-agent-team

Summary

Table of Contents