Your agents can't help with what they can't see

"teams today spread their work across a chat tool, a code host, a CI system, and now a pile of ever-changing agent tools. every seam loses information...and agents feel it the most. they can't help with what they can't see."
Jack Dorsey, releasing Buzz on 21. 7. 2026

That is the whole problem in one sentence, and it has a second half that is easier to miss.

Some people on your team have got genuinely good with AI. They keep the client context in a file the model reads, they have instructions that work, they know which tool to reach for. None of that is wasted. But all of it is per person. The context sits in one person's folder, the instructions in one person's settings, the answer in one person's window. Your best operator's setup is not something a colleague can call, or even see.

So you end up with two gaps at once: the tools cannot see each other, and the people cannot see each other's setups. What the company paid for was individual proficiency. What it wanted was capability it owns.

Buzz is Block's answer. An open source workspace that puts people, agents, conversations and code on the same level, behind one identity system, on a server you own. They built it, in Dorsey's words, "to reduce our dependency on slack and github", then gave it away under Apache 2.0. It is model agnostic by design, and two weeks after launch the repository had passed 23.000 stars.

Two ideas underneath it are worth your attention, whether or not Buzz itself wins.

Idea one: unified context

In Buzz, an agent is not a tool you open. It is a member of your workspace. It has its own identity, it belongs to specific channels, and when someone mentions it, it answers in that thread with the full conversation in front of it.

That removes the copy-paste tax. Nobody explains the client, because the client is what the channel has been discussing for three weeks. Nobody pastes the thread, because the agent is reading the thread.

It goes further than chat. Messages, project items, code reviews, git events and automation runs are all the same kind of signed record in one searchable history. A feature branch becomes a channel, so the patch, the CI result, the review and the decision sit in the same thread as the conversation that produced them.

Idea two: an agent you can audit

Because the agent is a member and not an app on someone's laptop, more than one person can call it. A colleague who has never installed a developer tool can mention it in a channel and get real work out of a setup that took your best operator an afternoon. The configuration stops being personal equipment.

Then there is the identity model, which is the part you should care about if you are the one who signs things off.

Each agent has its own keys. It does not borrow yours. Everything it does is signed and traceable to it, so you can answer "who did this, and who let them" months later. Matt Rice, who has been documenting the rollout, said it best: it is "a teammate you can audit, not a bot wearing your face."

Compare that to the bots you have now, which post under an app identity that tells you nothing about who authorised what.

There is a quieter mechanism underneath it. Buzz agents support lifecycle hooks: checks you wire into the agent's loop, hidden from the model, refused if the model tries to call them itself. The constraint does not depend on the model choosing to behave.

How this looks in practice

This is how we use it. Take what fits and change the rest; the setup is worth more the more you shape it around your own work.

A question comes up while you are discussing a prospect. Usually: someone says "I will look into it", opens a browser, loses fifteen minutes, reports back in an hour. In Buzz: you ask in the thread. The agent already knows which prospect, because that is what the thread is about, and the answer lands where everyone can see it.

A task falls out of the conversation. Usually: it gets mentioned, everyone assumes someone else caught it, and it resurfaces in two weeks as a problem. In Buzz: you ask the agent in the same sentence you would have used with a colleague. It does the work and reports back in the thread, so the request and the result stay together.

A customer reports a bug. Usually: support writes it down, a developer reads it a day later, asks three clarifying questions, starts reproducing. In Buzz: support posts it, someone pulls in a developer's coding agent, and it reproduces the issue while the thread is still warm.

You come back from two days away. Usually: you scroll. In Buzz: you ask what you missed in the channels you care about and get a short brief with links.

The pattern is the same every time. The work happens where the conversation already is, so nothing has to be copied into another tool and copied back.

What people built in week one

None of these are Block employees. All of it happened within seven days of launch.

• A company of eleven agents, migrated in. An orchestrator, an execution lead, wired to the owner's own project board.
• An agent whose only job is delegating. Called Chief, with a job description that says it does not do the work. One message in, and it staffs a channel with specialists and returns a citation-checked deliverable.
• A content factory in one thread. Idea to published post, with the agent checking the live page afterwards.
• A bridge to Linear. Assign an issue, a manager agent wakes the right agent in a fresh sandbox, progress posts back to both systems.
• Slack and Notion, replaced. An operator two days in, running one agent for onboarding and one for financial reporting that anyone can query.

And the one that says the most about where this is going: one of them never installed it by hand. He told his coding agent, out loud in voice mode, to install Buzz, create the channels and configure the agents. Our guide does roughly the same thing, with a prompt you paste into Claude Code, Codex or Cursor. It is at the end of this article.

Agents that work as a team, not a crowd

The most useful public example so far is Riley Brown's setup, because it shows what changes when several agents share one room.

He uses Codex as the lead, since it already holds his skills, memory and computer-use workflows. Claude Code and Grok act as reviewers. On a real job, thumbnails, Codex produces five options, the two reviewers critique them, Codex produces five more from that feedback, and he picks what deserves another round.

What makes it work is the sequence rather than the lineup.

Two rules make it work in practice. Every handoff states what is being asked, what counts as done, and what the agent is not allowed to do. And anything with external consequences, publishing, sending, merging, spending, deleting, stays behind a human.

You are not buying a model

Buzz does not ship a brain. You point it at one, and you can swap it later without losing the workspace, because the context lives on your relay rather than inside the tool.

In practice you use whatever your team already pays for. If your work cannot legally leave your own machines, an open-weights runtime is a supported option rather than a hack.

Who pays, and who is allowed

There are two ways to run an agent, and they cost different things.

On someone's laptop. Buzz drives a coding assistant that person already has installed. The company adds nothing to its software bill, since the agent uses that person's subscription and their machine. The catch is that it only works while the machine is on.

On a small server, always available. This one needs its own API key, from Anthropic, OpenAI, or any compatible provider including OpenRouter, and you pay that provider per use. There is no Buzz fee on top. Hosting is free during the beta, and self-hosting costs nothing.

Two settings decide the governance, and both deserve a decision rather than a default.

The first is who may talk to each agent: only its owner, a named list of colleagues, or anyone in the channel. It ships as owner-only, so sharing is a deliberate act. That is the right default, for a reason that becomes clear further down.

The second is how many conversations it handles at once. Every running session burns the owner's subscription and their machine, so this is a resource decision rather than a technical detail. It is also why a shared agent needs a named owner.

How we structure it

This is what we run at NativeAI. It is a starting point, not a template to copy exactly: the more you shape it around how your company actually works, the more you get out of it.

One channel per stream of work, one per audience, and at least one that only agents write to.

• general and welcome for the daily conversation
• one channel per product
• one each for sales, content, operations and people, customer support, internal tooling
• one for industry news, so it does not flood everything else
• one where the team collects the prompts and workflows that actually worked
• one feed channel that only automations post into

The agent lineup is smaller than people expect. Three things, not ten. Everyone who already uses a coding assistant turns it into a shared agent for two or three named colleagues. One always-on assistant on a server handles questions that arrive when laptops are closed. One automation identity, not conversational at all, posts into the feed channel so machine events are never mistaken for human ones.

Start with the shared agents. The feed channel earns its keep later, once enough automations exist to fill it; on day one it is an empty room.

What is still missing

Buzz is in beta and changes fast, so anything you read about it, including this, needs a date on it. This section is accurate on 6. 8. 2026, against v0.5.5, which is the fourth release in a week. Two things moved in the fortnight before it was written: git hosting went from missing to shipped, and the mobile apps went from promised to live on 29. 7., on both the App Store and Google Play.

The phone apps need one clarification, because it decides how useful they are. They are not a remote control for your laptop: the app signs its own messages, talks to the relay directly, and push works, so your team sees what you write straight away. What a phone cannot do is wake an agent that lives on a closed laptop. If you want an answer at midnight, run one always-on agent on a server with its own API key, and the phone reaches it any time.

Beyond that: approval gates for workflows are half built, and cross-relay reputation is a stated intention rather than code, which Block flags itself. Each community still runs on one relay, so linking relays together is ahead rather than here.

And the app feels early, because it is. Some things take more clicks than they should, and the interface shifts under you, since new versions land every few days.

Then the part worth reading twice, which Block's own engineer wrote down rather than buried. A Buzz agent usually runs on the same computer a person uses, outside any sandbox, with permission prompts skipped, inheriting that machine's files, skills and credentials. That is why it is powerful and needs almost no configuration. It also means, in his words, that "the agent can do anything, and security rests entirely on restricting who can tell it what to do." The whole safety model is the identity layer. Leave the default at owner-only and widen it one named colleague at a time.

One more open question, from an engineer at Slack: an agent that belongs to several private channels becomes a route for information to cross boundaries that exist for a reason. Per-agent permissions and a signed record are the answer on paper. Treat agent access the way you treat access to the shared drive.

Where this is pointed

Buzz runs on Nostr, the same stack that already carries Lightning payments, and Dorsey has said "agents that can transact feels like a natural place for us to take it next." An agent with its own identity, its own audit trail and the ability to pay for work is a different kind of participant in a company than an autocomplete box.

The strongest evidence this is not a side project is that Block's first test is not you. It is themselves: "we're going to run more and more of block on buzz."

Where you will feel it first

You will not notice this on the first day. You notice it in four specific places.

The question that used to cost an hour. Someone asks in the channel instead of promising to look into it, and the answer is visible to everyone rather than sitting in one person's window.

The colleague who was never going to learn this. They mention a coworker's agent and get real work out of it, without installing anything. That is the moment a personal setup becomes a company capability.

The handover you did not have to do. Someone comes back from a week away and reads the thread rather than booking three catch-up calls.

The question you can actually answer later. Who did this, and who authorised it, with a signed record instead of a guess.

Pick one real project, put it in a channel, and share one agent with two colleagues. Two weeks is enough to know whether any of the four show up for you.