runtime-orchestrator-boundary

To separate workflow state from runtime execution, classify features by state persistence: route turn-scoped, DAG-internal parallelism to the runtime layer, and route workflow-level parallelism with persistent state transitions to the orchestrator layer.

The boundary is defined by state lifetime: the runtime handles short-lived, turn-scoped execution steps, while the orchestrator manages workflow-lifetime state transitions, approvals, and worker spawning that persist across multiple turns.

Persistent workflow state in the runtime causes reliability bugs because the runtime is designed for transient, turn-scoped execution and cannot safely manage cross-turn state transitions, retry loops, or snapshot and restore operations required for workflow recovery.

You need workflow orchestration safety guardrails when implementing retry and repair loops, worker spawning, or approval pauses, ensuring these persistent state transitions and commit ordering checks remain managed by the orchestrator, not the runtime.

Worker spawning belongs in the orchestrator if the workers manage workflow-lifetime state and persist across turns, while transient tool parallel execution stays in the runtime, as determined by the state lifetime classification rule.

Runtime-level parallelism is limited to turn-scoped, DAG-internal execution and cannot safely handle workflow-level state migration, notebook commits, or snapshot and restore operations, which must be enforced in the orchestrator to prevent boundary violations.