Task Delegation

Style: Mode-B-lite. Role-aware subtask delegation without weakening Fusebase Flow ownership, verification, or role boundaries.

Purpose

Coordinate bounded work across multiple agents when the host environment supports subagents. Delegation is a speed tool, not an authority transfer: the self-attested main role remains accountable for scope, integration, verification, and final reporting.

When to invoke

Route first: an explicit absence/unattended instruction ("I'm stepping out", "run this unattended", "I'll be away", "complete it end to end while I'm away") is the /step-out command — hooks/local/fusebase-flow-overlays/commands/step-out.md; read it BEFORE assessing delegation eligibility below, then return here. Ordinary attended work, planning-only/read-only requests, and "complete end to end" without an absence instruction are not /step-out.

• Operator explicitly asks for delegation, subagents, parallel agents, or parallel work.
• AI Developer has independent implementation/test slices with disjoint write scopes.
• Product Owner needs read-only investigation, option comparison, or artifact review that can run in parallel.
• Architect escalation needs independent read-only probes over distinct subsystems.

Do not invoke when

• The task is simple enough to finish directly.
• The next critical-path step depends on the subtask result; do that locally.
• The subtask itself needs an operator interaction or decision while it runs. A decision pending for other work does not block dispatching independent slices outside a Product Owner session (§ Pending operator answers).
• The work touches deploy commands, production side effects, approval artifacts, secrets, or live-user credentials.
• Product Owner would be delegating production code edits.
• Write scopes overlap or cannot be clearly owned.
• The host has no subagent/delegation tool; use normal docs/tmp/handoff/ Flow instead.

Required inputs

Procedure

1. Decide whether delegation is allowed

If the requested delegation is forbidden, refuse under role-discipline and offer a compliant alternative.

2. Keep the critical path local

Before spawning any subtask, name the immediate local action. Delegate only sidecar work that can progress while the main session continues non-overlapping work. Do not delegate the task that blocks your next action.

3. Write a delegation brief

Every delegated task gets a brief with:

For code-edit subtasks, tell the worker: "You are not alone in the codebase. Do not revert or overwrite other concurrent edits; adapt to them."

Turn-completion rule (every delegated session — binding): a delegated session's deliverable must be COMPLETE within its turn. A delegated session cannot self-resume: when its turn ends, its context dies and nothing comes back. If the work requires waiting (ticks, agent runs, external processes), either poll INSIDE the turn with bounded check loops of at most 4 min each until the result exists (a sub-agent's cache lives 5 min, so one longer sleep re-writes its whole context — token-economy TE-20; wait with a bounded check loop such as timeout 230 bash -c 'until <check>; do sleep 15; done' — never a bare leading sleep N, which Claude Code blocks — and set the tool timeout above the loop's bound), or restructure the task as record-then-read (flow-skills/smoke-testing § Verification cost discipline). NEVER end the turn with "running in background — I'll resume when it completes" — you won't, and the orchestrator may trust the false completion.

Progress ledger (every delegated session — binding): write durable facts into the artifacts you already owe AS THEY OCCUR — the deploy hash the moment the deploy lands, probe/evidence rows as each one runs, the report skeleton first and rows as earned — never everything-at-the-end. Sessions die mid-work (provider limits, machine restarts); end-loaded reporting loses everything that wasn't yet written. Successor contract: a successor session resumes from records — read the ledger first, resume from the last durable fact, never redo verified steps; the delegating prompt for a successor states this explicitly (verify-from-records). Successor state (the delegator writes it; ≤10 lines, on top of the successor's §3 brief and push blocks): ledger path + recorded HEAD; done tasks with SHAs (or the tasks.md pointer); the one next step; open questions and parked items with their clearing conditions; commands still in flight (command · PID or output path · bound). Everything else is a pointer to the ledger — never a transcript tail.

Delegated-session liveness (zero-trust — binding on the DELEGATOR): after dispatch, watch the delegate's PROGRESS — new commits / advancing SHA, process activity, output-file byte growth — event-driven (a bounded watcher, the default where your host can wake you) or at most every 4 min (liveness-discipline § Wake interval); never passively await a completion ping. A missing ping is evidence of neither completion nor death; only observed progress (or its absence past the expected interval) decides. A delegate that dies on a transient provider rate-limit is a dispatch failure, not the slice's verdict — never record it as FAILED-<reason> or BLOCKED-AT-<gate>, because the work was never attempted. Re-dispatch a minimal "try again" to the SAME agent id (it keeps its context — do not respawn, do not re-send the brief); if it reports the limit again, retry only inside the bounded delegate-retry envelope — max 3 attempts / 5 minutes total, labeled ~60s → ~90s → ~120s backoff, one progress read per interval (canonical: flow-skills/liveness-discipline § Bounded delegate-retry envelope) — then judge the work on what it produced. On exhaustion of either bound: STOP retrying, read the progress ledger, re-brief a successor with verify-from-records, or return BLOCKED-AT-delegate-no-start — never FAILED-<reason>. This is a discipline, not a gate — a hang is invisible from inside, so it is watched from outside (the watcher above); Flow ships no blocking check and no "watchdog applied" attestation hook for it (FR-27). Protocol home: flow-skills/liveness-discipline § Zero-trust sub-agent liveness.

Blocked-return rule: when the remaining wait is UNBOUNDED (human approval gate, external event with no bounded ETA) — which neither in-turn polling nor record-then-read can span — the prescribed return is an explicit BLOCKED-AT-<gate> verdict + what cleared looks like + a pointer to where reality is recorded, so the orchestrator re-dispatches when the gate clears. Never fake-complete; never burn an open watch on an unbounded wait.

Delegation contract push block — inline this in every delegating prompt (push, not pull; workers do not load skills):

Your deliverable must be COMPLETE within this turn — you cannot self-resume; poll in-turn with bounded check loops of at most 4 min each (cache TTL; never a bare leading sleep) or read durable records, never end with "I'll resume when…". Write durable facts into your owed artifacts AS THEY OCCUR (skeleton first, rows as earned), never everything-at-the-end. If you hit an unbounded wait (human gate, no-ETA event), return BLOCKED-AT-<gate> + a pointer to where reality is recorded. Return per the delegated return shape: verdict · SHAs · deltas · artifact pointers · context (compacted yes/no + tool uses this run) — never re-paste a body an artifact already holds; state-change claims cite the ground-truth check performed (surface read + what it showed). Chat-return budget: ≤80 lines and ≤6,000 characters. Longer → write a sanctioned durable artifact and return its path; commit only when the owning workflow requires it.

No inherited auto-load. A delegated sub-agent session does not inherit the orchestrator's auto-loaded skills or the always-on FR-24 digest — session_start does not fire for it. The anti-reread exemption in communication / role-discipline therefore does not apply to a worker. Canonical worker boot: the delegating prompt inlines the FR-24 digest and the push blocks below; a code-edit worker also reads FLOW_RULES.md (to ## Amendment log) and references/ai-developer.md (§3 Inputs); a read-only worker reads only what its brief names. Never tell a worker "the skill is already loaded"; never have it re-read a file whose full text is already in its context.

Mandatory (code-writing / implementation slices): the delegating prompt MUST inline the comment-policy Delegation push block from flow-skills/comment-policy/SKILL.md (push, not pull — sub-agents do not reliably auto-load skills, so don't just tell the worker to "load comment-policy"). Read-only / triage delegation is exempt (no code is written).

For frontend/design subtasks, add:

For test-only UI automation subtasks, add:

4. Parallelize only independent slices

Use parallel delegation only when all are true:

• Each subtask has a distinct write set or is read-only.
• Results can be integrated in any order.
• Failure of one subtask will not corrupt another subtask's work.
• The main session can do useful non-overlapping work while subtasks run.

5. Integrate, verify, and report

The main session must:

1. Read each returned result.
2. Inspect changed files or evidence before trusting the result.
3. Resolve conflicts without reverting unrelated user or subagent changes.
4. Run the relevant verification gate commands.
5. Record delegated work in the gate/deploy report when it affected implementation or evidence.

Delegated return shape

For delegated returns only — gate reports keep PASS/FAIL; spec Status values remain DRAFT/DONE/BLOCKED (or ABORTED after an investigated no-work outcome), while scope-lock is recorded only as decisions.md Lock status: LOCKED, never Status: LOCKED.

Return budget (binding): ≤80 lines and ≤6,000 characters. Longer → write a sanctioned durable artifact and return its path; commit only when the owning workflow requires it. Both limits bind together — one 32,000-character line satisfies a line-only cap and still costs the orchestrator the full read. A read-only PO/Architect delegate and a concurrent investigation write to docs/tmp/ (or the artifact the owning workflow names) without committing.

Exempt from the budget (AC13): the canonical gate report (templates/gate-report.md, contracted at templates/handoff-implement.md § Gate report contract) and the canonical deploy report (templates/deploy-report.md, contracted at templates/handoff-deploy.md § Deploy report contract). Evidence completeness outranks the cap at the gate — never truncate a gate or deploy report to fit.

Ground-truth rule: any claim that system state changed (launched / registered / deployed / completed) names the verification performed — the system surface read and what it showed. An attempted action or an observed look-alike artifact is not evidence; a false "launched" built from those can survive for hours.

Subagent output is evidence, not proof. Fusebase Flow success still requires the normal gate, smoke, security, and deploy checks.

Model routing

Per-project selection lives in policies/model-routing.yml (optional; per-machine override policies/model-routing.local.yml). A tier selects a MODEL, never authority — role boundaries (§1), approval artifacts, credential handling and deploy ownership are unchanged by any tier, and an execution-tier agent gets no deploy or approval rights from its row (FR-12).

Fallback (binding). An absent, malformed, unavailable or unsupported selector produces a RECORDED fallback — continue on the available host model, sequentially if necessary. Never stop a run for model configuration, never assume an unverified model mapping, never promise per-agent effort (effort is session-level). When no independent agent is reachable, the review still runs and is reported as a same-family review; if no independent pass is possible at all, report that limitation instead of claiming independence. Record the resolved model when the host exposes it, otherwise resolution unavailable.

Escalation. Escalate a tier pre-emptively only where the plan marks the slice HIGH risk; otherwise only after an attempt has actually failed, within the host's real capabilities and the existing retry bounds (liveness-discipline).

Agent tool reach

A Flow agent's tools: line is Flow's (agents/<name>/AGENT.md). Never edit its mirror .claude/agents/<name>.md: preflight reports the drift, and recovery preserves the edit and exits partial.

When a task's required input needs a tool the Flow agent lacks, add it to the project's tool profile, policies/agent-tools.yml. The profile is project-owned: Flow never ships, upgrades or restores it. It is protected (policies/*.yml), so the operator approves the exact tool list in chat and the commit uses a single-use approval.

schema_version: 1
agents:
  ai-developer:
    add_tools: [mcp__<server>__<tool>]

bash hooks/local/mirror-agents.sh generates .claude/agents/<name>-project.md: the Flow body, the Flow tools: list plus the profile's tools, and a generated marker. The Flow mirror stays a byte copy. Upgrade, post-fusebase-update.sh and mirror-agents.sh regenerate the variant, and remove it when its profile entry goes. Preflight reports a missing, stale or hand-edited variant; a hand edit is preserved, never overwritten. Commit the profile and the variant together.

Dispatch <name>-project only for tasks whose Inputs: need a profile tool; every other task keeps the lighter <name>. The variant is the same role: <name>-project counts as <name> for every role, gate and agent-type rule.

Profiles only add tools: never AskUserQuestion (FR-19), never Agent/Task, named MCP tools only. A tool is reach, never authority: role boundaries, approvals and gates are unchanged (FR-12). Flow's hooks do not inspect MCP tool calls, so list only the tools the inputs need. Reach is not connection: the MCP server must be configured and signed in for the session.

Reserved agent names: every Flow agent name, its -project variant, and the FuseBase CLI agents (known_names in hooks/local/fusebase-flow-overlays/agent-surface-ownership.json). Any other .claude/agents/<name>.md is the project's own file; Flow never writes, restores or flags it. If such an agent works as a Flow role, its body says "Read and follow agents/<role>/AGENT.md before working." — never a copied body, which stops receiving Flow updates.

An input no reachable agent can read is a question (FR-11) or BLOCKED-AT-input naming the input and the missing tool — never a fallback that builds without it; PENDING states belong to verification only (smoke-testing). Codex and other hosts without per-agent tool lists (.codex/agents/ is operator-referenced; no variant is generated there): guidance only — confirm the session itself can read the input.

Correction ownership

Generalizes the same-agent, context-preserving reuse the provider-limit path already requires (§3) to corrections, bounded by context size:

• A fix to a worker's OWN diff goes back to that worker while its context is small: fewer than 50 tool uses summed across its runs and no compaction, both read from the Context field of its returns (§ Delegated return shape; on Claude Code the completion notice's <tool_uses> is authoritative for the count; <subagent_tokens> is not a context measure). A return without the Context field counts as past the bound. When the Context field is present but there is no reliable tool-use count (including hosts with no usage notice), return a worker's own correction only within the one task group its brief gave it, with no compaction or demonstrated context drift; anything beyond that group goes to a fresh successor. Past the count bound, or when the task is unrelated or that context has demonstrably drifted, brief a fresh successor with the findings + ledger pointers; it resumes verify-from-records (§3 successor contract). Resuming a large idle worker re-writes its whole context (token-economy TE-09, TE-19).
• One correction owner per review round, batched by file. Never one agent per finding.
• Disjoint write ownership (§4) and one independently reversible outcome per commit still bind: batching findings never merges unrelated outcomes.
• Verify an external API/SDK shape once, record it where the plan lives, and cite it afterwards. Re-verify what this change touches or what a changed dependency invalidates — not merely what was edited (token-economy).

Pending operator answers

Applies in every mode, attended or /step-out, to any session that hands out work — never to a Product Owner session, where Operator Relay step 4 still halts until explicit approval (role-discipline shared-protocols § Operator Relay Protocol). It changes SCHEDULING only; it opens no gate and grants no authorization.

• A pending answer parks the gated action and its dependents (delegate side: §3 Blocked-return rule). Waiting means not executing that action: independent authorized work is compatible with the Operator Gate Protocol; executing the pending action, or anything presented under it, is not.
• Before the turn ends, dispatch the already-authorized independent slices. A turn that ends with delegates in flight leaves a bounded watcher running (liveness-discipline § Wake interval); where no watcher is possible, poll in-turn and ask at the end.
• The question is the turn's last content block, above the state footer, in chat text (FR-19).
• One open task per tree. A code-writing session with an uncommitted task starts no other task in that tree (FR-03, IM.4).

Unattended scheduling

Applies while /step-out is the active mode (hooks/local/fusebase-flow-overlays/commands/step-out.md). It changes SCHEDULING only; it opens no gate and grants no authorization.

• Dispatch return parameter: brief each worker to ≤29 lines in an unattended run — tighter than, and inside, the § Delegated return shape budget (≤80 lines AND ≤6,000 characters). The gate-report and deploy-report exemptions are unchanged: never truncate those to fit.
• Retry, review-round or gate-round exhaustion is a scheduling event. Once the bounded delegate-retry envelope is spent (liveness-discipline), do not wait and do not sleep — record the state, dispatch the next INDEPENDENT authorized slice, and return to the parked one when its clearing condition is met. An exhausted round bound (code-review § Round bound; gate re-checks: workflows/verification-gate.md § Gate failure response) parks that change WITH its findings for the operator's budget or scope decision; an unattended run never closes it out.
• A blocked slice does not stop the run. An unmet gate, missing authorization, or unresolved product question parks that slice AND its dependents, with the exact question, evidence, options and clearing condition recorded. Every other independent authorized slice continues.
• Cross-slice checks wait for every slice they cover. The verification gate, a phase-wide review and phase-audit depend on every slice in their scope: dispatch none of them while one of those slices is not DONE; a parked slice parks them with it (an early gate only fails — workflows/verification-gate.md step 2 needs a SHA for every task). A per-change review of a DONE slice proceeds.
• Unfinished work keeps its own brief. Re-dispatch a slice's unfinished or parked tasks as that slice — a fresh successor with the slice's full §3 brief, verify-from-records — never appended to another slice's worker, which owns only its own slice (§3 Ownership, §4, § Correction ownership).
• Persist only what an owner already owes. A planner or reviewer writes a full file only where documentation-budget and that artifact's owner require one; otherwise it returns the header plus pointers.

Output artifacts

Failure cases

Escalation path

• If the work cannot be made independent, run it serially in the main session.
• If Product Owner needs implementation work, draft or amend the AI Developer handoff.
• If a delegated result contradicts locked decisions, stop and return to Product Owner.
• If repeated delegation failures occur, add a problem-catalog entry and tighten task boundaries.

Anti-patterns

• Do not delegate because the task feels large; delegate because slices are independent.
• Do not delegate read-only searches that a quick rg can answer locally.
• Do not delegate vague work like "fix the feature" without file ownership.
• Do not delegate vague testing like "check the UI"; define the exact route, user flow, locators, data, auth plan, diagnostics, and evidence.
• Do not run multiple agents against the same files at the same time.
• Do not treat subagent output as final without main-session verification.
• Do not delegate frontend work with only a file path; include the product identity, surface map, data contract, selector strategy, stack conventions if applicable, and trust-critical flows.
• Do not delegate deploy commands, rollback, approval artifacts, or secret handling.
• Do not read a hook denial or a refused mint as "record it and proceed under the grant": a grant (chat or /step-out) is evidence of the conversation, not an approval artifact, so that slice returns BLOCKED-AT-<gate>. The owning-role main session still mints when the operator's chat authorization names that specific action under that role's signal (role-discipline § Operator Gate Protocol); a worker never mints. A fusebase deploy approval minted with --command '<exact command>' authorizes only that text in this repository (command_only_v1) — that is its environment scope; it does not bind the deployed content — and stays valid for identical reruns until expiry (policies/approval-policy.yml § WHAT A VALID VERDICT GRANTS); a gated git push (git_push_v1) also binds the pushed commits, so a new commit needs a new approval. Before the signal, present what the environment name resolves to (environments/<name>.json: backend, org, protected), whether the deploy provisions isolated stores or runs with --skip-store-provision, and that the approval covers every rerun of that exact command, whatever tree is present, until expiry (DP.1: an action not presented is not covered).
• Do not use popup / clickable menu tools to coordinate delegation decisions; ask in chat text per FR-19.
• Do not turn a delegate's provider-limit death into a task verdict, and do not respawn a fresh agent for it — re-dispatch "try again" to the same agent id, retrying only inside the bounded delegate-retry envelope (max 3 attempts / 5 min; liveness-discipline) — never unbounded.
• Do not passively background-and-wait on a delegate, and do not add a blocking gate or a "watchdog applied" attestation hook to compensate — poll progress instead (FR-27: watch from outside — liveness-discipline § Wake interval).

Clean-room note

Original Fusebase Flow content. Derived from operator-provided capability requirements and generalized into repo-local workflow discipline; no third-party code, prompts, skill files, or hook scripts are copied. See docs/source-map.md.