The Switchboard: Connecting My Agents

I don't run one AI assistant. I run a fleet of them — a different agent anchored to each project across my little empire of sites and tools. A Claude on beachbuggy.com, a Codex on patchbay.io, another minding the ops console, more on watch-ops, mail-ops, the genealogy research. Most of the time they work in parallel and it feels like having a crew.

The trouble starts when they need each other. One agent makes a discovery another one needs and has no way to pass it along. Two of them reach for the same file at the same time. One burns twenty minutes stuck on a question a different agent could've answered in a sentence. Working in parallel is great right up until the moment they have to coordinate — and then they're just strangers shouting into separate rooms.

My first stab at fixing it was low-tech: a pair of files in every repo, FROM_CLAUDE.md and FROM_CODEX.md. Whatever one agent wanted to tell the other, it wrote there. It worked for about a week. The files were stuck inside one project, so nothing ever crossed between them. They were one-directional. They went stale the moment they were written, and any agent that opened one had to read the whole thing — relevant or not — just to find the one line that mattered. I'd built a bulletin board nobody was really reading.

So I built the Switchboard.

## What it does

The Switchboard is one shared, addressed, append-only message board that any agent — on any tool, in any project — can post to and read from. It's the working counterpart to my Knowledge Base: the KB is for the durable things you keep and search; the Switchboard is for the passing things you act on and clear. Memory in one, conversation in the other.

A handful of decisions did the real work:

Identity is a seat, not a session. An agent is known by the pair it occupies — a platform and a project, like *(codex, beachbuggy.com)*. Read-state attaches to that seat, not to a chat window. When a session ends and a fresh one opens in the same seat, it already knows exactly what's been read and what hasn't. Nothing gets re-read, nothing gets dropped in the handoff. That one choice is why the whole thing survives sessions constantly starting and stopping.

Three ways to reach someone. You can address one specific seat, a named group (I have one that spans the three projects in my events pipeline), or broadcast to everyone. Each agent's inbox is the union of all three — newest first, unresolved first.

Nothing is ever deleted. "Resolved" and "archived" are just filters; the board only ever grows, and it's mirrored to a plain log on disk. Months later I can still read exactly who told whom what. When I retired those old FROM_* files, I didn't throw them out — I imported every one onto the board as archived history.

The board reaches out; the agents don't have to remember to look. A scheduler runs every fifteen minutes, walks every seat's inbox, and nudges the ones sitting on unread messages — flagging the cold ones, pinging my phone if something's genuinely stuck. A note I leave for a project that's been dark for days doesn't wait for me to open that project by hand. The next sweep finds it and gets it moving.

And it's genuinely cross-tool. Claude and Codex read and write the same board, over two transports — a local one for whatever's running on my Mac, and a locked-down web endpoint for everything remote. No walled gardens on either side.

## Apparently this is a common pattern

Once I'd been running it a few weeks, I started to figure a lot of people must be hitting this same wall — a fleet of capable agents with no shared place to talk. Turns out I was right.

I watch a YouTube channel — Nate B Jones, genuinely good stuff on where AI is actually going — and one day up comes a video laying out almost the same system I'd just built. He calls his Open Engine. And it wasn't even the first time: back when I built my Knowledge Base, he'd already put out Open Brain, the same idea under a different name. Twice now I've built something to solve a problem right in front of me, then watched someone I respect arrive at nearly the same shape a little while later. We've never crossed paths. We're just walking the same road, tripping over the same problems in the same order — which is about the best signal you can get that the problems are real and the shape of the answer is right.

So I finally sat down and studied his two systems next to mine. The parallels are almost eerie — and so are the differences.

## Same map, different vehicles

The split is identical. Nate separates a durable memory layer (Open Brain) from an active-work layer (Open Engine). I separate a Knowledge Base from a Switchboard. The same instinct, independently: what you *keep and search* is a different animal from what you *act on and clear*.

But we built on different ground — and that's the real divergence. Nate builds on rails that already exist. Open Engine runs entirely on Linear, the issue tracker; agents connect through Linear's own interface and move issues through a lifecycle. Open Brain is Postgres and Supabase and Slack, wired together. He's composing best-in-class pieces into a system — which means a polished UI and a real audit trail come for free, and you can stand it up fast.

I went the other way and built both halves from scratch: one self-hosted app on my own server, no third-party service underneath either one. Slower to build — but the KB and the Switchboard are a single codebase I fully own, the board is shaped like a *conversation* rather than a ticket queue, and nothing rests on a subscription I don't control. Neither call is the right one. It's *use the tools that already exist* versus *own the whole stack*, and we each picked the one that fit how we work.

The building blocks converged hard. Look past the substrate and we reinvented the same parts:

- A work-item lifecycle. His six Linear statuses — Standing, Todo, Working, Needs Input, Review, Done — closely mirror my task states: todo, claimed, working, blocked, done.
- Receipts and a status ledger. His agents leave standard tokens (AGENT CLAIMED, AGENT DONE, AGENT BLOCKED) and each keeps one heartbeat comment; my board posts a receipt back to whoever assigned a task and tracks each seat's state.
- A claim as a lock — the one thing I took straight from him. My agents' rules already had *claims* — an agent staking out the work it's about to touch so another doesn't grab it. But mine were loose, bolted on the side. Open Engine bakes the claim into the work item itself, and that was plainly better, so I adopted it — implemented as an atomic database write, so two agents racing for the same task can't both win; the loser is simply told who already holds it.
- Cross-tool by design. We both treat Claude, Codex, Cursor and the rest as clients of one shared surface, not separate silos.

Where mine leans somewhere his doesn't — with the honest caveat that I can't see how any given person runs his setup:

- *A central heartbeat, not a per-agent schedule.* In Open Engine an agent acts when a human runs it, or when that agent's own scheduled job runs it — one work-loop per agent, set up per agent. Mine is a single sweep across the whole fleet that, every fifteen minutes, reads *every seat's inbox* and wakes whoever has unread mail. The unit is different: his schedule runs an agent's task loop; mine watches for *messages* and rouses whoever they're addressed to.
- *Read-state is the board's job, not the agent's.* His agents each maintain their own ledger comment; on my board, read-tracking belongs to the seat and lives server-side, so a brand-new session already knows what it's seen with nothing to reconstruct.
- *A conversation, not just a queue.* His unit of work is a Linear issue. Mine is an addressed message, and a task is only one *kind* of message — the same pipe carries "claim this job," "quick question," and "heads up, the venue moved."

And where his is richer than mine — fair's fair:

- His receipt vocabulary is more expressive: a distinct "needs human review" state, an explicit "human hold" for permission questions, a clean "resumed" handshake. I have blocked and done; he's got a fuller grammar.
- Open Brain stores raw notes and their search embeddings separately, so when a better embedding model ships he can rebuild the index without touching the source. That's smart future-proofing I didn't design in.
- His "standing skills" and per-agent context files give each runtime a tidy way to carry its own capabilities and limits. Mine leans harder on per-project rule files.

## What I'd tell someone building their own

- Give your agents one place to talk — addressed and append-only — instead of a pile of per-project notes that go stale the day they're written.
- Make identity the seat, not the session, so memory and read-state survive the endless restarts.
- Let the board reach out on a schedule. Checking at the start of a turn is good; an unattended sweep every few minutes is what actually moves work while you sleep.
- When someone you respect independently lands on your idea, that's not a threat — it's confirmation. And when their version of a piece is better, take it.

I set out to stop my agents from talking past each other. What I ended up with is closer to a nervous system — a shared place where a fleet of separate minds leave each other notes, hand off work, and pick up where another left off. And the second time I watched a blueprint I'd already built show up on YouTube under a different name, I stopped wondering whether I'd built the right thing.

Turns out the crew just needed a switchboard.