Delegation and workflow runtime

Core owns delegated execution, authorization, process dispatch, persistence and recovery. The bundled Sub-agent plugin owns the Delegate and Workflow tools, the workflow DAG engine, agent definitions and orchestration policy. Both a Delegate call and a workflow node use the same host dispatch rather than creating separate execution runtimes.

Owning modules

• src/subagent/dispatch.ts: the one decision between in-process execution and a runner process.
• src/subagent/pool.ts, runnerHost.ts, runner.ts and protocol.ts: runner allocation and the typed process boundary.
• src/subagent/hostRpc.ts: bounded host requests and cancellation across that boundary.
• src/brain/delegatedScope.ts and delegatedTurn.ts: durable execution scope, live policy reconstruction and the shared delegated request.
• src/brain/service/delegatedSession.ts: parent/child controls, workflow continuation and dispatch settlement.
• src/brain/service/delegatedRecovery.ts and delegatedSettlement.ts: recovery ordering and completion of child-owned work before publishing the parent's result.
• src/store/brainDelegationStore.ts: durable parent/principal-scoped delegated reads.
• plugins/subagent/lib/workflow.mjs: workflow definition, dependency handovers, orchestration journal and shared outputs.

Dispatch and failure

SubagentDispatch.send holds the same remote-call fence for either execution mode. In-process execution is used when the runner is absent or disabled. A runner that cannot start raises SubagentRunnerUnavailable, allowing this not-yet-executed turn to run in-process. A failure inside a healthy runner is reported without replaying the task or its side effects.

delegatedChannelSendOpts builds the request for both execution modes. Serializable scope travels across the boundary; policy closures, tool Sets and identity are reconstructed from that authority. Live account grants intersect the captured scope and never widen it. The captured working directory is replayed from the durable scope for later continuation, rather than inferred from the parent's current directory.

Workflow handover and recovery

A node receives short handovers from its direct dependencies, not every upstream transcript. The engine records the workflow and node execution state in its orchestration journal. Shared result artifacts have durable recipient grants, so the parent and authorized direct dependents can read the same output without a copied transcript authority.

continueWorkflowNode checks the durable parent relation before continuing. A settled answer is reused after the child's own delegated work has settled. An interrupted turn resumes through its interrupted-result context; an empty transcript requires the workflow's original task. Recovery does not launch a second node merely because its live runner was lost.

A minimal real consumer is the bundled Sub-agent plugin's WorkflowStart: it parses one DAG definition, dispatches ready nodes and forwards only their dependency handovers. Work consumes the selected model's normal account usage and runner resources. Read the plugin control and result contracts and user workflow guide for their respective audiences.