Parallel Work Without Losing Ownership

Grok Build's parallel-work problem is not merely how to start more processes. It is how to let child sessions, background commands, monitors, and recurring jobs continue without losing track of who started them, which prompt they belong to, who may cancel them, and where their results should appear. This chapter follows those lifecycles so readers can distinguish useful concurrency from uncontrolled fan-out.

The safety model from the previous chapter makes this distinction necessary. A permission decision belongs to a request, while a sandbox belongs to a process. Once several processes and sessions are alive, those boundaries need owners. Otherwise a child completion can appear in the wrong conversation, a cancellation can reach unrelated work, or a deleted session can leave a task running with no responsible recipient.

A child session is a lifecycle, not a thread

When Grok Build starts a subagent, the request enters a coordinator rather than immediately becoming an untracked asynchronous task. The coordinator is a single-writer actor. It owns pending, queued, active, and completed child records, as well as wake messages, cancellation, foreground deadlines, and teardown state. Host-specific runners execute the child, but the coordinator remains the place where admission and lifecycle decisions are serialized.

That arrangement gives concurrency a shape. A spawn request begins as a request that may be admitted immediately or held in a queue when the relevant limit is full. Once started, it becomes an active child with a parent session, a child session identity, and lineage information. When the runner finishes, the coordinator terminalizes the result, publishes it to the appropriate waiter or parent, records a completed entry, and starts another queued child if capacity permits. The states are not labels for a dashboard; they determine which operations are legal at each moment.

stateDiagram-v2 [*] --> REQUESTED: spawn request REQUESTED --> QUEUED: admission waits REQUESTED --> ACTIVE: capacity available QUEUED --> ACTIVE: slot opens ACTIVE --> BACKGROUNDED: caller leaves or budget expires ACTIVE --> COMPLETION: child finishes BACKGROUNDED --> COMPLETION: result published ACTIVE --> CANCELLED: parent or client cancels QUEUED --> CANCELLED: admission cancelled CANCELLED --> DRAINED: teardown settles COMPLETION --> REPARENTED: surviving work changes owner COMPLETION --> REMOVED: result delivered or evicted REPARENTED --> ACTIVE: work continues under new owner REPARENTED --> DRAINED: owner teardown COMPLETION --> REMOVED DRAINED --> REMOVED REMOVED --> [*]

The coordinator also keeps scope narrow. A child request carries a parent session and often a parent prompt. Queries, cancellation, wakeups, and completion surfacing can be checked against that lineage. A parent can cancel its own children without turning an unbound request into a wildcard that cancels every child in a shared coordinator. A child cannot widen its own reach merely because it knows another session exists.

This matters when a model delegates work that changes files.