Cross-Harness Relay: Grok Bot, Claude Code, Codex and Hermes on one job

Read this repo and my notes [paste]. Draft RELAY.md using this template [paste]. Leave 'Filled by' blank.
For each seat, propose the narrowest reach that still lets it do the job, and list what it may not do.

Decide who fills each seat last.

You did not write this diff. Compare it to PLAN.md [paste].
List findings as high, medium or low with file, line and a one-line fix. Say plainly if nothing is high.

Use a different model from the builder.

# Cross-Harness Relay: Grok Bot, Claude Code, Codex and Hermes on one job

A bot template and teaching guide by PaperChaseWebb for running more than one agent harness on the same piece of work. Seat cards for a front desk, planner, builder, reviewer, tester and night shift, a RELAY.md seat map, a relay packet every handoff carries, routing rules, a preflight check, shared memory rules, eight relay drills, a rules block and 14 prompts. Plain .md.

This is a method, not a hosted product and not an endorsement of any vendor. You bring the accounts you already use. The pack tells each agent which seat it sits in, what it may touch, what it must hand on, and where you read before the work moves.

## Contents

1. Why run more than one harness, and when not to
2. Seats, not models
3. The seat map: RELAY.md
4. Six seat cards
5. The relay packet
6. Four loop shapes
7. Routing rules: routine or judgment
8. Preflight: prove the next seat can act
9. Front desk and night shift
10. Shared memory between harnesses
11. Failure modes and fixes
12. Eight relay drills
13. Rules block and 14 prompts
14. Sources

## 1. Why run more than one harness, and when not to

Builders who use Grok Bot, Claude Code, Codex and Hermes side by side keep landing on the same few reasons:

- **A second reader.** A model reviewing its own diff tends to agree with itself. A different model, or a different seat with a different brief, finds the step most likely to fail.
- **Different jobs, different homes.** Conversation and approvals belong with whatever you talk to all day. Long unattended jobs belong somewhere built to run them. Routine code belongs wherever it costs least to produce and is easiest to review.
- **Limits.** Quotas and usage caps run out at bad times. A written fallback route keeps work moving without the agent deciding on its own where to send it.

When not to: if one agent with a good rules file and a test suite already gets the job done, a relay adds handoffs, and every handoff is a place to lose context. Start with two seats (builder and reviewer). Add a seat only when you can name the problem it fixes.

## 2. Seats, not models

Write the team as seats. A seat is a job with a brief, a reach (what it may read and change) and an exit (what it must hand on). Any harness can fill any seat. You decide who fills which seat from your own trial runs, not from a leaderboard.

| Seat | Job | Typical reach | Exit |
|---|---|---|---|
| Front desk | Takes requests, asks for approvals, reports results | Chat, calendar, read access to the repo and logs | A relay packet to the next seat, or a report to you |
| Planner | Turns a ticket into a plan with files, tests and risks | Read the repo, write PLAN.md | A plan you approve |
| Builder | Implements one approved plan | A branch, the test runner | A diff with tests green |
| Reviewer | Reviews the diff against the plan | Read the branch, write REVIEW.md | Findings by severity |
| Tester | Uses the running app like a person | A test or staging URL, a test account | Bugs written as a spec |
| Night shift | Runs long or scheduled jobs unattended | A narrow profile with only the tools the job needs | A result with a proof footer |

Two rules hold across every seat: no seat approves its own work, and no seat widens its own reach.