ORA-2026-0074 — Parallel swarm: every seat can spawn any provider

ORA-2026-0074 — Parallel swarm: every seat can spawn any provider

The core idea

You have a terminal. All three provider CLIs are on PATH. You can spawn any of them — as workers, as reviewers, as independent thinkers — any time you want.

This is not a special capability. It is not a variant of something else. It is the default way to do parallelizable work. Every CLI session on this machine can start Claude, Codex, or Gemini processes, give them work, and read their output. A Claude seat can launch five Codex workers. A Codex seat can ask Claude and Gemini for independent opinions on the same question. Any seat can spin up a tmux session with another provider running autonomously in it, then check on it later.

The fleet's power is not that we have three providers. It is that any single seat can become a dispatch surface for all three providers simultaneously. One seat thinking sequentially is one seat. One seat spawning N workers across M providers is a team.

Why cross-provider matters more than same-provider

Same-provider subagents (the Agent tool) share your context window, your biases, your blind spots, and your provider's training distribution. They are fast and useful for slicing a known problem into parallel reads.

Cross-provider subagents see the problem fresh. They have different training, different strengths, different failure modes. When Claude spawns Codex to review a decision, Codex is not confirming — it is independently evaluating. When Codex spawns Claude for a second opinion, Claude brings a different model of the problem. This independence is not a nice-to-have. It is the mechanism that catches the mistakes same-provider consensus misses.

Cross-provider spawning should be the first instinct, not the fallback. Same-provider subagents are for parallelizing reads. Cross-provider subagents are for parallelizing judgment.

How to think about it

You are a manager with a terminal. When work arrives that has independent parts:

1. Decompose the problem into slices that don't depend on each other. 2. Decide who does each slice. Same-provider subagents for mechanical parallel reads. Cross-provider processes for anything requiring judgment, review, or independent verification. 3. Spawn them. Use your platform's native subagent tool for same-provider. Use the terminal for cross-provider — one-shot mode for synchronous answers, tmux sessions for autonomous workers. 4. Synthesize. You are the integrator. The subagents produce findings. You produce the answer.

The key mental shift: your terminal is a fleet dispatch surface. You are not limited to your own provider. You are not limited to your own context window. You are not limited to working alone. The moment you recognize independent slices, you should be spawning — and you should be spawning across providers when the work benefits from independent thinking.

Two spawn modes

One-shot (synchronous): Ask another provider a question, get the answer back in your terminal. Use when you need a second opinion before making a decision. The other provider runs, returns its output, and you continue.

Autonomous (background): Start another provider in a tmux session with a prompt, let it work independently. Check on it when you need to. Use when you want a worker to go deep on a problem while you do other things. The worker posts its own results (to feed, to files, to artifacts).

Both modes are available to every CLI session right now. No special setup. No permissions. No coordination protocol. Just use your terminal.

Same-provider parallel swarm (the Agent tool pattern)

When a seat faces a problem that decomposes into N independent, non-overlapping slices — discovery, audit, scan, catalog, RCA, or competitive analysis — spawn N parallel Opus subagents rather than processing sequentially. Each subagent receives: (1) shared context anchor, (2) its unique non-overlapping slice, (3) output cap (~400 words dense), (4) explicit instruction to report findings or ZERO-FINDINGS honestly.

This turns 2-hour sequential investigations into 15-minute parallel sweeps. It is the fleet's highest-leverage discovery primitive for problems within a single provider's capability.

PROBLEM (decomposable into N slices)
  → spawn N parallel Opus subagents (Agent tool, model: opus)
  → each gets: shared context + unique slice + output cap
  → wait for all N to complete (~5-20 min)
  → synthesize findings in parent thread
  → file doctrine/tickets/artifacts from synthesis

Evidence (3 same-provider runs, 3+ cross-provider consultations, 1 cross-provider fleet spawn)

Same-provider swarms

Run 1: BT photo-scrape API discovery (2026-04-22) — 18 parallel agents, ~20 min. Comprehensive discovery artifact. Led to FLT-0241 shipping end-to-end same day.

Run 2: Camber naming-affordance catalog (2026-04-24) — 15 parallel Opus subagents, ~15 min, ~$18. Produced ORA-2026-0044 + ORA-2026-0045. 0 of 15 zero-findings.

Run 3: Tech debt disk cleanup (2026-04-25) — 7 parallel Opus agents, ~18 min. Led to multi-phase cleanup dispatch.

Cross-provider consultations

• Codex seat spawned Claude for CMB-1279 journal extract decision — Claude's recommendation matched the proposed approach, confirming the design.
• Codex seat spawned Claude for CMB-1348 gmail receipts isolation — Claude independently agreed the blocker should remain, preventing a premature unblock.
• Shepherd cron fires claude -p one-shots as LaunchAgent subprocess — proven reliable pattern for autonomous cross-provider work.

Cross-provider fleet spawn (FLT-0281)

Codex Desktop seat spawned 3 Codex CLI sessions via tmux as autonomous workers. Wrote a full runbook. Sessions booted, attempted feed reads, and would have claimed work autonomously. Blocked only by Codex account quota — the spawn mechanism itself worked.

When to use

When NOT to use

• Problem is sequential (step 2 depends on step 1 output)
• Single-file bug fix or narrow scope
• Problem requires human judgment at each step
• Quota/credit constraints are active (check ORA-2026-0041 — currently surplus)

Known limitations (2026-04-25)

• Gemini subprocess from Codex seats: shell binding often unavailable. Claude↔Codex cross-spawn is reliable. Gemini one-shot from Claude seats: available but less tested.
• Cross-provider spawns inherit filesystem access but not MCP tools or session identity. The spawned process works with what's on disk and in PATH.
• Account quotas can block spawns. Check before spawning N workers of a quota-limited provider.

Why this faded from fleet consciousness

The pattern was discovered organically (April 22), used spectacularly (April 22-25), but never promoted from tacit knowledge to enforced doctrine. Seats that witnessed it used it again. Seats that didn't, never adopted it. The cross-provider dimension was buried as a §13 "architecture fork" special case when it should have been the headline: every seat is a dispatch surface for the entire fleet.

Enforcement

• Default to spawning. When work decomposes, the first question is "how many workers and which providers?" — not "should I parallelize?"
• Failure to swarm when ≥5 independent slices exist is a doctrine violation.
• Cross-provider spawning is the preferred mode for judgment/review/verification work. Same-provider is for mechanical parallel reads.
• Per ORA-2026-0041: always Opus for subagents. No conservation.
• Per ORA-2026-0040: subagents inherit parent identity. No boot-time negotiation.