Relay
Relay takes a single, well-specified task and runs it through the same phased pipeline as everyday Orchestration — plan → architect → implement → review — but with one change: every phase is executed by a CLI vendor lane instead of a sub-agent. The Conductor stays in charge, hands the task from one vendor to the next, and writes each phase’s output to a .ptah/specs/TASK_* folder so the whole run is auditable and resumable.
Where Forge and Race give every vendor the same prompt and pick a winner, Relay gives each vendor a different prompt — one per phase — and runs them as a sequential pipeline. The diversity shows up in one place: the review phase is always handled by a different vendor family than the one that wrote the code, so you get genuine cross-vendor review baked into delivery.
When to use Relay
Section titled “When to use Relay”- You want orchestration’s structured delivery — a real plan, an architecture doc, an implementation, and a review — but you want the work done by external CLI vendors rather than in-process sub-agents.
- Cross-vendor review on your own changes — the implementer and the reviewer are deliberately different vendor families.
- An auditable, resumable run — every phase is persisted to
.ptah/specs, so you can review each artifact or resume a run that timed out.
How it runs
Section titled “How it runs”Phase 1 — Plan & architect
Section titled “Phase 1 — Plan & architect”The Conductor creates a .ptah/specs/TASK_* folder, restates the task with explicit acceptance criteria, and hands the planning and architecture phases to a reasoning-strong vendor lane. Each phase writes its deliverable (task-description.md, then implementation-plan.md) to disk. You review and approve these documents before any code is written — the same checkpoints as a normal Orchestration run.
Phase 2 — Implement
Section titled “Phase 2 — Implement”The approved plan is handed to a coding-strong vendor lane, which implements the change in place on your working branch and logs its work to tasks.md. The artifact from each phase becomes an input to the next — that hand-off is the “relay baton”.
Phase 3 — Cross-vendor review
Section titled “Phase 3 — Cross-vendor review”A different vendor family reviews the implementation against the acceptance criteria and writes code-logic-review.md. Because the reviewer never wrote the code, this is a true peer review, not a self-check. If the review surfaces a real issue, the Conductor relays a fix phase before declaring the task done.
Phase 4 — Verify & synthesize
Section titled “Phase 4 — Verify & synthesize”The Conductor runs the project’s tests/build/lint on the change, then produces a summary that cites which vendor produced each artifact. You see the diff and approve before anything is committed.
Safety
Section titled “Safety”- Runs in place on your active branch — no worktrees by default, since it’s one task rather than N competing attempts.
- Never commits without your sight and never auto-merges to
main. - Vendors never commit — each lane does its phase and hands back; the Conductor owns verification and the final commit.
- Resumable — the
.ptah/specs/TASK_*folder lets a timed-out run pick up where it left off instead of starting over.
Invoking Relay
Section titled “Invoking Relay”Natural language triggers:
- “Relay this task across the panel”
- “Run this as a vendor pipeline — plan, build, then a different vendor reviews”
- “Orchestrate this with CLI vendors instead of sub-agents”
From the Tribunal panel: choose Convene a Tribunal on the dashboard and pick Relay. Relay is a role move, so instead of a flat lane picker you get one slot per phase — Plan, Architect, Implement, Review — each with a vendor and a model chosen from whatever discovery found on your machine. The same vendor may fill two slots on different models, but the roster is validated before launch: a review lane identical to the implement lane is blocked outright, and a same-family review is flagged as a weaker signal than a cross-vendor one. Launch, then describe the task and its acceptance criteria in the conductor chat.
While the run is live, the panel shows a four-step phase rail above the lane tiles: each phase’s status, which lane is handling it (and whether it was reassigned mid-run), and a link to its deliverable in the spec folder. If no spec folder could be allocated, the rail says the progress readout is unavailable rather than showing four phases that look like they haven’t started.
Explicit harness: select Tribunal Conductor from the harness picker, then describe the task and its acceptance criteria.
Relay vs. the other moves
Section titled “Relay vs. the other moves”| Move | Prompt per vendor | Shape | Produces |
|---|---|---|---|
| Council | Same question | Parallel panel | A cited verdict (no code) |
| Forge | Same coding task | Parallel + review | Best of N implementations, merged |
| Race | Same coding task | Parallel + verify | One verified winner |
| Relay | Different prompt per phase | Sequential pipeline | Delivered change + spec artifacts |
| Crucible | One task, two unequal roles | A loop, until PASS or a cap | Delivered change + the judge’s round record |
Limitations
Section titled “Limitations”- Needs a clear task and acceptance criteria — a vague brief produces a vague plan, and the whole pipeline inherits the fuzz.
- Cost — roughly one vendor call per phase (more if a high-stakes phase is fanned out to multiple vendors). Ptah announces the lanes and cost before spending.
- Heterogeneous, not a panel — Relay deliberately bends Tribunal’s “diversity is the signal” thesis; the diversity here is the cross-vendor review phase, not N answers to one question.