Consumer story (discovery-lab)
discovery-lab's fleet census (2026-08-12, tools/provenance.mjs topology-census): 246 supervised runs — 143 solo, 33 single-child, 30 star, 7 staged, 1 chain, max depth 1, zero graph shapes.
Leads never compose, and the arena measured why prose cannot fix it: v9b "spawn-early" (orchestration forced by instruction) lost −1.17 [−2.50, 0.00] (prereg/arena/result-v9-gen1.md).
The missing piece is a CODE surface over the lead's children: submit one program that runs a fan-out, a chain, a join, a retry loop — instead of one model turn per coordination verb.
The operator layer already has this power twice over:
runGraph (kernel): typed delegates/analyzes edges, versioned directives, fresh/resume continuity, traversal caps, the journaled edge ledger.
- personify combinators:
pipeline, fanout, loopUntil, panel, verify, widen.
The LEAD has neither. Its only composition interface is per-call spawn_agent/await_event over the coordination MCP — which is exactly the star-generating interface the census measures.
The gap, precisely
resolveSupervisorTools handlers receive SupervisorToolInvocationContext = node identity + signal — no coordination verbs (verified in installed 0.132.13 dist/index-CWnUn15M.d.ts:4230 and the 0.133.0 tarball; unchanged). A product cannot build a compose tool whose spawns cross the run's authorizers/budget/journal from the sanctioned tool seam.
runGraph cannot be called from a supervisor tool handler: AgentGraph.budget opens its OWN conserved pool with its own journal/runId, so a mid-run call would start a second, unaccounted run beside the lead's pool — breaking budget conservation and provenance identity.
- Nested driver graphs are explicitly deferred in
graph.ts ("P0 executes driver↔worker(s); nested driver graphs are P3").
What discovery-lab shipped as a workaround (tangle-network/discovery-lab@64627f05)
compose_workflow, a supervisor tool mounted via resolveSupervisorTools for the root lead: the lead submits a JS script whose only primitives (spawn/await_settled/message/harvest) are JSON-RPC clients of the run's OWN coordination MCP, reachable because the caller pins SuperviseOptions.coordination.port.
Every spawn crosses the unchanged authorizeSpawn, pool tickets, maxLiveWorkers, and journals.
It works (10/10 tests incl. an integration through the runner), but the seams make it awkward in ways only runtime can fix:
- Harness arm only. A router-brained supervisor serves no MCP (and refuses the
coordination binding), so the same tool cannot mount there.
- Root manager only. Nested managers' coordination servers sit on ephemeral ports the product cannot know; a nested lead's compose tool would misparent children onto the root's scope, so it must be depth-gated off.
- Out-of-band URL plumbing. The product must reserve a port and reconstruct the URL rather than being handed the verbs.
- A product-side script host at all. The vm/worker sandbox is accident containment, not a boundary; the composition should execute in runtime's authority domain.
Ask (either closes the gap; the first is smaller, the second is the graph-native answer)
A. Put the coordination verb surface on SupervisorToolInvocationContext — e.g. context.verbs.spawnAgent(args) / awaitEvent / steerAgent / observeAgent, the same handlers serveCoordinationMcp already binds, minus submit_result/stop. Fixes both arms and all depths; products keep authoring their own compose tools.
B. A lead-facing graph-submission verb — compose_graph (or agent-facing runGraph) mounted beside spawn_agent: the lead submits nodes+edges (the existing AgentGraph data shape), runtime executes it as a NESTED manager drawing from the caller's conserved pool, edge ledger and all. This is also the natural landing for the recorded P3 (nested driver graphs) absorption.
discovery-lab will adopt either immediately: the lab-side script engine keeps its contract and swaps its MCP client for the context verbs in one place (discovery-lab/docs/compose-workflow.md records the full verified-contract analysis and this consumer story; docs/15-adoption-decisions.md entry 2026-08-12).
Consumer story (discovery-lab)
discovery-lab's fleet census (2026-08-12,
tools/provenance.mjs topology-census): 246 supervised runs — 143 solo, 33 single-child, 30 star, 7 staged, 1 chain, max depth 1, zero graph shapes.Leads never compose, and the arena measured why prose cannot fix it: v9b "spawn-early" (orchestration forced by instruction) lost −1.17 [−2.50, 0.00] (
prereg/arena/result-v9-gen1.md).The missing piece is a CODE surface over the lead's children: submit one program that runs a fan-out, a chain, a join, a retry loop — instead of one model turn per coordination verb.
The operator layer already has this power twice over:
runGraph(kernel): typed delegates/analyzes edges, versioned directives, fresh/resume continuity, traversal caps, the journaled edge ledger.pipeline,fanout,loopUntil,panel,verify,widen.The LEAD has neither. Its only composition interface is per-call
spawn_agent/await_eventover the coordination MCP — which is exactly the star-generating interface the census measures.The gap, precisely
resolveSupervisorToolshandlers receiveSupervisorToolInvocationContext= node identity +signal— no coordination verbs (verified in installed 0.132.13dist/index-CWnUn15M.d.ts:4230and the 0.133.0 tarball; unchanged). A product cannot build a compose tool whose spawns cross the run's authorizers/budget/journal from the sanctioned tool seam.runGraphcannot be called from a supervisor tool handler:AgentGraph.budgetopens its OWN conserved pool with its own journal/runId, so a mid-run call would start a second, unaccounted run beside the lead's pool — breaking budget conservation and provenance identity.graph.ts("P0 executes driver↔worker(s); nested driver graphs are P3").What discovery-lab shipped as a workaround (tangle-network/discovery-lab@64627f05)
compose_workflow, a supervisor tool mounted viaresolveSupervisorToolsfor the root lead: the lead submits a JS script whose only primitives (spawn/await_settled/message/harvest) are JSON-RPC clients of the run's OWN coordination MCP, reachable because the caller pinsSuperviseOptions.coordination.port.Every spawn crosses the unchanged
authorizeSpawn, pool tickets,maxLiveWorkers, and journals.It works (10/10 tests incl. an integration through the runner), but the seams make it awkward in ways only runtime can fix:
coordinationbinding), so the same tool cannot mount there.Ask (either closes the gap; the first is smaller, the second is the graph-native answer)
A. Put the coordination verb surface on
SupervisorToolInvocationContext— e.g.context.verbs.spawnAgent(args)/awaitEvent/steerAgent/observeAgent, the same handlersserveCoordinationMcpalready binds, minussubmit_result/stop. Fixes both arms and all depths; products keep authoring their own compose tools.B. A lead-facing graph-submission verb —
compose_graph(or agent-facingrunGraph) mounted besidespawn_agent: the lead submits nodes+edges (the existingAgentGraphdata shape), runtime executes it as a NESTED manager drawing from the caller's conserved pool, edge ledger and all. This is also the natural landing for the recorded P3 (nested driver graphs) absorption.discovery-lab will adopt either immediately: the lab-side script engine keeps its contract and swaps its MCP client for the context verbs in one place (
discovery-lab/docs/compose-workflow.mdrecords the full verified-contract analysis and this consumer story;docs/15-adoption-decisions.mdentry 2026-08-12).