[coordination][deferred] Cross-agent delegation (delegate a goal to another instance's brain)

[serge-ivo]

DEFERRED — needs a real second consumer beyond Coder. Generalize delegate so a coordinator hands a GOAL to ANOTHER instance/agent's brain (its AgentDO), which owns execution with its own tools/memory/guardrails — the manager+workers shape for the multi-agent marketplace. Do NOT build speculatively; wait for the second consumer. Part of #154 + epic #58.

[serge-ivo]

The second consumer has arrived

This was deferred with "needs a real second consumer beyond Coder — do NOT build speculatively." That gate is now met: the requirement is configurable multi-layer supervision — a user wiring agents to oversee other agents, at arbitrary depth, as configuration rather than code.

Design: docs/supervision.md.

Rather than building this directly, it should now fall out of:

• [coordination][deferred] First-class delegate(target, goal) registry primitive #156 — generalize the delegate target from repoId to a supervisable entity (the type change that unlocks everything)
• [coordination] Supervision graph as configured platform data — hierarchy belongs to the platform, not inside an agent #183 — the supervision graph as configured data (edge table, DAG validation, reuse of the 0058 delivery outbox)
• [coordination] Autonomous work budget — bound spend across every unattended entry point #184 — delegation budget (depth + spend flowing down)
• [coordination][security] Supervision must not escalate authority — a delegation lends a goal, never privileges #185 — authority containment (a delegation lends a goal, never privileges)

Cross-agent delegation is then the natural consequence of those four, not separate work. Keeping this open as the outcome to verify against.

[serge-ivo]

Live as of 67eb915 — lib/delegate-instance.ts + POST /v1/instances/:id/delegate.

This was deferred with "needs a real second consumer — do NOT build speculatively", then gated behind #183/#184/#185. All three landed, so it is on. Each is enforced on the delegation path, not assumed:

• The configured graph decides who may drive whom. Delegating to an instance that is not your subordinate is a 403, and the workflow is never kicked. Without this the graph would be decorative and any instance could drive any other — re-creating from another direction the bypass [coordination][security] Supervision must not escalate authority — a delegation lends a goal, never privileges #185 closes.
• Depth is derived from the graph, never taken from the caller. A subordinate that could name its own depth would escape the cap by claiming 0.
• The budget is inherited; only a ROOT delegation opens a pool. One per hop is the per-path copy that makes a tree cost allowance × fanout^depth.
• The supervisor rides along only as onBehalfOf — audit, never permission. The subordinate runs on its own brain, so [coordination][security] Supervision must not escalate authority — a delegation lends a goal, never privileges #185 holds by construction.

Delegation is logged under the parent's trace, so a multi-level tree reads as one run — the join choreography normally lacks.

11 tests, including the two that matter: a non-subordinate target is refused and never starts a workflow, and depth comes from a 2-level graph rather than the request.

[serge-ivo]

Done in 67eb915, with capability routing in c9f093f and checkability in 25b3871. Proven in production: Coder Lead delegated to Repo Coder, run completed done in 1 of 2 iterations. Graph membership, derived depth, inherited budget and onBehalfOf-only authority are all enforced on the delegation path.