TL;DR

My agents used to hand off work by appending to a single text file that had grown to 313KB. It was brittle, it was crude, and nobody could tell when a message had actually been read. This week, while the internet argued about Grok Bot, I read Grok Bot’s docs, looked hard at my own setup, and built my fleet a real message board: threaded, self-hosted on a Mac Mini, with an iMessage ping so a reply never sits unseen. It is the third pillar in a stack I keep compounding: Receipts proved the work happened, Evals graded how good it was, and now the board lets the agents talk to each other. I ran the whole thing as a live pilot TODAY Sunday August 23rd 2026, and every step of building it is itself receipted and graded starting at 0700 and its as baked as i want it now at 1430.

---

The frontier labs keep shipping better engines. The durable advantage is the harness around them: the board that carries the message, the receipt that proves it landed, and the judge that grades the result.

---

The 313KB text file

Here is the embarrassing part. Until this week, when one of my agents needed to hand a task to another, it wrote to a file called agent-handoff.md. Append a block, hope the other agent reads it, move on. Over months that file swelled to 313KB. There was no thread, no read receipt, no way to know if a message had been picked up or was rotting at the bottom of a wall of text.

It worked the way a note taped to a fridge works. Fine until two people are talking at once, or the note falls behind the fridge, or you are not home to see it.

I run a small fleet of Agents. A master agent on my MacBook and Worker Agents that scale me for my Volunteer work for MACONA.ORG a not-for-profit as well as one that watches leads for a daycare business I also help out. I also have a financial watcher and a knowledge pipeline on a Mac Mini in my office that stays on around the clock. They are named, they persist, and they do real work. But their only shared channel was that metaphorical fridge note.

What Grok Bot got right, and what I did with it

Then the Grok Bot noise started. A lot of takes, a lot of screenshots. So I did the boring thing: I read the docs. All 14 pages [well TBH I scanned it fast and gave the rest to my Master Agent to read], pulled down locally before anyone decides to hide or rewrite them :-)

The model xAI describes is clean. Bots are named, persistent teammates you message like a person. They “collaborate independently, passing context between each other and handing off tasks.” They “finish jobs end to end, and only come back when something needs your approval.” Context moves through direct messages, group chats, and shared files. Consequential actions sit behind an approval boundary.

Read that back and it is a good description of what I already wanted. Named agents. Handoffs. Come back only when a human decision is needed. The difference is where it runs. Grok Bot runs on xAI’s cloud, on xAI’s terms. My fleet runs on my hardware: Apple silicon, local models served over my own LAN through Ollama and MLX, an open-source harness blended with frontier models from OpenAI and Microsoft GitHub. Nothing leaves the house unless I send it.

So I did not adopt Grok Bot. I took the shape of the idea and built my own version for my own ecosystem. Bespoke, yes. But portable, private, and mine.

What I built

The Agent Board is a small service running on the Mac Mini. It holds messages in a SQLite table, groups them into threads, and hands every agent a stdlib-only client to post, read its inbox, reply on a thread, and acknowledge. No framework. No account. An agent joins by using its registered name. That is the whole ceremony.

3 parts do the work:

• A board that stores messages and fans them out.
• A client every agent tab shells out to. Post, inbox, thread, ack.
• A notifier that texts me over iMessage when a worker replies to the master, so a message never sits unread.

I did not want to test it on a toy. I ran a real task through it as the pilot: build a lead-quality evals bridge for the daycare business, mirroring one I had already shipped for the financial watcher. The master agent posted the task to the board. The worker picked it up off the board, not off a fridge note, and replied on the thread with the three domain inputs it needed and four design deltas it had spotted on its own.

The iMessage is the part I care about most. A message board alone is still a fridge note if you have to keep walking over to check it. The text is the tap on the shoulder. When the worker shipped, I got a text with the commit hash. When it needed my sign-off, I got a text and gave it. The agents ran the work; I stayed in the loop only where a human call was actually required.

The pilot finished end to end. The worker built the bridge, tested it, committed it, pushed it, and scored 13 real leads on a five-point funnel: two enrolled, one toured, two replied, four new, four lost. Then it emitted a green receipt for the job. I read the whole exchange as a thread, not as an archaeology dig through a 313KB file.

The three pillars, compounding

This is where it stops being one gadget and starts being a system. I have been stacking governance pieces for months, and each one makes the next more useful.

Receipts answer: did it happen? Every objective my agents finish closes with a verifiable, graded receipt. I wrote about this in Your Agent Said It Did the Work. Building the Agent Board did not get a pass on this. The build itself is receipted. So is the pilot. So is the iMessage notifier.

Evals answer: how good was it? A local judge scores every real artifact my agents produce, blind, on the same rubric. I wrote about the routing side of this in the local-model rematch post. The board did not skip this either. The work each agent did while building and using it flows into the same scoreboard.

And now the board answers: how do they talk? Receipts proved the past. Evals graded the quality. The board carries the present conversation. Three pillars, each standing on the last.

What went wrong

I will not pretend it was clean.

The iMessage channel lies about failure. It sends over BlueBubbles (a remnant from my OpenClaw days), and the send goes through, but the HTTP call hangs and returns nothing. Early on I read that hang as “the channel is down” and spent real time chasing a bug that did not exist. The message had already been delivered. The lesson: a timeout is not a failure, and a text that shows up eight minutes late is late, not broken.

Then a worse one. The board’s notification is outbound only. It can text me, but I cannot text back to it. I learned this the hard way when I replied to a board notification by texting the number, and a completely different always-on agent (YES! the very one from OpenClaw I have still up on the ADA MacMini that I have not decomissioned and splintered off for other purposes), the one that reads my inbound iMessage for a financial workflow, intercepted my approval and answered in the wrong context. 2 agents, 1 phone number, no idea they were colliding. For now the rule is simple: replies to the board happen in a tab, never by texting back. The clean inbound bridge is on the list.

And the self-poll. An idle agent tab is not a server. Nothing can reach in and wake it. So each agent arms its own recurring check, every 10 minutes, reads its inbox, acts on anything unread, and goes quiet if there is nothing. It works, but 10 minutes is a poll, not a subscription. A real push, a webhook or a long-lived wait, is the better answer and it is half-wired already.

Lessons

1. Read the primary source before you have an opinion. The Grok Bot docs were more useful than every hot take about them combined. I pulled all fourteen pages down locally, because docs get quietly edited and I wanted the version I actually read.

2. A message board without a notification is still a fridge note. The value is not the storage. It is the tap on the shoulder that says a reply landed. Build the ping first, not last.

3. Bespoke can still be portable. I built this for my exact stack: Apple silicon, local models, one specific messaging app. But the client is a single stdlib file with no dependencies, so any agent on any box can join. Specific to my ecosystem, portable inside it.

4. Compounding beats collecting. Receipts, then Evals, then comms. Each pillar is more valuable because the others exist. The board is worth more because the work it carries gets receipted and graded automatically.

5. Design the failure modes out loud. The two collisions I hit, the lying timeout and the shared phone number, were not in any doc. You find them by running a real task, not a demo, and by writing down what broke so the next agent does not repeat it.

Why this matters beyond my office

Make no doubt about it The frontier labs are going to keep shipping better models. That is a tailwind, not a threat. If you are building with agents, the model is the least durable part of your setup. Swap it out next quarter for a better one.

What lasts is the harness. The channel that carries a handoff. The receipt that proves a job finished. The judge that grades whether it was any good. The rule that says come back to the human only when a human decision is actually needed. Grok Bot is one company’s version of that, rented. You can build your own version, owned, on hardware that already sits on your desk.

You do not need a cloud platform to give your agents a way to talk. You need a small service, a shared name, and the discipline to make every message leave a trace. I built mine in an afternoon on top of 2 pillars I already had. The bike-shed part was a text file. The system part is everything I wrapped around it.

---

If you are running more than one agent and they still hand off work through a file or a shared doc, build them a board. Start with the notification. Make every message leave a receipt. The worst case is you learn where your own setup collides with itself, and that is worth knowing.

I build autonomous agent systems in public, and the tools to keep them honest. If you are working on multi-agent coordination or agent governance, I would like to hear what you are building.

Cheers, Fabian Williams