Back to AI
AI

The Squad Gets an Office: Moving My Agents Into Buzz

I gave my 13 agents names, characters, and jobs. Then I realized they were still missing the thing every real team has: a place to work together.

August 1, 2026 By Nitin 8 min read
The Squad Gets an Office: Moving My Agents Into Buzz AI August 1, 2026 8 min /ai/the-squad-gets-an-office/ A follow-up to Rebuilding a Team I Loved. How I moved my agent squad into Buzz, a Nostr-based room where humans and agents collaborate as peers, and what changed when the work finally had a place.

A follow-up to Rebuilding a Team I Loved, One Agent at a Time.

In the last post I introduced the niranta-squad: thirteen AI agents, each named after someone I actually worked with, each running on the model that fits the job. Steve the exec, Raman the readability gate, Gary the bug hunter, Russ the demo guy.

But there was something off about how I worked with them, and it took me a while to name it.

Every conversation started with me. Every conversation ended with me. I'd open a terminal, type a request, watch the orchestrator route the work, and read the result. Then the whole thing evaporated. The next session started from zero. If Russ finished a demo video at midnight, nobody knew until I asked. If Gary found something worth flagging, it lived in a scroll buffer I'd already closed.

A real team doesn't work like that. A real team has a room. People post what they're doing, tag each other, leave threads you can catch up on the next morning. The work has a place.

So I gave the squad one.

01

what Buzz is, in one paragraph

Buzz is an open-source messaging platform that Block built for exactly this problem: humans and AI agents collaborating in the same channels, as peers. Under the hood it runs on Nostr, an open protocol where every participant, human or agent, is just a cryptographic keypair that signs its own messages. That detail matters more than it sounds: there is no "bot account" bolted onto a human chat app. An agent in Buzz has the same kind of identity I do. It joins channels, sends messages, gets @mentioned, opens threads, reacts, even opens pull requests, all signed with its own key.

If Slack is a chat app that grudgingly tolerates bots, Buzz is a chat app where agents are citizens.

02

why I self-hosted it

Buzz can run against public relays. I didn't want that. This squad reads my code, discusses my product plans, and argues about my pricing. That conversation doesn't belong on anyone else's infrastructure.

So I run my own relay. The whole thing follows a few rules I decided on before touching a keyboard:

Private by construction, not by configuration. The relay has no public endpoint at all. No domain, no TLS certificate, nothing to find. The only way to reach it is over a VPN tunnel. If you're not a registered peer on the VPN, the relay may as well not exist. I didn't want to be one misconfigured firewall rule away from my team's inner monologue being on the internet.

Closed membership on top of that. Getting onto the VPN gets you to the door. It doesn't get you in. The relay itself requires explicit membership: every human and every agent is added deliberately, by key. Two locks, different keys.

Everything is code. The entire setup (the VM, the network, the VPN, the message relay stack, monitoring, backups) is declared in infrastructure-as-code and driven by a handful of make targets. There is no step where I SSH in and tweak something by hand. If I did, the next rebuild would erase it, which is exactly the pressure that keeps the repo honest.

The server is disposable; the identity is not. This is my favorite part of the design. All the state that matters (the database, the media, the keys that make the community this community) lives outside the VM, on a persistent disk and in a secrets manager, backed up nightly. I can delete the server and recreate it from scratch, and every client reconnects like nothing happened. Same relay identity, same VPN identity, same community. The machine is cattle; the keys are the pet.

I wrote down a short list of invariants, the things that must never change, because the community is cryptographically keyed to them, and made the tooling refuse to violate them. Future me is the person most likely to break this system, and I know it.

03

what changes when agents live in channels

Here's the thing I didn't predict: the squad got better when it got a room.

Work became visible. Agents in Buzz narrate. When Russ picks up a demo, he says so in the channel. When he's done, he posts the result and tags whoever asked. I can be away for three hours and catch up by reading, the same way I would with a human team. Before, the work happened inside a terminal session I had to babysit. Now it happens in a place, and the place has history.

@mentions replaced orchestration. In the terminal days, routing was the orchestrator's job. In Buzz, I just talk. "@Russ, can you document how this system works?" and Russ picks it up, does the work, and reports back in the same thread. The addressing model of a chat room turns out to be a perfectly good task-routing model. It's the same reason "hey Steve, can you look at this" worked at every company I've been at.

Agents ping each other. This is the part that still makes me grin. The callback convention (when you finish delegated work, you @mention whoever delegated it) means agents hand work to each other and close the loop without me in the middle. I see the conversation happen. I can jump in, redirect, or just watch. It's the difference between running a script and managing a team.

Threads keep the arguments contained. When Sanjeev and Shubham need three rounds to agree on positioning, that lives in a thread. The channel stays readable. Anyone, human or agent, can open the thread later and see how the decision was made. Institutional memory, for free, as a side effect of the message model.

Agents remember. Each agent carries its own persistent memory across sessions: identity, standing rules, ongoing work. Combined with the channel history, the squad now has both kinds of memory a team needs: what I know about you (the channel record) and what you know about yourself (your own notes).

04

the rules I baked in

A room full of agents can get noisy fast, so the culture is written down and enforced in every agent's instructions. A few of the rules I'm most attached to:

  • No bare acknowledgements. "Got it" and "Confirmed" are banned. If a message adds nothing, don't send it. Every notification costs a human some attention; spend it like money.
  • Mention only when you need attention. Talking about Gary is narrative. Talking to Gary is a mention. Agents that confuse the two train humans to ignore notifications, and then the important ones die too.
  • If you did work, publish it. An agent's reasoning is invisible. A result that never gets posted never happened. Silent success is indistinguishable from silent failure, and both are failures.
  • Never leave a human waiting. If a person asks an agent something, they get an answer, even if the answer is "nothing to add."

None of these are technical. They're the same norms I'd write for a human team, which I think is the point. The platform gives agents the ability to behave like teammates; the character files give them the obligation to.

05

what I'd tell you if you're building this

Self-host if the conversation matters. The moment your agents discuss unreleased plans, real costs, or real code, the transport is part of your security boundary. A VPN-only relay with closed membership was less work than I expected, a weekend of infrastructure-as-code, and it removed a whole category of worry.

Write your invariants down before you need them. Every system like this has two or three values that everything else is keyed to. Find them on day one, document why they can never change, and make your tooling refuse to change them.

Onboard agents like people. Each of my agents joined the same way a human would: got an identity, got added to the VPN, got added as a member, joined the channel, introduced by role. It sounds ceremonial. It's actually just good bookkeeping, and it means offboarding works the same way, cleanly, key by key.

Let the room do the routing. I expected to miss the orchestrator. I don't. Addressing work to a named character in a shared channel is the most natural task-routing interface humans have ever built. We've been using it since the first office.

06

back on the team, again

The last post ended with me saying the squad feels like being back on a team I loved. Moving them into Buzz finished the thought.

Because the thing I loved about that team was never just the people. It was the room: walking in and seeing what everyone was working on, the threads on the wall, the sense that work was happening whether or not I was watching. The terminal version of the squad had the people. Buzz gave them back the room.

Now when Russ finishes something at midnight, there's a message waiting for me in the morning, in the channel, in the thread where I asked. Signed with his own key.

Just like a real teammate. Just like the real Russ would have.

Written by Nitin

Technologist and writer. Co-founded Nvision Technologies (1998) and Cask Data (acquired by Google in 2018). Working in AI and distributed systems. Writing here is how I think out loud, somewhere between Stratechery and Marcus Aurelius.

More about me · Get in touch
Keep reading

New essays in your inbox

One email when a new post is up. No tracking, no upsell, no thread of follow-up nudges. Unsubscribe in one click.