feat(subagent): sibling delegations are concurrency-safe

One assistant message carrying several subagent calls now overlaps them
under the rolling pool (maxParallelToolCalls) instead of serializing each
foreground delegation behind an exclusive barrier; results still commit
in model order.

tool-subagent declares isConcurrencySafe: () => true for every call form:
children work in their own sessions, a run never mutates the parent
session, and sibling workspace coordination already belongs to the model
for background, continuable, and workflow children. The former
serial-execution pin flips to a parallel pin plus a gated genuine-overlap
test, and the authored subagent-parallel snapshot pins the assembled
transcript (tool/call, tool/call, tool/result, tool/result) with
interchangeable twin children, which replay race-free under the existing
first-call binding and createdAt harvest ordering.

The provider seam now requires concurrent starts and continuable
preparations for distinct children to isolate operation-local state,
cancellation, settlement, and cleanup; a continuable gate test proves a
cancelled preparation leaves no Agent or durable Session while its
sibling persists independently.

Closes deepseek-harness/deepseek-harness#1489
This commit is contained in:
Hypatia May
2026-08-11 11:54:21 +08:00
parent 6d3cabf295
commit a26d03960a
25 changed files with 325 additions and 25 deletions

View File

@@ -29,7 +29,7 @@ With `run_in_background: true`, `backgroundMode` selects the route. `one-shot` r
## Concurrency
Foreground and background calls are exclusive. Children may share the parent's workspace or external resources, and a unary classifier cannot prove that sibling delegations have disjoint effects. See the [parallel tool-call Agent Note](../../../.agents/notes/implemented/feature/2026-07-10-parallel-tool-call-execution.md).
Foreground and background calls are concurrency-safe: sibling delegations in one assistant message overlap under the loop's rolling pool (`maxParallelToolCalls`), and results still commit in model order. Children work in their own sessions and a run never mutates the parent session; the one-shot background form's one parent-owned write — registering a Task — is a synchronous, commutative insertion that tolerates concurrent dispatch, so overlapping background calls acquire their task ids in dispatch-race order. Coordinating sibling workspace effects belongs to the model, exactly as it already does for background and continuable children. See the [parallel subagent Agent Note](../../../.agents/notes/implemented/feature/2026-08-09-parallel-subagent-delegations.md) and the [parallel tool-call Agent Note](../../../.agents/notes/implemented/feature/2026-07-10-parallel-tool-call-execution.md).
## Model Experience