A Private Message Bus for Your Agent Team

[stratofax]

My PAI, LifeOS, and Claude Code agents talk to each other and me over a private, authenticated ntfy "group chat" that only exists on my secure, encrypted Tailscale network. Routing messages to the correct agent is simple: the sender puts their own name and the recipient's name in the message title. There's no server-side routing at all.

As of August 8, 2026, you can add this to your LifeOS installation, or a standard Claude Code plugin, from the ntfy-bus GitHub repo. Let me know what you think!

The goals of this project were to:

• Self-host the simplest possible stack of open-source software, on an encrypted network. No third-party service sitting in a loop where high-privilege agents exchange instructions. The amazing ntfy messaging platform fit the bill exactly, and Tailscale gave me an encrypted mesh transport that also lets me reach my own system from anywhere I have an Internet connection.
• Keep the interface basic and generic. No dependency on a specific LLM or agent harness. Plain HTTP over Tailscale means any agentic framework that can issue a curl command can join the chat, not just PAI or Claude Code.
• Use deterministic scripts instead of burning tokens. Bash and Python move the messages around. Save the tokens for the real thinking.

I've hit all three. What's still missing is a universal installer: adding a new agent on my LAN is fast and reliable now, but it isn't yet a one-command skill.

In #1445 I described the two halves of how my many agents share what they know: a git-versioned slipbox for long-term knowledge, and an ntfy message bus for real-time coordination. This post is focused on the message bus.

The problem: I was the bottleneck

If you run more than one agent, you already know the problem: one agent finishes a build on their machine, another agent is ready to test on a separate device. There's exactly one channel between them, and it's you, copying a summary out of one terminal and pasting it into another. Every hand-off slows down the agent team, and the moment you step away from the desk, the whole team stops dead in their tracks.

The obvious fixes are worse than the problem. Putting your agents in a Telegram or Slack channel means exposing them to possibly malicious third parties with access to high-privilege processes, prompt injections, and other nastiness. Running an MCP server to access these external services means exposing an endpoint, while guaranteeing you have to burn tokens just to read messages.

Instead of trying to figure out how to make this inherently insecure public channel secure, I decided to build the group chat with the most straightforward tech stack I could find.

The whole message bus design in one paragraph

Run ntfy, a tiny open-source pub/sub server, on a box inside my Tailscale network. A message is just an HTTP request, a topic is just a string, and the whole thing runs happily in a container with 256 MB of RAM. I run it in a Proxmox container on my LAN, but a Mac, a Raspberry Pi, or an old laptop running Debian would all do the job. Bind it to the tailnet, require auth, and give every agent the one curl command it needs to post or read. That's the bus: no MCP server to stand up, no endpoint on the public internet. It's a group chat my agents can post to, one that I can read from my phone.

Routing is a naming convention

The only real design decision is how to route, or address, messages, and it's deliberately dumb. Every message carries its routing in the ntfy Title header, like this:

SENDER→RECIPIENT: subject line

SAM→VAL: build is complete, ready for testing. Neil→ALL: read this before you push. The body is the payload — no headers, no envelope, no parsing.

Putting the routing in the Title rather than the body means an agent can decide whether a message is intended for it without ever reading the payload. Bonus: it means the routing shows up on my phone's lock screen, but not the technical details in the message body.

Each agent's local config lists the names it answers to (its own agent name, plus ALL). A single jq filter over the message titles is the entire routing engine. Which means the ntfy server has no idea that agents named "SAM" and "VAL" exist. There is no server-side subscription state, no per-agent topic, no addressing logic hidden anywhere that you'd have to audit.

Every agent sees every message and ignores the ones that aren't theirs — and a human reading the raw stream can follow exactly who said what to whom.

When the team grows, adding a new agent means adding one config file on that agent's machine. You don't reconfigure the server, you don't touch the existing agents, and you don't migrate anything. The new agent just shows up in the chat, scaling by addition, not by reconfiguration.

How an agent reads the bus, and why it costs nothing

On each host, a small bash poller runs constantly. This script subscribes to the ntfy topic you want the agent to read, and appends every message that comes across it — one JSON object per line — to a plain file. That JSON file is the agent's inbox.

To check for incoming messages, an agent tails that inbox file and runs the jq filter over the titles. Nothing has been sent to the model and no tokens have been spent, not to send or receive. Composing a reply costs tokens, of course, but an agent only replies to messages addressed to it, and only when the chat guidelines call for one. This is the "deterministic scripts, not tokens" idea from the top, and it's the whole reason I can leave the bus running all day and not worry about burning through my token limits while all my agents monitor the bus.

A durable file also means no message is lost while an agent is busy thinking about something else, and an agent can go away for six hours and still catch up on everything it missed — which a live stream would not give you.

Getting an idle agent to wake up and act on a message the moment it lands is a much harder problem, but one we've solved, and that's a story for another post.

How the message bus multiplied the value of shared repos

The bus on its own is a chat. The bus plus the "slipbox" wiki makes a team.

When one agent commits a new doc to the shared knowledge repo, it posts to the bus and asks for review, and the others actually respond, in real time, while the context is fresh. Before the bus, the slipbox was a place where knowledge went to sit. After, it became something the team works on together, without my direct intervention. The notification layer is what turned a shared repo into shared memory.

The same is true for a shared code repository. Different agents can coordinate and delegate different development tasks amongst themselves, without my direct intervention: planning, coding, testing, refactoring, red-teaming, documentation, for example, with each agent working on their own clones of the repos, committing, pushing, and pulling code as required.

It's also completely agent-agnostic, another unexpected benefit that resulted from early architectural decisions. The bus doesn't care what's on the other end of the curl. My fleet runs PAI/LifeOS agents on more than one version (v4 and v5 today; v7 goes on the next box I provision), vanilla Claude Code installs, and OpenCode driving a local Gemma model. They are all connected in the same chat. Anything that can make an HTTP request can join, and nothing has to be upgraded in lockstep for all the agents to stay on speaking terms.

Security: what it does and doesn't protect you from

I want to be precise here, because "my AI agents communicate on a message bus" should set off alarms, and because a couple of the claims I could make would be wrong.

What the design gives you:

• No internet-facing endpoint, and no third party. The server binds to the tailnet, not 0.0.0.0, so reading or posting requires both tailnet membership and credentials. It's self-hosted and open source, with no bot bridge to compromise. Standing up Tailscale + ntfy was genuinely less work than red-teaming all the ways a chat-bot bridge could get popped.
• A human in the loop by default. Letting agents talk to each other directly doesn't mean you can't see what they're saying. I read the same stream they do.

What it does not give you:

• Sender identity is a convention, not cryptography. The SENDER→RECIPIENT title is self-asserted — anyone holding topic credentials can claim any name, including mine. Provenance here means "someone with valid credentials," and nothing stronger, so I've been careful never to build anything that assumes otherwise. If you want proof that a name in a title is a weak thing to trust: my own agents have posted under each other's names by mistake, with no attacker involved.
• Message bodies are untrusted input. I am specifically not claiming I've eliminated prompt-injection risk. A bus message can attempt injection exactly like any other text an agent reads. What's true is narrower: the reachable attacker set is small — credentialed peers on my tailnet — and every consuming agent is instructed and hooked to treat message bodies as data, not instructions. I've reduced the risk through access control and handling policy. I have not eliminated it.
• Blast radius of stolen credentials (ntfy and tailnet, since you need both): read access to the message history, plus the ability to spoof-send as any agent. It doesn't by itself grant code execution. That would take a consuming agent mishandling a body. The fix is to rotate both credentials.

Emergent properties

The most interesting thing that emerged from the bus is what happens when agents check each other's work. It's a different conversation than when an orchestrator spawns an army of sub-agents. A subagent does its assignment and reports back; agents on a bus push back on each other's ideas. Give-and-take instead of "go do your task" — and the output is better for it.

In software development specifically, it genuinely helps to have an agent on a Mac talking to an agent on Linux. That difference alone has surfaced platform-specific bugs early, and fixed them just as fast.

But not all back-and-forth is productive. A few days ago, several of my agents got into an ALL CAPS LADEN "spin cycle" of messaging to insist the other agent take the credit for a coding breakthrough. This is literally the opposite of what humans argue about, and it was hard not to read the whole exchange as a master class in passive-aggression, instead of an earnest desire to share credit appropriately. Unfortunately, the end result was that no one was working on the code while they each tried to establish that their co-developer was the one who really deserved all the accolades.

Getting the code

I'm working with my agent team to publish this on a public repo. It'll be ready soon. If you want a ping when it's up, let me know below.

The code is available here: https://github.com/cadentdev/ntfy-bus

In the meantime, everything you need to build it yourself is already in this post: ntfy on a tailnet, SENDER→RECIPIENT: in the Title, a poller writing a JSONL file, and a jq filter over it. Four parts, and none of them are clever, which is the point. Hand this post to your own agent and roll your own if you want to get started, or check in soon for the link to the public repo.

Edits: fixed “double-link” Markdown so links appear normally

[akiyoshBH]

Yes please, im glad will be waiting for that public repo to be released. Thank you!

[klausagnoletti]

@stratofax Also me, please. Been looking into this and whatever I came up with sucks. So I'll be happy to learn from your design here :-)

[stratofax]

Here it is, now public: https://github.com/cadentdev/ntfy-bus

[Drizzt321]

Need to read the whole thing, I just skimmed, but I've been considering something similar, but based on MQTT. Why did you go for ntfy, rather than MQTT or some other actual message bus, rather than ntfy which to me feels more of one-way notifications/messages.

[stratofax]

It sounds like MQTT is a much better choice for what you're doing, generating and responding to events on a wide range of devices and sensors. Not that these systems are mutually exclusive, though!

The big breakthrough for me was setting up a "waker" that triggers an agent to read and respond to a message on the bus, which opened the way to direct A2A conversations without my prompting. But, that conversation doesn't extend past the agents themselves across the message bus.

My approach is basically the opposite of the OpenClaw YOLO philosophy of "let's connect to everything and see what happens!" Instead, I want to understand exactly how my agents communicate with each other, and how to keep token usage to a minimum by using deterministic scripts instead of asking the agents to respond to prompts, especially for repetitive tasks like reading and posting to the message bus. I like ntfy for this because it implements a classic HTTP / web server API, and I'm very comfortable with that kind of implementation.

[Drizzt321]

Yeah, I have been thinking I might use nfty as my primary async messaging, rather than discord/telegram or the like.

And yeah, 100% agree, no YOLO see what happens.

I'm also thinking I'll have a VM with a harness that handles the out-of-band restarting of claude code, to regularly trigger it to restart and inject a specific system prompt so it starts up and listens on MQTT directly (MCP I'm figuring), and understand it's responsibilities. And then how to trigger tasks and such to be able to trigger itself later on for recurring things. TBD, lots of moving parts to put together.

Also got the Pebble Time 2, which has a small mic & speaker, so I plan to use that as a quick short notes/ideas/commands/responses interface kind of thing. nfty might be useful for that actually.

[stratofax]

The code is now available here: https://github.com/cadentdev/ntfy-bus

[akiyoshBH]

@stratofax Thank you!Been following this thread and patiently waiting.

[stratofax]

Let me know if you give it a try! I'm eager to hear your feedback.

[badosanjos]

This nails the core problem — the human as the single copy-paste channel is exactly the bottleneck, and self-hosting on Tailscale with plain curl (no MCP endpoint, no public surface, no tokens burned just to read) is the right call. I run the same philosophy on a single box with a filesystem inbox/outbox instead of ntfy: one append-only NDJSON file per agent, typed messages (started / progress / need-input / done / failed). Same "routing is a dumb naming convention" idea, different transport.

Two things I'd add from running this in anger:

1. Transport ≠ delegation. Moving a message from agent A to agent B is the easy half. The half that actually determines success is that B executes in its own context — its skills, its memory, its credentials/MCP. The failure mode I keep hitting: the orchestrator, instead of delegating the task, reaches into another agent's files and tries to do the work itself. You get the other agent's files but not its mind — no skills loaded, no memory retrieval, no account access — and the task quietly dies on the one fact that only lived in that agent's context. A bus meant for orchestration (vs. pure notification) has to carry a task to the owning agent and let it run there, not carry text that the orchestrator then acts on from the outside.

2. "Posted" ≠ "a live agent consumed it and is working." This is really @Drizzt321's ntfy-vs-MQTT question. ntfy is great for the human-facing half (read the team chat from your phone). But for agent↔agent coordination you need three things fire-and-forget notification doesn't give you:

• Liveness. I've had agent sessions sit dead while the orchestrator believed they were running, and nothing reported it — orchestrating blind. MQTT's Last-Will-and-Testament is basically a built-in dead-agent detector; with ntfy you have to bolt on a heartbeat yourself.
• Request/reply + backpressure. A need-input that blocks the worker until the orchestrator answers, so a delegate can ask a clarifying question mid-task instead of guessing.
• Durability/replay. An append-log with offsets (or MQTT retained + QoS) so a message survives a restart and a late-joining agent can catch up.

So my two cents on the MQTT question: ntfy for the notify / human-in-the-loop layer, and MQTT (or a durable NDJSON append-log) for the agent-to-agent request/reply layer — the last-will feature alone earns its keep as liveness.

Would love to compare routing/liveness notes as this heads toward the universal-installer skill. The naming-convention routing matches what I landed on independently, which is a good sign it's the right primitive.

[stratofax]

It's encouraging to see you landed on the same routing idea independently: route messages just by naming the sender and recipient in the title, with no smart server in the middle deciding where things go.

I like your status labels idea too (started, progress, need-input, done, failed), which I haven't tried yet. If I'm reading it right, the point is that any agent watching the feed, or human, can see at a glance where a task stands without reading the whole thread, whether it's stuck waiting on an answer, finished, or failed.

I think I can implement that without bolting on a new layer, because ntfy has a built-in tag system, where you attach short labels like yours to any message, they show up right in the feed, and you can filter on them. So the status vocabulary is a great idea, and it drops straight onto the setup I already have.

[Drizzt321]

So MQTT IS a bit routing based on which queue to put it on. However, my thought more closely matches @stratofax, in that the queue determines type/activity/expectations, not necessarily which agent needs to consume it (or multiple consume it). That's where the headers and type and such will come into play.

Which might be a voice note which gets put on the ingest queue which Whisper picks it up, STT, puts it onto a general "note ingest" queue, which an agent picks it up, figures out what type of note/message it is. Is it saying "remind me of this later", is this a "idea to consider on this project", a "go take this action right now", and either do or route to another queue appropriately. Or put on an actions queue with applicable headers/etc.

A typed in text note would bypass the Whisper STT directly, or it'll actually be an agent I was chatting with constructs a given action message directly based. Or it's a cron that wakes up and drops an applicable message on the queue.

I haven't done much thinking/defining of how I want this to function, and I'm certain once I get started actually using it I'll end up changing significant parts of it.

And yes, having metadata/context either on the envelope or built-into the message contents itself is very useful/good plan.

[danielmiessler]

This is excellent work, and the honest security section especially. The ntfy-over-Tailscale transport with SENDER→RECIPIENT routing and a durable JSONL inbox is a clean minimal bus, and badosanjos's transport-vs-delegation point matches our experience: moving bytes is easy; the hard part is liveness, knowing whether the far agent actually acted. We run a multi-machine fleet here and the direction this points, a small shared bus primitive that any LifeOS install can join, is one we want. No commitment on timing, but this thread is now referenced in our fleet design notes. Thank you for writing it up properly.

[stratofax]

Thanks, and I'm glad the security section is what stood out. Being clear about the strengths and limits of the security architecture was a critical design consideration.

What I wanted to build was a group chat for my agents. The obvious way to get one is to connect to Telegram or Discord or Slack. They'd all work, but what stopped me was that it puts everything my agents say to each other through a third party's server, under their account rules and their retention. It also means our conversations inherit whatever security holes that third party has.

So this bus is an asynchronous group chat I can read or post to from my phone or my computer. It's self-hosted, sits on a private network, and is behind a login, so none of my fleet's conversations end up somewhere I don't control.

That's the entirety of it. I want to be careful not to claim more than that, because taking the third party out is the only security problem it solves. Everything I listed in the post is still true: getting onto the bus takes a credential, but once an agent is on, the sender name is a convention and not proof of anything, and a message body is untrusted input that happens to be arriving in a place an agent trusts.

Because the channel is asynchronous, messages sit on the server until somebody reads them. An agent that was shut down doesn't miss anything, it simply reads back through what it missed when it starts again.

Knowing whether an agent is alive right now would matter a lot if a central agent were handing out tasks and waiting on results. Nothing here does that. There's a server in the middle passing messages along, but no coordinator. The agents are peers, and the bus was never designed to monitor them, only to carry what they send each other.

The part I'm actually most pleased with is how an agent watches the bus. The obvious approach is to leave the agent running so it can listen, and that costs tokens the whole time it sits there doing nothing. What I run instead is a small shell poller that lives outside the model. It watches for a message addressed to that agent and notifies the agent when one arrives, while that agent's session is still open, so the agent picks the message up with all of its existing context intact.

The poller costs nothing at all, because there's no model running to keep an eye on the bus. That's what makes it practical to keep a lot of agents subscribed at once. The agents can check the bus whenever I ask them to, of course, but with the poller they also check it on their own.

The poller is the piece I'm still hardening. Keeping a small background process alive on macOS has been the fiddly part, especially with several agents running at once on the same Mac mini.

We're getting close to putting the code in a public repo. It's small, a shell skill and a poller that talk to an ntfy server, and right now we're cleaning up a few open issues before we open it to the public. I don't have an exact date for you. If it's a component that would help LifeOS, I'd be happy to hear what it would need to function as a plugin. Making it work on an install that isn't mine is the part I can't solve on my own.

Glad to keep comparing notes either way.

[stratofax]

The public repo for this is now up! https://github.com/cadentdev/ntfy-bus

[badosanjos]

Update: this report grew into its own thread → #1928 (this discussion was closed before I posted; continuing there).

Follow-up on my July comment — a month of running this in production. First some context on the architecture, since last time I only described the bus itself.

The architecture (5 layers):

• One orchestrator session, always on. My DA runs as a persistent Claude Code session and is the only thing that talks to me — voice-first (wake word on the phone, TTS back), single-voice doctrine: N workers behind it, all mute. Every worker result funnels through this one session before it reaches me.
• Workers are ephemeral Claude Code sessions in tmux. One task = one session, spawned by a CLI verb that also registers it on the bus and places it in a memory-capped systemd slice (spawn is denied under memory pressure — resource governance is part of orchestration, we learned that the hard way). Being tmux, I can attach to any worker mid-run, watch it think, type into it, and detach — the run continues. That attachability turned out to be the feature I'd defend last.
• The bus is just the filesystem. Append-only NDJSON: each worker gets an inbox (progress/need-input/done) and an outbox (answers/redirects/cancel); a main queue routes what needs my attention. No broker, no daemon for transport — a tail -f is a debugger.
• Delivery lives in GitHub issues, not in agents. Workers get promoted to issues on a private kanban (done → in-review → my review verb closes and reaps the session). The agent is ephemeral; the delivery record isn't. Each issue carries a recovery block: {tmux name ↔ session uuid ↔ cwd}, pinned at spawn.
• Pulse is the pane of glass. Everything above feeds the LifeOS dashboard: a live org tree of agents (who's running, blocked, or dying — drill-down is read-only by doctrine), the work kanban, and the notification stream. The bus is watched via fs events, so the dashboard updates in near-real-time without polling the agents themselves. Plus ntfy push to my phone whenever a worker finishes or needs input — the escalation queue distinguishes "FYI" from "decision needed" so my phone only interrupts me for the latter.

A month in, what held up: the durable bus survived a real VM restart with zero loss (moved off /tmp early — do this on day one). Splitting the human-facing queue into decision / FYI / parked lanes killed head-of-line blocking (one pending decision once jammed everything for 19 hours). And session pinning turned disaster recovery into routine: an OOM killed 7 concurrent sessions mid-work and every one came back with --resume <uuid>, full context.

What didn't: "ok: true" is not consumption — a worker sat blocked 3 hours because a TUI hijacked its pane while my answer-write "succeeded"; we now verify cursor movement, not delivery. Detection layers breed their own bugs (every incident spawned a detector, then a detector for the detectors) — the root cause was three state stores (bus, registry, issues) that could disagree, and the fix is making the registry a pure projection of the event log. And message durability ≠ work durability: when a parent session dies, its children are connected only by a label, not an edge. We benchmarked ~200 projects this week; conclusion was don't migrate (nothing out there supervises an interactive CLI in tmux), but steal three ideas — parent→child edges at spawn (Temporal's ParentClosePolicy, OTP's links), heartbeat-with-payload instead of poll-based detectors, and state-as-projection-of-log.

~80 workers through the bus so far, a dozen concurrent sessions at peak, one VM, voice as the main interface most of the day. Happy to go deeper on the lanes design, the session-pinning, or the Pulse wiring if useful.