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:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user