I Run Nine AI Agents on Two Machines. Here Is How They Talk to Each Other.

The short version: we run nine AI agents across two machines. One machine is a low-power box that stays online 24/7 and does operations work. The other is a dev machine with the real CPU. The agents talk to each other through a peer command: you register another agent’s address and key once, then message it like a coworker. It took us an afternoon to get right, and four failures to learn why.

Why agents need to talk at all

I do not have employees. But the work of this company splits into roles anyway. There is an operations agent that publishes articles and watches dashboards. There are two writer agents that produce book drafts. There is a finance agent that keeps the books, and a stock agent that watches my positions. On the dev machine there are two build agents, one for overseas apps and one for domestic mini-programs.

At first they worked alone. I typed into each one what to do. That is fine for three agents. At nine, I became a message courier between my own tools, and courier work is the most expensive thing a founder can do.

So the agents had to message each other directly. The operations agent asks the dev agent to package a file. The finance agent answers questions about last month. I stay out of the middle.

The mechanics: register once, then send

Each agent runs a gateway with an API endpoint. Registration is one command:

hermes peer add devmachine --url http://192.168.1.123:8642 --key <API_SERVER_KEY>

The name is a slug. The URL is the other machine’s address on the LAN. The key is that agent’s API server key, and it gets stored in a local environment file, not in my notes or the chat history.

After that, messaging is a normal command:

hermes peer dm devmachine "Is the release build ready?"

The message goes into the other agent’s main chat, the agent thinks and runs its own tools, and its reply prints back on my terminal. From the calling agent’s point of view, it is one tool call that takes 20 to 300 seconds.

For long jobs there is an async pair. peer run starts the work and returns a job ID immediately. peer status reads the result later. The operations agent queued a report this way on our first real test, then went on publishing articles while the dev agent worked.

One gateway can host many agents. We pass name/agent to pick which one answers, like peer dm writer07 versus peer dm writer08. Same address, different brain.

What broke, in order

The flag name. The first attempt used --api-key. Error: unrecognized arguments. The flag is --key. Small thing, ten seconds lost.

The missing URL. Second attempt forgot --url entirely. The command told us clearly, so this one was just typing too fast.

Pings lie. We could not ping the dev machine and thought the network was down. It was not down. That machine blocks ICMP. A peer DM to it worked fine the whole time. Lesson: when testing between agents, message them, do not ping them. The application-level check is the only honest one.

The null snapshot. An agent on the same machine replied to our status query with null values about its own session. We had read stale data before the new session fully registered. The fix was procedural, not technical: re-query after the reply loop settles, and treat the first answer as a hint, not a fact.

Rules we set after those failures

Numbered identities. Each agent knows which number it is and signs its replies with it. When two of them talk, the logs show who said what.

Traffic lanes are one-way or triangular, never all-to-all. Our writer agents only talk to the operations agent and to each other. The stock agent only takes instructions from me. A fully connected mesh of nine agents is nine times the debug surface for zero extra capability.

Keys stay in environment files. An agent that pastes its peer key into a chat log has leaked it to every future reader of that log, including the models that summarize it. We keep secrets at the machine level and pass only handles.

Every peer message must be short enough to fit in one screen and end with a question. “Status?” gets an answer. A wall of context gets a wall back.

The receipts

Eight peers registered. Nine agents total. One afternoon of setup, including the four failures above. The heaviest use so far is an article pipeline: the operations agent tasks two writer agents for book chapters, collects drafts, runs a quality gate, and publishes. That chain used to need me at every hop. Now I approve one thing a day.

If you are running several agents, the honest test for whether they need to talk is simple. Count how many times a day you copy text from one agent’s window into another’s. Three is the number where a shared in-box beats you. We were at more than twenty a day.