AMPLIFAI The Masterclass →
Field Guide

Two agents, one loop:
getting Claude and Codex to work together

I asked Claude to make a space where it could talk to Codex. It made a markdown file. Then I spent an hour being the messenger between them, until a seventeen-line script took that job. This is what actually happened, in order.

You'll need

  • Two agent CLIs (we used Claude Code + Codex)
  • A repo they can both open
  • A spare terminal for the watcher
  • No orchestration framework
Where this comes from. One working day on an interactive graphics site: a scroll-pinned canvas gone glitchy on iPhone. It ended with 46 logged messages between three agents. Nothing here was planned in advance; each piece got added the moment the previous setup became annoying.
1

Ask for a room, not a system

~3 min

The entire setup started with one sentence and no design.

I asked Claude to create a space where it could collaborate with Codex. That's the whole prompt. I didn't specify a format, a protocol, or a handoff scheme. I wanted to see what it would do.

It made a markdown file called AGENT-CHAT.md, and gave it house rules at the top:

Free-form discussion channel between agents.

- Append messages at the bottom. Never edit or delete another agent's message.
- Header format: ### <date> <time> — <agent>
- Keep messages short; link files/lines instead of pasting large blobs.
- Address the other agent directly (@codex, @claude).

That's it. No framework, no message queue, no orchestration library. A text file in the repo that both agents can read and append to, because both of them already have file access. That's the entire transport layer.

The append-only rule turned out to matter more than it looks. It means neither agent can quietly revise what it said earlier to match how things turned out, so the log stays honest enough to reconstruct a decision hours later.

The prompt
"Create a space where you and Codex can collaborate." Let the agent design the protocol, then read what it chose and keep the parts that work.
2

Notice you're the relay

~3 min

They'll write to each other happily. Neither will ever think to go and read.

The chat file worked immediately. Claude posted, and when I told Codex to look, Codex replied properly with the right header and a real response. The collaboration was fine. The problem was me.

An agent only acts when you prompt it. So every single exchange needed me to switch terminals and say "go read what the other one wrote." Claude posts, I tell Codex. Codex replies, I tell Claude. For a conversation that ran dozens of messages, I was a human message bus, and the agents were waiting on me for every turn.

This is the moment worth recognising, because it's the same in any multi-agent setup you build by hand: the agents aren't the bottleneck, the polling is. Nothing wakes an idle CLI except a person typing into it.

The tell
If you're copying context between two terminals more than twice, stop and automate the wake-up. That's the actual missing piece, not a better prompt.
3

Replace yourself with 17 lines

~5 min

A loop that watches a file's timestamp, and wakes the other agent when it changes.

I asked Claude to automate the relay. It wrote a bash script. This is the whole thing, unedited:

#!/bin/bash
# Auto-relay: when Claude posts to AGENT-CHAT.md, wake Codex to reply.
# Run in its own terminal: ./scripts/agent-chat-watch.sh
cd "$(dirname "$0")/.."
LAST=""
while true; do
  NOW=$(stat -f %m AGENT-CHAT.md 2>/dev/null)
  AUTHOR=$(grep '^### ' AGENT-CHAT.md | tail -1)
  if [[ "$NOW" != "$LAST" && "$AUTHOR" == *Claude* ]]; then
    echo "[watch] new Claude message — waking Codex..."
    codex exec --full-auto "Read AGENT-CHAT.md in this repo. The latest
message is from Claude and awaits your reply. Reply as Codex per the file's
protocol: append one message at the bottom (header '### <date> <time> —
Codex'), never edit earlier messages. Engage substantively; verify claims
against the code before agreeing."
    LAST=$(stat -f %m AGENT-CHAT.md 2>/dev/null)
  fi
  sleep 15
done

Read what it's doing. Every fifteen seconds it checks the file's modification time and the last ### header. If the file changed and the newest message is Claude's, it runs codex exec with a prompt telling Codex to go read the file and reply in protocol. Then it records the new timestamp so the same message never fires twice.

The idle cost is zero. Not "cheap". Zero. The loop only runs stat and grep, which are ordinary shell commands touching nothing but your filesystem. No model is invoked until there is genuinely a new message to answer. You can leave it running all day and it costs nothing but a terminal tab.

One line in that prompt is doing quiet, heavy work: verify claims against the code before agreeing. Without it, the second agent tends to be agreeable, and two agents nodding at each other is worse than one agent working alone, because you've doubled the cost and added false confidence. That clause is what makes the loop produce disagreement.

Run it in its own terminal
./scripts/agent-chat-watch.sh runs it. It's a foreground loop. Ctrl-C stops the relay; the agents just go quiet.
4

Let them organise

~4 min

Once the loop closed, the parts I expected to have to design showed up on their own.

I asked for two things: collaborate, and give me summaries. What emerged from that was more structured than anything I would have specified.

They divided the work without being told to: one taking the scroll and resize layer, the other taking touch and rendering, and said so explicitly in chat so the split was on record. They corrected each other, repeatedly and bluntly. The most useful message of the day was Codex telling Claude that its first fix had improved the wrong layer: the work was real, it was just aimed at something that wasn't the defect. One agent alone would have shipped that and reported success.

They also worked out that they needed separate copies of the repo, because two agents editing one folder overwrite each other. That became a rule in a shared AGENTS.md contract file: own branch, own working directory, never edit another agent's files. Again, written by them, after hitting the problem.

And they got things wrong together. At one point both agents agreed the bug was fixed while the site was still visibly broken on my phone. My correction, a one-line field report that the section never advanced, reset the whole diagnosis. Two agents agreeing is not evidence. It's still worth checking with your own eyes.

What to prompt for
"Collaborate, correct each other, agree who takes what, and summarise for me." The structure follows from that. You don't have to invent it up front.
5

Roles that swap

~4 min

Neither agent is "the builder." Whoever isn't writing is reviewing, and it trades every round.

This was the pattern that made the day productive. One agent implements a slice while the other stays strictly hands-off. When the implementer finishes, it commits and says so, and the phrase it settled on was "I am now read-only." That sentence is the handoff. The other agent then reviews the committed change, and the roles invert for the next slice.

A real handoff from the log, trimmed:

### 14:32 — Claude, items 1+5 committed, going read-only

Behavioral commit posted: e9cef2c on branch fix/resize-storm.

Scope, exactly per your 14:18 authorization:
  1. width-only resize guard on three handlers
  2. pointer effects gated behind (hover: hover)
  3. svh unit unification across pinned sections

Validation: check passes, 0 errors, 0 layout issues. Diff: +43/-12.

I am now read-only on the composition. Your turn.

Two details make it work. The reviewer is given a commit, not a live file — so it's judging something that can't shift underneath it. And the reviewer runs the checks itself instead of trusting the report, which caught real problems twice.

The review verdicts were genuinely useful: approvals with issues sorted into blocking and non-blocking, so the merge wasn't held up by two minor inconsistencies that got written down for later instead of lost.

The two phrases worth stealing
"I am now read-only" to hand over, and "report blocking issues only" to get back a verdict instead of twelve style opinions.
6

Add a third opinion

~4 min

Two agents that have been arguing for four hours share a frame. A fresh one doesn't.

Late in the day I added a third CLI, Kimi, as a final reviewer. Not as another implementer. By then Claude and Codex had built up hours of shared context, which is efficient and also a blind spot: they'd converged on one way of seeing the bug.

Kimi joined under written terms in AGENTS.md: reviewer and prober only, no edits to the composition, all communication through the chat file, and no promotion to implementer unless both incumbent agents agreed to it there. Findings had to cite file and line, and any validation claim had to state the exact command run.

Its first message was an independent read-only review of three commits, returning a verdict with line-referenced verification of each claim, plus two non-blocking observations, including one about a config call ordering that neither of the other two had raised.

The final tally for the day: 46 messages: 25 from Codex, 20 from Claude, 1 from Kimi. The third agent barely spoke. That's the correct ratio for a final reviewer.

Why write the terms down
A new agent with edit rights and no context is a liability. Role restrictions in a file both existing agents can read means they'll hold the new one to it, so you don't have to police it.
?

Common questions

How do you make Claude Code and Codex talk to each other?

Through a shared file in the repo. Ask one of them to create a chat file with append-only rules and a header format, and both agents can read and write it, because they already have file access, so no integration is needed. Coordination is just text on disk.

How do you automate agents replying to each other?

A small shell loop that watches the chat file's modification time. When the file changes and the newest message is from the other agent, it runs the second agent's CLI with a prompt telling it to read the file and reply. Seventeen lines of bash, no framework.

Does a watcher script cost tokens while it waits?

No. The idle loop only runs stat and grep against a local file: plain shell commands that never touch a model. Tokens are spent only when a new message actually triggers a reply, so you can leave it running all day.

Can two agents edit the same file at the same time?

They shouldn't — they overwrite each other mid-change, and the failure is silent. Give each agent its own working directory and branch, and let only one own a given file at a time, handing over explicitly when it commits and goes read-only.

Do multi-agent setups actually catch anything?

In our case the second agent's most valuable contribution was telling the first that its fix had improved the wrong layer, a correction a single agent had no way to produce about its own work. But two agents also agreed with each other while the bug was still visible on a real phone, so agreement between them is not proof.

Why add a third agent as a final reviewer?

Two agents working a problem for hours converge on a shared framing. A third joining cold, restricted to review only, doesn't inherit that. Ours found an ordering issue the other two had not raised, in its very first message.

Do you need an orchestration framework for this?

No. This whole setup is a markdown file, a bash loop, and a contract file the agents wrote themselves. The structure (role splits, ownership rules, review protocol) emerged from asking them to collaborate and correct each other, rather than being designed up front.

If you also design

Two agents won't save a badly briefed one.

Everything above is coordination, useful only once each agent's first pass is worth reviewing. That part is context, and it's most of the work. If you build interfaces as well as ship them, that's what we teach: context engineering. Giving an agent your design system, your tokens, your rules, so its output starts close instead of generic.

It's a masterclass for designers, so it runs through Figma, worth knowing before you click. And if that's not your world, the setup above is yours to use regardless. It was written to be copied.

Module 1 is free: Figma × Claude Code

Full course: $399 · $299 until Sep 13

Want an agent connected to your Figma canvas first? The Claude Code × Figma setup guide covers that end, then come back and give it someone to argue with.
Agents producing generic UI? That is usually the design system, not the prompt: how to make a design system an agent can actually use.
Running one model as planner and another as builder? Stop building with your best model covers the split and what it costs.