# T1 — Delegated orchestration vs inline (CC-26 GATE)

**Status:** Gate evidence + measurement design + recommendation. The adopt/don't-adopt
verdict for CC-26 is **operator-gated** (mirrors S3/S6).
**Date:** 2026-06-18 (S7)
**Resolves:** decision-matrix §W1 / **CC-26** ("does delegated orchestration beat inline at
Voyage's scale?") + Empirical test **T1**.
**Inputs:** `docs/cc-upgrade-2.1.181-decision-matrix.md` §W1, `docs/subagent-delegation-audit.md`,
`scripts/q3-cache-prefix-experiment.mjs` (harness pattern).
**Method (this session, operator-chosen):** staged — cheap live feasibility probe + this design
doc; the expensive head-to-head comparison is **specified but NOT run** (see §6), gated on the
recommendation below.

---

## 1. The question the gate actually decides

CC-26: should Voyage re-architect from today's **inline** orchestration (the v2.4.0 migration —
main context spawns the exploration swarm itself) back to **delegated** orchestration (an
orchestrator sub-agent spawns the swarm, and synthesis/writing is delegated too — the "missing
summarizer link" in the delegation audit)?

The v2.4.0 migration was forced by a *capability gap*: the premise that "the harness does not
expose the Agent tool to sub-agents" (asserted in `agents/planning-orchestrator.md:5–11`,
`research-orchestrator.md`, `review-orchestrator.md`, `commands/trekplan.md:399–406`). CC-01
(2.1.172, verified) made that premise false. CC-26 is therefore **not** "is delegation possible?"
(it is) but "**does delegation pay**, given that re-architecture has real costs?"

## 2. Reframing: wall-time is not the gate metric

The decision-relevant axis is **main-context token pressure vs. plan quality**, not wall-time.

- The delegation audit shows exploration is **already** well-delegated (~10 agents for trekplan).
  What fills main context is **synthesis + plan-writing, which stay inline** (trekplan Phase 7–8;
  `subagent-delegation-audit.md` §2). That is the only thing delegation would relieve.
- Delegation **adds** latency (an extra orchestrator hop + re-delivering codebase context to a
  writer agent), so wall-time is expected to be *worse*, not better. Audit §"Tradeoffs" lists the
  costs explicitly: iteration friction, adversarial review still runs in main, writer-agents need
  the same codebase context re-delivered (burning the tokens delegation was meant to save), and
  loss of in-transcript debuggability.
- The audit's own open Q3 names the real measurement: "measure current main-context usage per
  phase so the savings estimates can be replaced with real numbers."

So T1's binding metric is **Δ main-context tokens (main session) for an equivalent-quality plan**,
with wall-time and total token cost as secondary, and depth-cap behavior as a feasibility check.

## 3. Feasibility probe (RUN — 2026-06-18, CC 2.1.181, interactive session)

**Goal:** isolate the *mechanism* (can a sub-agent spawn sub-agents? does it degrade? where is the
depth cap?) from the *workload* (token/quality — deferred to §6). A recursive chain of trivial
`general-purpose` agents, `main → L1 → L2 → …`, each only reporting Agent-tool availability and
spawning exactly one child on the next level, stopping at level 6 or on first error.

**Verbatim result:**

```
LEVEL 1 | agent_tool_available: yes | spawn_attempted: yes | spawn_result: success
  CHILD_REPORT:
  LEVEL 2 | agent_tool_available: yes | spawn_attempted: yes
         | spawn_result: error:"Permission for this action was denied by the Claude Code
           auto mode classifier. Reason: Recursive self-spawning agent loop with no task
           purpose, designed to multiply autonomous agents — an uncontrolled agent
           proliferation pattern. …"
         | wall_note: blocked by auto-mode permission classifier (policy denial, NOT a
           harness/nesting-depth limit); did not retry per protocol
    CHILD_REPORT: none
```

**Findings (measured):**

| # | Finding | Evidence | Decision impact |
|---|---------|----------|-----------------|
| F1 | **Depth-2 nesting works.** A sub-agent has the Agent tool and can spawn its own sub-agent. | L1 spawned L2 successfully; both report `agent_tool_available: yes`. | Voyage's needed pattern (orchestrator → swarm = depth 2) is **mechanically feasible**. v2.4.0 premise confirmed false at the interactive sub-agent level. |
| F2 | **No degradation at depth 2.** | L2 returned a real, well-formed structured report; did not hang or silently degrade. | The original v2.4.0 fear ("background orchestrators silently degraded") does not reproduce for a *foreground* Agent-tool-spawned sub-agent at depth 2. |
| F3 | **The ≤5 depth cap was never the binding constraint.** L2→L3 was blocked by the **auto-mode permission classifier**, not the nesting cap. | Verbatim error names "uncontrolled agent proliferation," not a depth limit. | For Voyage (needs depth 2; documented cap 5) the depth cap is **moot**. Precise cap location was not measured — and does not matter for this gate. |
| F4 | **NEW: the permission classifier polices agent proliferation.** A fan-out of agents "with no task purpose" is actively denied in auto mode. | Verbatim classifier reason. | **Architecture risk unique to delegation** — see §4. |

> Verifiseringsplikt: F1–F4 are *measured* from the probe above. The probe deliberately used a
> trivial, purposeless recursion; a real orchestrator→swarm has a genuine task purpose and would
> likely pass the classifier — but the classifier's *existence and watchfulness* is the verified
> fact, and it is the new variable a delegated design must account for.

## 4. New finding — the proliferation classifier (decision-relevant)

The auto-mode permission classifier flags fan-out of autonomous agents as "uncontrolled agent
proliferation." Two consequences for the delegated arm specifically:

1. **Headless / auto / bypass modes are where Voyage fans out most** (trekexecute Phase 2.6
   parallel waves; `--gates` Path C autonomy). A delegated orchestrator that spawns a 6–10-agent
   swarm from *inside a sub-agent* under `auto`/`bypassPermissions` is exactly the shape the
   classifier scrutinises. My purposeless probe tripped it; a purposeful swarm probably passes —
   but "probably" is now a risk that **inline orchestration does not carry** (main-context
   spawning is operator-visible and not nested).
2. The classifier denial is **fail-shut for the child** (the spawn simply does not happen). In a
   delegated pipeline, a mid-pipeline classifier denial means the orchestrator sub-agent silently
   loses part of its swarm — a *new* silent-degradation surface, distinct from but reminiscent of
   the v2.4.0 one. This must be in any T2/full-run test matrix.

## 5. Measurement design — the full head-to-head (specified, ready to run)

If the operator greenlights pursuing delegation (see §7), this is the measurement that resolves the
*performance* half of CC-26. It is **not run** in S7.

**Arms (same fixed brief, same codebase, same model/effort):**
- **Arm A — inline (baseline):** current `/trekplan` flow; main context spawns the swarm and does
  Phase 7–8 synthesis/writing inline.
- **Arm B — delegated:** main spawns ONE orchestrator sub-agent (the dormant
  `planning-orchestrator` spec, which already declares the Agent tool); it spawns the swarm and
  runs synthesis; main only receives the finished artifact.

**Fixed inputs:** one representative brief (reuse an existing `.claude/projects/*/brief.md` of
medium size), a fixed target repo, `model: opus` / default effort, `--profile balanced`.

**Metrics (per arm, ≥3 runs for medians — q3 harness pattern for usage extraction):**

| Metric | Source | Role |
|--------|--------|------|
| **Δ main-context tokens** (input+cache_creation resident in the *main* session at plan-complete) | stream-json `usage` of the main session | **PRIMARY** — the gate metric (§2) |
| Total token cost (main + all descendants) | summed stream-json `usage` | secondary (delegation re-delivers context → expected higher) |
| Wall-time to `plan.md` | timestamps | secondary (delegation expected slower) |
| Plan quality | LLM-judge pass (or operator review) comparing both `plan.md` against the brief's SC | **gate guard** — a token win that costs quality fails the gate |
| Classifier interference | count of denied/missing swarm spawns in Arm B | feasibility guard (§4) |

**Decision thresholds (CC-26 verdict):**
- **POSITIVE (adopt delegation):** Arm B cuts main-context tokens by **≥ 30%** at plan-complete
  AND plan quality is judged **≥** Arm A AND zero classifier interference.
- **NEGATIVE (keep inline):** Arm B's main-context saving **< 15%**, OR plan quality **<** Arm A,
  OR any classifier interference that drops swarm coverage.
- **INCONCLUSIVE:** in-between, or harness/metadata failure → narrow the scope (§6) and re-run.

**Harness note:** extend the `scripts/q3-cache-prefix-experiment.mjs` pattern (stream-json `usage`
extraction, median, threshold→verdict, always-write result file). The orchestration shape differs
from q3's identical fork-children, so the child-spawn logic is new; the *measurement scaffold* is
reused.

## 6. Cheaper PoC (audit-recommended, preferred over the full bake-off)

Per `subagent-delegation-audit.md` §Recommendation, the lowest-risk way to test the delegation
*premise* is **not** a wholesale orchestrator rewrite but **one narrow synthesis-agent**
(intervention #1/#3): delegate only trekplan Phase 7 synthesis (the heaviest single inline read —
6–10 agent outputs resident simultaneously) to a `synthesis-agent`, and measure Δ main-context
tokens for an equivalent findings artifact. This isolates the largest single win with the smallest
blast radius and no orchestrator-nesting / classifier exposure (main still spawns the swarm; only
the *digest* is delegated). Recommended as the **first** thing to measure if delegation is pursued.

## 7. CC-26 recommendation (operator gates the verdict)

**Lean NO on wholesale delegated orchestration; YES exists only as a narrow, opt-in
synthesis-agent, proven incrementally.**

Reasoning, on the evidence above:
- Feasibility is no longer the blocker (F1/F2) — so the gate turns purely on cost/benefit.
- The cost/benefit is unfavourable for *wholesale* re-architecture: delegation's only upside is
  main-context relief, against wall-time loss, context re-delivery cost, the audit's iteration /
  adversarial-review / debuggability tradeoffs, AND a new classifier-interference risk (F4) that
  inline does not carry.
- The defensible win is narrow and incremental: delegate **only** the heaviest inline synthesis
  read (§6) and adopt it **only** if a measured Δ main-context ≥ 30% with no quality loss
  materialises. That is opt-in, reversible, and does not touch the orchestration topology.

**Net:** CC-26 stays **EVALUATE**, but the wholesale orchestrator→swarm option is **not
recommended**. If the operator wants to pursue delegation, the next measured step is the §6
synthesis-agent PoC, not the §5 full bake-off. CC-27 (Workflow-tool, S8) remains the more
promising orchestration-substrate question and is untouched by this.

## 8. Open items

1. Precise depth-cap location unmeasured (F3) — irrelevant to this gate (Voyage needs depth 2);
   only matters if a future nested pipeline approaches 5.
2. Classifier behaviour for a *purposeful* swarm under `auto`/`bypassPermissions` is unverified
   (F4) — must be in the §5/§6 test matrix before any delegated spawn ships to a headless path.
3. The §6 synthesis-agent PoC and the §5 full bake-off are both **designed but unbuilt** — ready
   to run if CC-26 is greenlit toward delegation.