README.md 9.1 KB
description: "Nine tools that let the model create, message, and coordinate teammates, for compositions mounting the experimental Team plugins."
kind: "package-reference"
@deepseek-ai/dsh-experimental-tool-agent-team
English | 中文
Summary
This package lets the model create named teammates, send them messages, inspect availability, wait for progress, interrupt stuck work, and coordinate through a shared task board. Every team member receives the same nine tools and guidance for coordinating in a shared workspace. Choose it when the model should operate a team only after you explicitly request one. It replaces legacy subagent controls with the same tool names, so compositions that need both must disable the legacy definitions. The package is published under its experimental name and provides no stability guarantee.
Table of Contents
- 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 nine 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 nine tools group into four capabilities:
- Create a teammate —
spawn_teammatetakes a name, a description, and the initial task; only the Lead can call it. - Send messages —
send_messagesteers a running member at its nearest step boundary, starts an idle member, and cold-resumes an inactive teammate. - See and wait —
list_agentsshows the roster with live status;wait_agentwaits for the next team change;interrupt_agentstops a teammate's current turn (Lead only). - Manage the task board —
team_task_create,team_task_list,team_task_get, andteam_task_updateadd, 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](#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](../../../.agents/notes/implemented/feature/2026-08-05-agent-teams.md) owns the model-facing and scoping decisions. ### Source map | File | Role | |---|---| | [`src/index.ts`](src/index.ts) | Plugin entry: config, the fixed policy text, and the nine scoped tool registrations | | — | No runtime invariant companion is published; the Team service owns durable and authorization relations. | ### 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 nine tool registrations are declared in [`src/index.ts`](src/index.ts). The nine 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.agentTeamsdomain 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, Steer delivery, the no-retry mailbox rule, and the Lead's duty to wait before answering. The nine 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 public, but its schemas can change freely while it incubates.