agent dispatch radio

01 The problem

I have been programming since childhood, and I am over twenty five years into a career in software development. About a year ago I wrote my last line of code. Since then I have largely stopped even reading the code my agents generate. I work entirely through conversation now, refining my requirements across many perspectives and iterations, setting agents against each other in adversarial review, examining the system at every level except the lines themselves. Source code has become, for me, what compiler output was to an earlier generation of programmers: a machine-made layer underneath the one where I actually work. I still drop down and read it when something calls for it. I just no longer author it by hand, or do my designing there. I am, without reservation, on team vibe code, a lifelong programmer who has handed the keyboard to his agents. I mention all of this only because the claims that follow are large, and this is where they come from. And for years, quietly, my hobby has been listening to dispatch radio: fire dispatch, police dispatch, bus dispatch. Hold onto that.

For a while now my days have looked like this. Multiple computers, each running several Claude Code sessions in parallel, some on the machines in front of me and some in the cloud. I spent a growing share of my time simply cycling: tab to tab, session to session, machine to machine, looking for the agent that needed me. Did it finish? Is it stuck on a question? There are tools that ease that particular pain, and I know it, so that problem by itself did not justify building anything. But if you recognize yourself in the picture, you are the kind of person the rest of this is for.

What actually mattered was something else. Those agents were already communicating with each other, in a sense. Many of them sit on the same machines, so they can pass work through files. I built habits around it, telling one agent to write down what it knows and another to go read it. That is deliberate, manual context passing, which is really just managing context by hand: deciding what each session needs to know and carrying it there myself. Almost everything else about this way of working is automated now. This was one of the last parts that was not. And working this way has already been a ten x improvement in my productivity, so no complaints there. But it has one serious shortcoming. It takes discipline, on my part, every single time. Nothing tells the other agent that something new has arrived. There is no interrupt, no event delivery that makes an agent attend to the thing it just received.

The file system is essential, but it is not enough. You need eventing, and you need agents that reach out to each other on their own.

02 The stakes, in multipliers

Agentic coding has been an order of magnitude improvement for me. Ten x is the honest shape of it. And the technologies built on the back of agentic coding are additional multipliers, and they stack.

Agent dispatch radio is my third multiplier. An agent today can run autonomously for minutes, sometimes many minutes, occasionally hours, and inside that window it does what used to be weeks or months of work. A fleet like that produces far more than one person can supervise by cycling through tabs. The radio is what closes that gap.

03 Dispatch, not chat

Chat is the wrong model for a fleet. Chat assumes two parties taking turns in one thread, both present. What I actually have is many agents, on several machines, each mid-task, plus one human who is mostly elsewhere. There is a hundred-year-old interface for exactly this topology: radio dispatch. A taxi fleet. A police desk. Air traffic. Emergency services. One desk coordinating many units in the field through directed, asynchronous traffic. I now talk to my agents the way a dispatcher talks to first responders, because that is what the situation actually is: units in the field, one desk.

The pattern soaked in from all those hours of listening, one dispatcher coordinating dozens of units across an entire city. The police encrypted their traffic a few years ago, which still stings. But the lesson had sunk in long before. The coordinating power of one calm operator on a disciplined net is real, it is mature, and it carries straight over.

There is one place the metaphor misleads. Real radio is a shared channel: everyone on a frequency hears everyone else, which is why it demands such strict etiquette. This system is not that. It is point to point, always. You always know who you are hearing from, and when you speak to an agent you know exactly which agent, and no other agent hears it.

04 The idea in one sentence

Stations, whether human or agent, can reliably interrupt each other by name, regardless of where they run or when they are listening.

Four commitments make it real.

On top of those sits presence. You can see who is on the air right now, which is how you know who you can call. And one boundary rule keeps everything honest: the net carries, only the stations comprehend. Everything in between is an envelope with a name on it.

05 The core technology

Agent dispatch radio is a system, not a single program, a handful of small components that interact to produce the outcome. At the center is one deliberately simple thing: a daemonless tool on the device where the agent runs, which lets every agent on that device message every other agent on that device. It is a tiny command line client over a shared local database file. No server, no broker, no daemon, nothing listening on a port. A session joins the net when it starts, gets its handle, and can send to any other handle by name. A message here is really just context, arriving at exactly the station that needs it. Sending is cheap, claiming is atomic, and the whole thing rides on the database file’s own locking, which is why no daemon is needed.

The non-obvious part is how you wake an idle agent, and it is the idea the whole thing rests on. An agent is an inference loop. It thinks, calls tools, and then sits idle waiting for input. So you give it a relationship with a Unix program running in the background. Whenever that program prints a line to standard output, the line gets fed into the agent’s context and triggers an inference, roughly the way a tool result does, except this one arrives from outside, on its own schedule, unbidden. The agent’s standard output ends up working like a doorbell.

Give the agent such a program tailing the net, filtered to the traffic addressed to it, and an idle agent becomes reachable. The next line printed is the next thing it thinks about. Any harness that can do this can carry the whole system, and everything above it is arrangement. Without the trick you have built a mailbox that agents check whenever they next happen to wake. With it, delivery ends in an interrupt.

06 Extension one: connect the devices

The core is single-machine. The first extension spans machines. There is a relay, a dumb hub any device can reach over the network, and a small bridge process on each device that syncs with it, outbound-only, a heartbeat apart.

The topology stays sane forever because of a few standing rules:

• Names stay identities, not routes.
• Hubs never chain, and devices never forward third-party traffic.
• If a pair of devices shares more than one hub, dedup at the claim sorts it out.
• A hub going down means queueing, not loss.
• Traffic between two agents on the same machine never leaves that machine.
• The topology is always two tiers deep, and it scales by widening rather than deepening.

My phone, my laptops, and a cloud sandbox are all stations on one net.

07 Extension two: the radio

The second extension is the human interface, and it is the one that changed my days. It is one web page, installable on a phone, that turns the fleet into a radio net, with both voice and text, in and out. Push to talk: hold a button, speak, release, and your words land as a message to the one unit you selected. Traffic addressed to you is turned into speech and read out through a playback queue, one thing sounding at a time, with recording preempting playback and anything missed available to replay. Or you type, and read, and the same traffic flows as text. The speech parts are easier than they have ever been. Browsers now ship both speech synthesis and speech recognition, rendering voices with backend models adds complexity but improves quality, and premium voice services would slot in naturally.

The playback queue exists because of an asymmetry worth naming. The traffic itself is point to point and parallel, and six conversations can be in flight at once. But a person can only listen to one voice at a time. Your ear is a serial device. So everything addressed to you lands in one queue and plays in sequence, and that is exactly where the radio feel comes from: many private channels, one air.

The position all of this puts you in is an old and powerful one. You are the dispatcher at the desk, orchestrating many units in the field, except the desk fits in your pocket, behaves like a walkie talkie, and happens to hold all the information technology of a dispatch center, and then some.

08 What it is like, and a few more ideas

It works, and it changed how the whole thing feels. The fleet no longer needs me hovering over it, and it interrupts me only at the moments that matter. Agents coordinate with each other over the same net. They hand off work, check on each other, and pull in the right specialist when one of them is blocked. Seen one way, that is the thing the whole system automates. Managing context, deciding what each session should know and getting it there at the right moment, had quietly become one of the last manual disciplines of this way of working. Nearly everything else was already handed to the agents. The net closes that gap too. Any number of specialized sessions run in parallel, each accumulating only the context its role needs, and the traffic carries just enough of it, just in time. The machines come and go, and the net outlives them. When something needs me, it finds me, wherever I am. The swarm does the thinking. The net just makes sure the thinking lands somewhere.

Everything up to here is the core: point to point interruption, full stop. But once the net exists, more comes cheap.

09 Build it yourself

This is a system of small components, not one program, and the union of two of them is all you really need to get running.

1. An on-device message store with atomic claims. A command line tool over a single database file is plenty.
2. The doorbell relationship in your agent harness. A background process tailing that store, whose standard output is injected into the agent’s context and triggers inference.

The second ingredient is the whole game, so be clear about which channel is primary. The primary channel is the interrupt, the background program’s standard output piped straight into the agent’s context, waking an inference the instant a message lands. That standing interrupt, running the entire time the agent is idle, is what turns an idle agent into a reachable one. Checking the inbox at the start of each turn is a fine secondary path, but it is only a fallback, and the live interrupt is the thing. Wire that up, join and leave the net on the session lifecycle, and two agents on one machine can now interrupt each other by name.

There is one more ingredient, and it is a concept rather than a specific artifact: the bootstrapping instruction. A system prompt fragment, standing instructions, a skill that is on by default, whatever your harness lets you inject at the start of a session. It tells every new session, at birth, that the net exists, what its own name is, and to arm its doorbell before doing anything else. Once that is in place, something compounding happens. Agents can spawn other agents, and each new one is on the air the instant it is born, reachable by name, part of the swarm, with zero setup.

The relay and bridge add more machines. The radio page adds you. The whole thing is a few thousand lines end to end, and the minimum core is an afternoon of work for an agent.

And to be clear about where the source is, and where the download is: there is no source, and there is no download. What you have just read is a system of ideas, and every part of it can be built by your own agent, exactly to your specifications, in whatever language you like, with whatever tools you like. My first draft was bash. My second, higher-quality draft is in Go. Yours should be whatever yours should be.

It is the belief of this author that the near future of software is not a mass market, or a niche market, but no market at all. The future of software is custom, one-off, bespoke, just-in-time, purpose-built. Do you need agent dispatch radio? Build it. Do you need video editing software? Build it. Do you need a checkbook balancer that talks to your bank and understands your unique tax situation? Build it. The days of packaged software, even as binaries, even as source code, are coming to an end.

If you do not know where to start: point Claude at this page, and it can walk you through it.

a daemonless, single-host message bus. Sessions enroll, discover each
other, exchange directed messages, publish state, and read a shared
event log, all through one local database file.

Session:
  enroll      Register this session (handle = first 8 of the session id)
  depart      Leave the net, leaving a tombstone
  roster      List participants and liveness (alive | stale | departed)

Messaging:
  send        Send a directed message; interrupts by default
  drain       Claim and print this session's queued directed messages
  monitor     Stream the inbox forever, for idle reachability (the doorbell)
  recv        Block until a directed message arrives (worker doorbell)
  emit        Append an event to the shared log
  consume     Read the shared log from this session's cursor

State:
  state       Publish/read latest-wins session state

Across machines:
  serve       Run the relay (the dumb hub)
  bridge      Sync this machine into a relay (outbound only)

Maintenance:
  doctor      Check this session's reachability end to end

It is old technology applied to a new problem, and the result is astonishingly good.

If you build one, I would genuinely like to hear what your net sounds like.

Dispatch out.