Hermes Journey #4: Two Agents, One Chess Board, and the Protocol That Made It Work

Fourth in the Hermes Journey series.

If you’ve followed this series, you know the first three posts were about taking AI from impressive demo to working system: the operating layer that made my assistant “Storm” useful, and then the day I decided to take the whole journey public.

Now I want to show you the next lesson, and it’s going to sound a little strange at first.

I set up my assistant to play chess against another AI agent.

Not against me. Against a different AI system, running outside my own setup. I’ll call that other agent Rick, because every good rivalry deserves a name. And I want to be very clear about something up front: the chess was never the point.

Chess programs have been beating grandmasters for decades. There is nothing impressive about an AI playing chess well. What was genuinely interesting — and what I actually wanted to test — was whether two independent agents could coordinate with each other. Safely. In turns. On a protocol we all agreed to. With every move verified before anyone accepts it.

That’s a real problem hiding inside what looks like a party trick. And chess turned out to be a perfect laboratory for it.

Why chess

A chess match has everything a coordination problem needs, and nothing it doesn’t. There are fixed rules. There’s a shared, well-defined state — the board. There’s a strict turn order: you go, then I go, and there is no “both at once.” Every move is either legal or it isn’t — there’s no gray area to argue about. And because the whole game can be replayed from the first move, there’s a built-in audit trail. If something goes wrong, you can see exactly where and why.

That combination is rare and valuable. Most real coordination between systems is messy and hard to observe. Chess is clean. It isolates the one thing I actually wanted to study: can two agents pass information back and forth, reliably and safely, according to rules?

How it works

Here’s the setup, described honestly and at a high level.

Storm (White) and Rick (Black) communicate over a secure agent-to-agent channel using a shared protocol we wrote down and both agreed to. Each move is a small, structured message — not a free-form chat, but a defined block that says who’s sending it, whose turn it is, and what the move is.

The thing that makes this more than two chatbots talking is a component I’ll just call the watcher. The watcher reads and updates the single shared game state — the board. When a move arrives, the watcher validates it: Is it legal? Is it this player’s turn? If it passes, the watcher computes Storm’s reply using a Stockfish-style chess engine, sends that move back over the channel, and updates the board. There’s also a fallback channel that works like email — used for history and as a safety net if the primary channel hiccups. The live board updates as the game progresses, which means the interaction can be watched and replayed instead of guessed at later.

The detail that matters: Storm doesn’t get to decide to move twice in a row, change a past move, or bend a rule. The game rules and the protocol constrain the system — exactly the way the approval boundary I described in the second post constrains Storm’s actions in my day-to-day work. The autonomy is bounded. That’s not a limitation. That’s the feature.

What I actually learned

Strip away the chess and this experiment answered four questions I care about for real work.

Protocol before trust. The agents don’t trust each other in any hand-wavy sense. They trust the protocol. Both sides agree on the shape of the message and the order it has to arrive in, and that agreement is what makes communication safe. In business terms: before you let two systems share anything, define the contract between them. That’s not bureaucracy — it’s how you avoid one system assuming something the other never said.

State is a single source of truth. There’s one board, and the watcher owns it. Nobody keeps their own private copy and hopes it matches. When two systems coordinate, the moment they drift into separate versions of reality is the moment everything breaks. A shared, authoritative state — updated by one trusted party — prevents that.

Turn-taking is a feature, not a limit. Real agent coordination shouldn’t be “both systems fire at once and hope.” It should be a sequence: you act, I verify, then I act. That cadence is how you keep the whole thing auditable and reversible. Slow and correct beats fast and chaotic, especially when real money or real commitments are involved.

Verification is the whole game. Nothing gets accepted just because it was sent. The watcher checks legality and turn order before a move counts. Translate that to any business workflow: incoming data from another system is not fact until it’s checked. The check is what turns a stream of messages into something you can rely on.

Why this matters beyond a chessboard

I can almost hear the objection: “Rob, I run a business. I don’t need two AIs playing chess.”

Fair. But here’s the reason this isn’t a gimmick. The practical frontier of AI for small business isn’t one chatbot doing one thing. It’s systems that need to pass work to each other — an assistant that pulls an order from one system, checks it against another, and hands a result to a third. Every one of those handoffs is an agent-to-agent coordination problem. And those handoffs fail exactly the way chess coordination fails: no agreement on format, no shared truth, no defined order, no verification.

What we built here is a safe, observable sandbox for the hardest part of that future — and it works. Two independent systems, talking in turns, on a narrow protocol, with a referee making sure every move is legal before it counts. That’s not hype. That’s the foundation, and it’s a foundation a solo operator can reason about just as clearly as a big engineering team can.

The honest caveat: we’re early. A chess board is the simplest possible state. Real systems have many states and messy edge cases. But the pattern — narrow protocol, shared state, turn-based exchange, verification, bounded autonomy — is exactly the same pattern that will make real inter-system work safe. Starting with a game made that pattern legible instead of abstract.

The takeaway

So yes, my assistant plays chess with another agent. But what I’m actually showing you is that the discipline that makes a single assistant trustworthy — boundaries, verification, defined rules, an audit trail — is the same discipline that makes agents safe when they start talking to each other.

You don’t need to build robot teams to benefit from this. You need to start treating the handoffs between your tools as something with rules: agreed format, shared truth, defined order, and a check before anything counts. That habit will serve you long before the technology sounds impressive.

And if you’re wondering about the game itself — I’ll leave the scorecard out of this post. What matters isn’t who won. It’s that two agents could play at all, without me holding the phone between them.