Orchestration & Model Routing

#The Problem

A multi-agent system with frontier models can burn unbounded money and attention. Archon Merkaba treats orchestration as a routing economics problem: every task should land on the right agent, on the right model, in the right execution environment — and the rules must be codified so they survive across sessions and models.

#Smart Model Routing

When the orchestrator spawns a subagent, model selection is deterministic:

1. Force-primary list. Agents whose mistakes are expensive (intelligence synthesis, investment strategy, architecture, security, engineering) always get the frontier model, regardless of how simple the message looks.
2. Message complexity scoring. For everyone else, a message is "simple" only if it passes all checks: short length, single line, no code blocks, no URLs, and no complexity keywords (a curated list of ~25 terms like backtest, daemon, migrate, security, traceback). Simple → mid-tier model; anything else → frontier.
3. When in doubt, route up. Conservative routing is cheaper than a wrong answer.

This mirrors the classic "cheap gate in front of an expensive expert" pattern, but applied to an entire agent fleet.

#Execution Environment Routing

The same discipline applies to where work runs:

A standing cost rule — "the VPS does vital operations only" — is written into policy: before any new cloud job that calls a paid API can be added, it must be justified against that rule. This single sentence has repeatedly prevented paid-API sprawl.

#Orchestration Patterns

The system uses a small vocabulary of reusable orchestration shapes, kept in a local workflow registry with trigger phrases and guardrails:

• Parallel specialist spawns (1–4 agents). The default for known, named delegations — e.g., "evaluate this strategy" fans out to CIO + TraderBot + Researcher, then the orchestrator synthesizes. Used when you already know exactly who to call.
• Multi-agent audit. Several agents independently review the same system through different lenses (correctness, security, silent failures, type design), findings are cross-validated, and only confirmed findings survive. The system's larger audits (up to nine agents) have produced multi-wave remediation plans.
• Dual-engine code review. Two independent review engines from different model families review the same diff; findings flagged by both get a confidence boost, and single-engine findings survive only above a confidence threshold. Model diversity catches what redundancy cannot.
• Wide dynamic fan-out. For genuinely open-ended work (broad research sweeps, many-file migrations), scripted workflows spawn agents programmatically with adversarial verification stages before results surface.
• Goal-bounded convergence. For single-session tasks with a measurable end state, a completion condition is set and a small evaluator model checks it each turn until it holds. Policy explicitly forbids using this for multi-day watches (that's the monitoring layer's job) or for unattended irreversible actions without circuit-breaker conditions and a hard turn bound.

#Guardrails on Autonomy

Orchestration power is bounded by standing rules:

• No workflow may auto-deploy to the live trading daemon, push to external repositories, or post to social platforms without an explicit human gate. Verification stages check correctness, never authorization — those are different questions.
• Approvals expire. A human approval older than seven days is stale and must be re-confirmed before an action fires. (This rule was learned the hard way; see 08 — Engineering Practices on institutional memory.)
• Kill switches. Any automated job that touches an external platform checks a kill-switch file before acting and exits silently if it exists.
• One pilot at a time. Only one session may manage the live trading daemon concurrently — enforced by convention and hooks, preventing two agents from fighting over a live process.

#Chat-Ops as an Orchestration Surface

Human ↔ fleet interaction flows through chat channels mapped to agents. The pipeline acknowledges receipt (a reaction emoji), routes to the specialist, replies in-channel, logs delivery, retries transient failures once, falls back to a secondary messaging channel on persistent failure (sending only metadata, never content — responses may contain sensitive data), and dead-letters anything undeliverable for later replay. Permanent errors (authorization, allowlisting) are classified and never retried.

The result: the founder can run the company from a phone, and every message is delivered, logged, or accounted for.