The Meta-Orchestrator Is the Workbench

This field report describes one anonymized internal run in August 2026. “Multi-slice” means tracker-defined work units across API, UI, compliance, documentation, and cleanup—not a count of simultaneously active agents. Client identifiers, sector-specific product surfaces, repository paths, issue text, exact incident counts, and account metadata were removed. The remaining observations are first-party evidence, not benchmark results.

We used Orca to push a workspace redesign through a live regulated-industry monorepo. At the busiest point, Claude, Codex, OMP, and Pi workers were implementing API, UI, compliance, documentation, and cleanup slices at the same time. The visible spectacle was the fleet. The useful system was everything that prevented the workers from becoming unrelated conversations.

The coordinator translated the tracker into an executable dependency graph, wrote briefs with exact seams, assigned work to compatible harnesses and models, watched completion signals, reconciled questions, and fed finished branches into a serialized merge queue. Workers did not own the overall plan. The coordinator did not micromanage their local implementation. That separation let specialists move quickly without allowing local context to redefine project scope.

Concurrency is a resource, not a strategy. Starting twelve agents is easy. Preserving one product contract across twelve partial views, then integrating their output without losing evidence, is the actual engineering work.

Orca gave us a vocabulary that survived terminal churn and machine interruptions. A Run was the durable objective and coordinator inbox. A Task was a unit of work with dependencies and status. A Dispatch was one concrete attempt by one worker in one terminal or worktree. Keeping those identities separate mattered whenever an agent stalled, a terminal restarted, or a branch needed a replacement reviewer.

The worker completion signal was not a decorative status message. It carried task and dispatch identity, outcome, files touched, findings, and remaining work. Questions were routed back to the coordinator instead of being answered by guesswork. A failed attempt could be replaced without pretending the task itself had succeeded. This made recovery possible after workstation interruptions: the filesystem, branches, pull requests, tracker state, and orchestration receipts could be re-read and reconciled instead of reconstructed from memory.

The practical lesson is broader than Orca. A meta-orchestrator needs durable identifiers, an inbox, explicit lifecycle transitions, and idempotent recovery. A grid of terminals is an interface. It is not yet a control plane.

In this run, we assigned Fable 5 to broad coordination and long-context synthesis, GPT models to bounded implementation, adversarial review, and exact refactors, and Kimi K3 to an independent structural read. Those were observed placements, not permanent model-family capabilities. We re-evaluate them against the current catalog and the expected failure mode of each task. OMP made the placements portable through a common tool surface, live model selectors, persistent kernels, LSP, structured subagents, and configured fallback chains per model and role.

The routing rule was task-shaped. Cheap or fast lanes handled inventory, mechanical checks, and narrow cleanup. Strong reasoning lanes handled architecture, security boundaries, migration conflicts, and final synthesis. Review used model diversity on purpose: correlated confidence is not independent evidence. When models agreed, we looked for the shared factual basis. When they disagreed, the disagreement became an explicit editorial or engineering decision instead of being averaged away.

Harness choice was also part of routing. Claude Code, Codex CLI, Pi, OMP, and other agents differ in tool contracts, edit reliability, context management, review behavior, and provider access. Orca treated them as workers behind one lifecycle. OMP treated many model providers behind one agent surface. The meta-orchestrator sat above both layers and preserved the task contract while choosing the cheapest reliable approved path. Provider or model changes were allowed only when the artifact’s data classification and retention policy permitted them.

Real fleets fail unevenly. Provider credentials expire. A model route works on a toy probe and rejects the real prompt. A harness starts under the wrong runtime. A remote testbox lacks the expected package manager. A reviewer rate-limits after implementation finishes. During this run we encountered those shapes, plus workstation interruptions and a repository baseline check that was already red before several feature branches began.

The useful response was a ladder: retry the same route only for a bounded transient failure; switch provider for the same model when transport is the problem; switch model within the same harness when capability or availability changes; switch harness when its tool surface is the failure; move execution to another machine when the environment is the failure; escalate to a person when authority, ambiguity, or risk exceeds the delegated boundary. Every rung retained the original task, test, review, privacy, and audit requirements. The red baseline had a named owner; affected slices used scoped, delta-green gates so no branch could add failures while the root repair proceeded separately.

A bad fallback silently lowers the bar: skip the review, narrow the test, accept the stale branch, or call a partial artifact complete. A good fallback preserves semantics and changes only the means. This is why fallback policy belongs in configuration and the orchestrator rather than improvised worker prompts.

Parallel implementation moved faster than shared-state integration. Database migration numbers collided. UI branches touched the same barrels and translation registries. A branch that was green against yesterday’s development head became conflicting after three prerequisites merged. The fleet was still productive, but the critical path had moved from generation to integration.

We responded by serializing the dangerous boundary. Workers continued in parallel on independent slices, while one integration owner for this run rebased, reconciled migrations, reran the relevant gates, and advanced the shared branch one pull request at a time. Downstream tasks stayed blocked until their actual prerequisite landed, not merely until a worker announced that its branch was ready. The general rule is one fenced writer at a time for each contested surface—not one permanent person or one global queue.

The deeper design rule is one writer per contested truth. Many workers may propose changes. One queue owns the shared branch. One migration sequence owns database order. One tracker owns delivery state. One registry owns model or feature configuration. Throughput comes from parallelizing what is independent and deliberately serializing what is not.

The coordinator never treated a worker’s confident summary as completion. A slice moved only after the artifact existed, the changed path was exercised, required checks passed on the current head, independent reviews were reconciled, review threads were resolved, and Linear reflected the same state as the repository. When a mandatory review service rate-limited, the task waited or used an approved equivalent gate; the absence of a reviewer did not become approval.

This produced a useful asymmetry. Workers could be creative inside their slices, but completion was boring and mechanical. The proof depended on the task: a bug needed a reproduction that no longer failed; a UI change needed a driven visual path; an API contract needed focused tests and a smoke call; a merge needed current-head CI and clean review state. Evidence was generated after the relevant change, not inherited from a previous branch head.

Receipts also made honest recovery possible. After an interruption, we did not ask which agent sounded finished. We asked which tasks had settled dispatches, which pull requests were mergeable, which checks were green, which review threads remained open, and which tracker states contradicted the code. No system owned every truth: the tracker owned product intent, Run/Task/Dispatch owned attempt lifecycle, the authoritative branch owned integrated artifacts, current-head CI owned verification state, and the review system owned unresolved objections and approvals. On disagreement, promotion stopped until the owner of that fact was reconciled and fresh evidence was generated.

A practical adoption path is small. First, choose one source of product truth and turn a handful of independent issues into tasks with explicit acceptance criteria. Second, create one Run and dispatch two implementation workers plus one independent reviewer. Third, require structured completion and keep one human or coordinator-owned integration queue. Fourth, add model and provider fallbacks only after you can identify which layer failed.

The extra lanes are not free. For one or two independent, low-risk tasks, a single strong worker plus focused verification is usually cheaper and easier to coordinate. Add heterogeneous workers when specialization or parallelism shortens the critical path; reserve multi-model panels for consequential artifacts where an undetected error costs more than the additional calls and synthesis time. Recalculate that break-even point from current provider prices, rate limits, and coordinator load rather than assuming a fleet always wins.

This walkthrough was verified against Orca 1.4.168, where orchestration is an Experimental feature. Enable Settings → Experimental → Orchestration, load the version-matched guide from the running binary, and confirm runtime state. If orchestration is unavailable in the installed binary, stop rather than translating remembered flags. Build the DAG before starting workers. Launch the ready wave only up to the concurrency budget imposed by machine resources, provider limits, and coordinator capacity. Use blocking delivery checks rather than terminal polling. In OMP, name model lanes explicitly and keep fallback chains in configuration rather than changing them ad hoc mid-task.

Scale width only when the coordinator can still answer five questions: What is ready? What is blocked and by which merged dependency? Who owns each contested surface? What fresh evidence is required next? Which system owns the disputed fact? If those answers are not immediate, more agents will increase work in progress faster than shipped value. The meta-orchestrator is the workbench because it is where intent becomes controlled concurrency, and controlled concurrency becomes integrated evidence.