Multi-Agent Coordination

Conclusion: This Is Not a Swarm Scheduler, but a Composition of Delegation Lifecycles

This distinction matters. Seeing a subagent call does not tell you whether the child inherits history, remains conversational, is managed as a Job, or even runs in the same process. A provider promises only its declared capabilities. Unsupported outputSchema, depth limit, tool filter, or persona requests fail before startup instead of degrading silently. MULTIAGENT-SEAM

1. The Real Topology: Providers Create Nodes; the Manager Owns Continuable Conversations

Model tools (names are configurable)
  subagent / subagent_fork
        │
        ├─ foreground ─────────→ SubagentRuntime.start(provider)
        │                            └→ provider.start() → SubagentRun
        ├─ one-shot background → Jobs → provider.start() → SubagentRun
        └─ continuable bg ─────→ ContinuationManager
                                     ├→ provider.prepareContinuable() (seed data only)
                                     ├→ Agent create / resume + inbox
                                     └→ durable Session + Activation epoch

Global controls: send_message / interrupt_agent / list_agents
Child return path: report (continuable in-process children only)

SubagentProvider.start() owns pre-publication creation for a one-shot child. After it returns a run, the holder owns result observation and disposal. For a continuable child, the provider contributes only detached data describing whether to seed parent history; the continuation manager owns identity, composition, the Agent handle, messages, cold resume, ownership, and teardown. MULTIAGENT-SEAM

2. One Tool Definition Actually Selects Three Execution Routes

“Background agent” is therefore not one state. One-shot background work is an ordinary Job; continuable background work is a conversation with a durable Session ID. Flattening both into running/done erases the most important control distinction.

3. Provider Matrix: One Seam, Six Different Isolation Boundaries

Spawn and fork are the backends that enter the local parent-child graph. External providers inherit no parent conversation; their only possible parent-derived context is the workspace cwd (ACP/SDK may instead use a configured cwd), and they return through the one-shot result seam. The ACP, Codex, Claude Code, and SDK packages are optional capabilities, not the default product surface: the Codex and Claude Code tool rows in the Standard/Code presets are explicitly disabled. MULTIAGENT-SPAWN-PROVIDERMULTIAGENT-FORK-PROVIDERMULTIAGENT-ACP-PROVIDERMULTIAGENT-SDK-PROVIDERMULTIAGENT-CODEX-PROVIDERMULTIAGENT-CLAUDE-PROVIDERMULTIAGENT-STANDARD-PRESETMULTIAGENT-CODE-PRESET

4. Spawn Versus Fork Differs in the Session Seed, Not in Whether the Child Is Independent

Both in-process forms join the exact preset generation the parent is currently running—the same plugin instances, tool registrations, and prompt sections—instead of resolving a possibly changed configuration again by preset name. MULTIAGENT-PRESET-INHERITANCE

5. Inheritance Matrix: Route, Workspace, and Capabilities Are Separate Dimensions

What does not inherit is equally important: spawn cannot see the parent transcript; fork cannot see the open Turn; one-shot approval grants do not flow down; the deployment sandbox default is not snapshotted; and a child's persona/tool filter remains in its own scope without mutating its parent or siblings. MULTIAGENT-CHILD-INHERITANCEMULTIAGENT-CHILD-COMPOSITIONMULTIAGENT-DELEGATED-POLICY

6. Recursion Budget and Authority Narrow Monotonically Along the Lineage

The tool loader defaults maxDepth to 3; provider-managed is used for external providers the parent runtime cannot constrain. The lower-level depth reads the greater of the durable header and runtime option, then adds one for the child, so a resumed child cannot masquerade as depth zero. Direct apply without a cap remains uncapped, which means “3” is a tool-configuration default, not a service-wide law. MULTIAGENT-TOOL-CONFIGMULTIAGENT-DEPTH

This is not a role-based team. There is no leader/member table or sibling direct-message path. Current authority is tree-shaped and intentionally narrow; teams, shared queues, or arbitrary Agent routing would require a new explicit protocol, not reinterpretation of parentSession as a universal ACL.

7. The One-Shot Core Contract: Provider-Owned Before Publication, Run-Holder-Owned After

validate provider + capabilities + schema + descriptor
  → provider.start()
      → unpublished setup / rollback on failure
      → publish child or external run
  → emit subagent/start
  → await run.result ──────────→ emit subagent/end
  → map stopReason / preserve partial output
  → holder runs dispose() to quiescence

The result is read from the child-owned suffix after the seed/activation boundary. completed, aborted, error, max-tokens, and refusal are not collapsed to a boolean; cancelled or truncated work can still carry partial output. One-shot subagent/end follows result settlement and may precede holder disposal; a continuable epoch's end waits for the teardown outcome. A background Job treats only completed final text as successful output, maps other reasons to killed/failed, and always disposes after settlement. MULTIAGENT-ONE-SHOT-RESULTMULTIAGENT-LIFECYCLEMULTIAGENT-RUN-SETTLEMENT

8. “Final Answer” and “Structured Result” Use Separate Commit Protocols

The canonical ordinary-output rule selects the last non-empty assistant message. If none exists, it uses accumulated text deltas; if neither exists, output is empty. Selection is independent of stop reason, so an error or max-token ending can still retain diagnostically useful partial text. MULTIAGENT-ASSISTANT-OUTPUT

This explains why external providers advertise zero capabilities: sharing a working directory does not let the parent runtime enforce their tool catalog, persona, recursion budget, or structured-result commit point.

9. A Continuable Durable Session Is Not the Same Object as a Process-Local Activation

An Activation is a residency epoch, not a durable Task. It holds the exact handle, weak ancestry, owned-child set, accepted message IDs, and one memoized disposal transaction. The child Session ID is stable; every cold-resumed residency gets a new lifecycle runId. MULTIAGENT-ACTIVATION-MODELMULTIAGENT-ACTIVATION-OWNERSHIPMULTIAGENT-LIFECYCLE

10. Inbox Acceptance Is the Authoritative Follow-up Commit; Cold Resume Does Not Reinvoke the Provider

send_message(childId)
  ├─ resident + running → enqueue in the same Agent inbox; wait behind current Turn
  ├─ resident + waiting → wake the same Agent
  └─ no Activation      → inspect durable Session
                           → authorize exact direct parent
                           → fold the child's own descriptor suffix
                           → ctx.agents.resume()
                           → enqueue in inbox

Delivery, release, and disposal for each child pass through the same ChildLock; the Agent inbox is the sole FIFO. The caller's AbortSignal owns only the work before acceptance. Once admitted, that send_message call cannot cancel the accepted Turn. MULTIAGENT-FOLLOWUP

11. Four Return Channels Exist; Reporting and Completion Are Not Synonyms

send_message returns only the accepted messageId, not the child's answer. The child-scoped report can target only its direct parent, may use wakeup or quiet scheduling, and does not end the Turn or Activation. MULTIAGENT-CONTROL-TOOLSMULTIAGENT-REPORT-TOOLMULTIAGENT-REPORT-DELIVERY

12. list_agents Is a Discovery Surface, Not a Task-Result Surface

The service merges the live Session store with optional persistence, identifies direct children/descendants through durable origin:subagent headers, then classifies mode and label through projections. Cold-read concurrency is fixed at four. A corrupt or temporarily unreadable child becomes its own corrupt/unavailable diagnostic instead of failing the whole listing. The scan does not consult the Activation manager or provider state. MULTIAGENT-LIST-SERVICEMULTIAGENT-LIST-CONCURRENCY

The model tool filters out one-shot children because send_message cannot continue them; descendant traversal can still pass through those nodes in stable pre-order. Only depth-one entries accept follow-up, while deeper entries remain ancestor-interrupt candidates. MULTIAGENT-LIST-TOOL

13. Concurrency Means “Overlap Across Children, Linearize Per Child,” Not Global Scheduling

The subagent layer has no global worker pool, fair queue, priorities, quota allocation, or result reducer. It supplies correct concurrency boundaries; the model prompt, Job layer, or a higher-order workflow still decides how many children to start, when to start them, and how to synthesize their work.

14. Interrupt Stops One Current Turn; Drain Tears Down the Whole Activation Tree

Interrupting an absent, completed, or one-shot ID is an accepted no-op; it is not a subtree kill. When local cancellation wins for an external one-shot provider, the result normalizes to aborted and the idempotent handle teardown waits for the managed process tree to exit. MULTIAGENT-INTERRUPTMULTIAGENT-OUTPROCESS-SETTLEMENT

15. Durability Comes from the Session Descriptor, Not a Resident Agent or Task Queue

Session header
  parentSession / origin=subagent / delegationDepth / seedLength / agentPreset

subagent/descriptor v2 (model-hidden, log-only)
  one-shot:    mode / provider / optional label
  continuable: mode / provider / label / agentProvider / agentModel / persona / toolFilter
  intentionally omitted: outputSchema / maxTokens / subagentDepth

Continuable creation appends a between-Turn descriptor after any fork prefix, then accepts the initial prompt. The descriptor is lossless-JSON snapshotted first; the current parser rejects unknown fields, while an unsupported version is not resumable. MULTIAGENT-DESCRIPTORMULTIAGENT-DESCRIPTOR-SEEDMULTIAGENT-DESCRIPTOR-FOLD

After process restart, the recoverable object is the child conversation and its declared composition—not the prior Activation, run handle, accepted set, or background Job. If final flush fails, the runtime still releases the graph, explicitly choosing “possibly stale resume” over “certainly deadlocked ancestor.” MULTIAGENT-FINAL-FLUSH

16. Codex Comparison: the DeepSeek Seam Sees One One-Shot Worker, While Codex May Orchestrate Subagents Internally

The repository's codex provider launches a new official codex app-server --stdio for every delegation and inherits only the parent Session cwd. It advertises zero start capabilities, has no prepareContinuable, shares no parent transcript/preset/tool scope, and returns no local Agent handle. DeepSeek Harness therefore wraps the entire Codex run as one one-shot child. Even if that Codex Turn uses its own subagents, the internal tree does not become addressable nodes in the DeepSeek continuation graph. MULTIAGENT-CODEX-PROVIDERMULTIAGENT-CODEX-RUN

The wire returns only the last final_answer, falling back to the last unphased answer when no explicit final exists; commentary and reasoning are excluded. Context-window exhaustion becomes max-tokens, while other faults pass through shared out-of-process settlement as error with possible partial output. MULTIAGENT-CODEX-RUNMULTIAGENT-CODEX-WIRE

Codex's Public Multi-Agent Contract Versus This Seam

The Codex column uses only OpenAI's public Subagents documentation, retrieved on 2026-08-13. DeepSeek is source-level at the pinned commit; this comparison makes no claim about undocumented implementation.

17. Failure Layers: The Commit Point Determines Who Owns Cleanup

The service checks capabilities before provider dispatch, out-of-process helpers normalize post-publication transport rejection into a stable result, and listing contains read damage to a single row. MULTIAGENT-RUNTIME-DISPATCHMULTIAGENT-OUTPROCESS-SETTLEMENTMULTIAGENT-LIST-SERVICE

18. Two Composition Audit Findings at the Pinned Baseline

The Codex boundary needs the same precision: the provider package is complete, while the preset supplies only a disabled model-facing entry. MULTIAGENT-CODEX-PROVIDER

19. Guarantee Matrix and Final Assessment