Connect DeepSeek Harness Agent Teams to the DeepSeek API

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. It is not enabled by default and should not be presented as a stable public product feature.

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.

Composition

The implementation is split into two experimental packages: one owns the Team domain and durable semantics; the other exposes model tools and guidance. A deployment must explicitly mount both. The official documentation shows limits such as member count, task count, pending messages, message bytes and disposal timeout.

Because these packages are experimental, package names and configuration can change. Copy the exact configuration from the documentation matching your installed tag instead of pasting an old blog snippet.

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.