When Parallel Work Needs a Coordinator

Orca’s structured orchestration layer answers a different question from its parallel worktree flow: not merely “which attempt looks promising?” but “who owns this work, what depends on it, and how do we know this particular attempt settled?” This chapter explains when a prompt sent to a watched terminal is enough and when a durable Run, Task, Dispatch, worker, message, or decision gate is justified. The value is operational clarity: several agents can be active without their completion claims, questions, and resources becoming indistinguishable.

A Run gives work a durable identity

A few open worktree tabs are enough for a short experiment. The operator can create three branches, watch the sessions, compare their diffs, and decide what to review. The arrangement becomes fragile when the work continues after the operator changes focus, when one task depends on another, or when a worker needs to ask a question and report a result without relying on a person remembering which terminal was involved.

A Run is Orca’s durable namespace for that larger problem. It has a coordinator inbox and provides a home for related tasks and messages. The Run does not itself schedule workers or decide where they should run. That separation is important. A namespace can say which work belongs together without pretending that grouping is the same as execution. Placement remains a deliberate action, and the worker’s execution host and worktree remain separate parts of the record.

A Task is the work item inside the Run. It contains a specification, a title or display name, dependency information, and a lifecycle state. A task can be pending, ready, dispatched, completed, failed, or blocked. When it is created with dependencies, Orca checks that those dependencies belong to the same Run and starts the task as pending unless all required predecessors are already complete. When a dependency completes, the system can promote the task to ready as part of the same state update. The point is not that the database has a convenient status label; it is that readiness follows a recorded relationship rather than a coordinator’s memory.

Imagine a small feature split into three tasks. One worker inspects the existing request boundary. A second can implement the change only after that inspection is complete. A third prepares regression tests that depend on the chosen interface. With ordinary tabs, the coordinator might keep those relationships in a note, launch too early, or forget to notify the waiting worker. With Tasks and dependencies, “ready” has a defined reason. The system can still contain a bad specification, but it no longer has to guess whether a prerequisite was satisfied.

A Run also gives messages a meaningful audience. The orchestration layer has a coordinator inbox and message types for status, dispatch, worker completion, escalation, questions, and heartbeats. A message is not just text pasted into a terminal; it belongs to a lifecycle and can be acknowledged or replayed according to the inbox rules.