Parity Room: Two Agents, Two Machines, One Switch Room

Same commit. Same tests.

• On my Mac: 3 passed.
• On Linux: 0 passed.

These are the three errors on Linux:

FileNotFoundError: [Errno 2] No such file or directory: 'config/Settings.json'
AttributeError: module 'datetime' has no attribute 'UTC'
AssertionError: assert {'2024-11-01': 4} == {'2024-11-01': 2, '2024-11-02': 2}

None of these is a logic error. Each one is something the code assumed about the machine it was written on: a file system that ignores letter case, a newer Python, a timezone.

I built Parity Room for the Flip the Switch hackathon to see what happens when agents handle this, and when people keep the decisions.

The idea

A Claude Code agent runs on my Mac. A Codex agent runs in a Linux container. Both join one Switch room with a PM (maya) and a QA lead (sam).

1. maya asks @verifier to check a branch.
2. The Linux agent runs the checks in its own environment, writes the evidence to a room document, and tags @implementer.
3. The Mac agent reads the room documents, fixes the causes, pushes, and updates its own evidence.
4. The Linux agent checks the new commit. Both machines pass.
5. The Mac agent asks sam to approve. It merges only after sam says yes in the room.
6. dave, the intern, tells the agent to push to main. Switch refuses the message. The agent never sees it.

The video is a real recorded run. I sped up the waiting parts and labelled them on screen.

What Switch does here

I did not write glue code for any of this.

• One template creates both agents on their named machines, and the room.
• Roles. People write @verifier or @implementer, never a machine name. implementer is exclusive, so only one agent pushes at a time.
• Room documents. A conventions document belongs to a person, and agents cannot edit it. Each agent owns its own evidence document.
• Addressing policy. Switch decides who may instruct the agent that can push. The rule lives in the platform, not in a prompt.

The third bug is the interesting one

The first two bugs crash. The third one does not. A test expects two events on 1 November and two on 2 November. That value came from a machine in IST. In UTC, all four events fall on 1 November.

So which side is wrong, the code or the test? A person has to decide. In Parity Room, the decision is in the conventions document: days are UTC days. The Mac agent reads it, changes the test, and writes the reason in the room.

That is the part I care about. Finding the failure is easy. Deciding which side is right, and writing it down where the team can see it, is the useful part.

Switch shows the result in its own web UI. This is the room page after a real run: the roles and who holds them, and the documents that each agent wrote.

Does it work?

I ran the whole flow five times with scripted people (the person lines were posted by a script). After each run, a script checked the result. Both evidence documents showed three of three at the same commit. The merge commit was on main. The merged main passed on the Mac and in the container.

• Request to ready for approval: 2m25s to 2m49s (median 2m42s).
• Approval to merge: 6 to 11 seconds.

Two earlier runs failed. In one, the verifier wrote that the result was green but forgot to tag @implementer, so the Mac agent never woke up. Now the hand-offs use Switch's send_targeted_message tool, which always addresses the role. In the other, my Mac went to sleep and paused the agent. The controller now holds a no-idle-sleep assertion.

Isn't this just Docker and CI?

Mostly, for finding the bugs. Docker or CI would catch all three. The make evidence command in the repo shows them with only Docker.

What they do not give you:

• A decision about which side is wrong, and a record of it.
• A person who must approve before the merge, recorded by name.
• A platform rule that stops the intern from pushing.

Why two agents and not one? In this demo, one agent with Docker could do all of it. The split is about access and trust. An agent can only report on the environment it really runs in. The agent that checks is not the agent that fixes. Only one agent writes to main. That matters more when the machines cannot sit in one place, for example a colleague's laptop or a Windows box. My demo does not show that, because the Linux machine is a container on the same Mac.

I do not think the idea has a technical moat. It is a template on top of what Switch gives you. If you build it, you can copy it in an afternoon, and that is fine.

What is real and what is not

• The agents, the Switch room, and the checks are real.
• The three bugs are seeded on purpose.
• In the newer video, maya and dave are typed by Claude Code, which drives my Mac's real mouse and keyboard, and sam is a second AI agent. There is no real teammate in the recording. In the first video and in the replay, the three people were scripted test accounts.
• The narration in the video is a synthetic voice.
• I tested on macOS (Apple silicon) only. I did not test a Linux host, Windows, Slack, Teams, Discord, or the template import in the Switch Console.

What I would tell the Switch team

• Roles, single-writer documents and the addressing policy worked well.
• Running the controller in a container needs a trick. It accepts plain http only on loopback, so I put the container in the network of the Switch container. A documented method would help.
• The refusal message says the account is not linked to a Switch user. My policy also allowed two named people, so a message such as "you are not on the allow-list" would be clearer.
• The full list is in the repo: docs/feedback.md.

Try it

You only need Docker and uv to see the bug:

git clone https://github.com/saurabh4269/parity-room
cd parity-room
make evidence

To run the whole room, you need Claude Code and Codex signed in. Then run make demo.

• Code: github.com/saurabh4269/parity-room
• Project page with a replay you can scrub: saurabh4269.github.io/parity-room