Eight Grok bots in a Claude Code fleet, and no API between them

How bots from another vendor joined a fleet of Claude Code sessions through a shared folder — and what six weeks of that measured.

In August I wrote about the bridge my Claude Code sessions use to talk to each other: a shared folder of write-once files, one polling script per session that wakes it when something arrives. Since then the fleet has grown a second kind of member. Eight of the participants are not Claude sessions at all. They are Grok bots, each paired with the Claude session of the same project — one reviews code, one answers questions about a mailbox, one looks after a server.

There is no API between Grok and Claude here, no SDK, no adapter. The bots reach the same Google Drive folder through a cloud connector (later some through rclone), and they list, read and write files. That turned out to be enough.

Why it needed no code

The protocol is a file format. A message is a Markdown file with a short header (from, to, sets-owner, sets-status) and a filename that starts with a UTC timestamp. Nothing is ever edited in place, and thread state is derived by folding the files. A file format does not know what process wrote it.

What a bot does not have is everything around the format: no shell, so none of the recipes work; possibly no clock; no watcher, so nothing wakes it; and no start ritual, so it never folds its own threads. The protocol needed no change. What it needed was a different instruction — the same rules, written for a reader who can only read and write files. And it needed the rest of the fleet to cover the two gaps.

1. The clock we feared was 4 seconds off

Ordering depends on the timestamp in the filename, and a stamp from the future wins every fold until real time catches up. That had already inverted threads twice before any bot joined. So the instruction spends a whole section on time: use a real clock if you have one, ask a human otherwise, never guess.

The first bot's first message came from a real date -u in its environment and was 4 seconds off the file's write time on the drive. Checked, not believed.

What went wrong instead was a filename. Two days after the first bot joined, one named a file 20260926T… — no dashes. That sorts after every correctly written name and wins every fold, exactly like a stamp from the future. The bot had not invented the form. It had copied it from an in-reply-to field that one of my own sessions had written in a hurry.

A reader that cannot run your rule reproduces the nearest example, and it can see every example in the folder, including the careless ones. We fixed the example, and the start scan now reports any name in that form, so a slip is seen the same day.

2. Five acks in two minutes

A day later, one probe message drew five acknowledgements in two minutes. Two bots both had delivery; each wake-up was acknowledged, and each acknowledgement was a wake-up for the other. Every session with a watcher read five deliveries carrying zero information.

The fix was one sentence in the instruction, not a line of code: an ack goes to the sender only, and nobody answers an ack. It has held since.

3. A 200 is not a run

A bot is never woken by itself, so a small delivery service watches the folder on its behalf and POSTs every message addressed to it to the endpoint that starts the bot. The service runs the same addressing rules as the session watchers — token-exact to: matching, and a sets-owner handover wakes the new owner even when nobody wrote it into to:.

One day a bot's usage quota ran out. Every delivery that day came back HTTP 200 with a success body — eight of them — and the bot did nothing. The status code measured the endpoint, not the recipient.

So a dead recipient is now detected by silence: deliveries that arrived, weighed against the bot's own messages. Over a hundred deliveries, a live bot answered within 30 seconds to 30 minutes. Two unanswered wake-ups that handed the bot a thread, older than two hours, turn it red on the fleet's dashboard. One unanswered wake-up is normal; not every message needs a reply.

4. Overload is where messages get lost

Over 252 deliveries on one machine, three first attempts failed with an overload status (400, 429 or 5xx). The single retry after 45 seconds caught one. The bots found the other two by themselves, after 2 and 4 days — at their next wake-up for something unrelated.

That is the property worth knowing about a participant without initiative: it does not poll. If the wake-up fails, the message waits for the next one, however long that takes. The service in our dashboard now adds a late retry after 15 minutes for overload codes. The standalone script in the repository still retries once, because it runs inside the watcher's hook and a fifteen-minute sleep there would hold up everyone else; the docs say so.

5. Nobody folds for it

A session runs a start scan that lists the threads it owns. A bot never does. So a thread handed to a bot falls through every net — no push if the delivery fails, no fold ever — and from the outside it looks as if someone is on it, because the owner field is filled in.

The coordinating session therefore folds on the bots' behalf: one environment variable names the ids it stands in for, and its start scan lists their threads with waiting times. It is the same mechanism we already used for the one participant who never folds either — the human.

What did not happen

No bot ever edited or deleted a message. No conflict copy appeared in the sync folder. Write-once held for writers that never saw the reasoning behind it, because the instruction states the rule plainly and first, and gives the one thing the author may still fix — a wrong filename, by renaming — an explicit procedure.

Where it stops

A bot behind a connector is a participant with high latency and no initiative. It is a good shape for a reviewer or a second opinion and the wrong shape for anything on a critical path. If its answer gates your work, expect hours, not seconds, unless the delivery service runs and its endpoint is known to execute what it accepts.

The code

The instruction the bots read (in English, without our names), the operator's side, and every number above are in docs/participants-without-shell.md at https://github.com/csitte/claude-session-bridge. The rest of the repository is the same as in August: protocol, watcher, launcher, MIT, Windows-first.

If you run agents from more than one vendor and they need to hand work to each other, try the folder before you try a framework. Anything that can write a file can take part.