Defaults & Fallback Chains

Defaults — previously the Router — lives at Orchestration → Advanced → Defaults. It is deliberately not a sibling of Charts: it is set-once config, and the system consults it at exactly two moments.

1. Work you never named an agent for. You typed a goal without an @agent, so something has to decide who takes it.
2. A run that failed. The work was assigned, it broke, and the fallback chain says what to try next.

Naming an agent always wins. Defaults never overrules a seat you drew in a chart or an @mention you typed.

The routing table

Work types run down the left — plan, implement, test, review, browser, docs, research, debug — and the agent that takes each one sits on the right. Drag a work type onto an agent to route it; click a route to edit its agent, model and notes. With the rail, palette and inspector all open, the board fits the room it has instead of needing a horizontal scrollbar.

Two things make the table less work than it sounds:

• It fills itself in on first run. The starting table is seeded from the AI CLIs you actually have installed, so you are correcting a real starting point instead of filling an empty grid.
• It suggests from your own results. After enough runs, Defaults can point out a type of work that keeps failing on one engine and propose a change. It never edits your table by itself.

Enabled roles are exclusive task ownership: if the assigned agent fails or lacks a required tool, the host is instructed to stop and ask rather than take over or silently reroute. The Runs & Yields tab shows what was actually delegated.

Fallback chains

A fallback chain is the answer to "what happens when this run dies at 2am?" Give any type of work an ordered list of backups — up to four steps — and the run continues instead of ending.

Choose what counts as a failure

Each chain names the triggers it responds to, so a genuine crash and an exhausted quota can be handled differently:

Each step in the chain carries its own agent, model, and whether it runs as a visible terminal or a headless worker.

Choose whether it advances on its own

A chain can hop automatically, or hold — so a run waits for your approval before it starts spending another provider's quota. Pick per chain; a long unattended job and a job you are watching want different answers.

Read the hop

When a fallback fires, it is written down rather than hidden. An active team shows the line that explains its own output:

That matters because a result produced by the backup should never read as one from your first choice.

What to set up first

If you only do one thing here, give implement and review a single backup each and leave the triggers at rate-limit and quota-exhausted. Those are the two failures that end long runs most often, and the two a chain recovers from without any judgement call.

Related

• Charts — drawing who reports to whom and who hands to whom
• Agent Teams — what a started team is
• Mission Control — watching a run, and the hops it took
• Quota Center — the limits a fallback chain exists to survive