Where should your agents actually live?

In July 2026 Block released Buzz, a workspace where AI agents sit in channels as full participants alongside people. The coverage mostly asked whether it can beat Slack. That is the wrong question for anyone who is not Block or Salesforce.

The right question, and the one the launch usefully surfaced, is one most teams have not sat down and answered: where do your agents belong? Not which model, not which framework. Where, physically, in your tooling, does an agent sit — and what does that placement decide about the work it can do?

There are three answers. Most teams arrive at the first by accident, and the third is where most of the value turns out to be.

One: bots in the chat you already have

An agent gets a bot user in your existing Slack or Teams. People mention it, it responds. It summarises a thread, answers a question against your docs, files a ticket when asked.

This is the default, because it is the shortest path from nothing to something visible. It has real advantages: no new tool for anyone to learn, no migration, and the agent's work happens in front of the people whose work it is. When it gets something wrong, someone notices immediately and says so.

Its limit is structural. An agent in a chat channel is a request-response tool wearing a friendly surface. It waits to be asked. Everything it does is initiated by a human who first had to remember that the agent exists, decide it could help, and phrase the request. The agent is only as useful as your team's habit of turning to it, and habits are expensive to build.

Two: a workspace built for humans and agents together

This is the Buzz proposition, and Centaur's, and increasingly the direction Slack itself is heading. The workspace is designed from the start around agents being participants rather than bolt-ons: they hold their own identity, they have scoped permissions, their actions are recorded distinctly from a human's.

The design argument for this is good, and the identity part in particular is a genuine improvement over shared bot tokens. If you run a lot of agents doing consequential work, knowing which agent did what — under whose authority — stops being a nice-to-have.

The practical argument against it, today, is timing. Buzz is pre-1.0, the mobile clients are incomplete, and Block itself sorts features into what works today and what is still being wired up. Moving a working team onto a young workspace costs you every integration and habit you already have, and buys you a better model of something most small teams are not yet doing at volume.

There is also a question this category has not answered. An agent in a channel can read everything in that channel. Scoped identities and a signed audit trail tell you afterwards what an agent saw. They do not stop it from seeing the thing someone pasted in a hurry. That is the same exposure you already have in Slack — the point is that moving workspaces does not fix it.

Three: an agent with a job and no chat surface at all

The third option is the one nobody demos, because there is nothing to watch.

The agent is not in a channel. It runs on a trigger — a form submission, a new file in a folder, a nightly schedule, an inbound email, a webhook from your project tool. It does its work, writes the result where the result belongs, and posts a line somewhere only if a human needs to act.

This is where most of the value in a small business actually sits, and the reason is not subtle. Work that goes through an agent in chat has a human bottleneck at the front: someone has to start it. Work that goes through a triggered agent does not. Over a month, an agent that processes every inbound quote request automatically does vastly more than one that processes the requests somebody thought to paste into a channel.

The examples in our own client work are boring and that is the point. Drawings arrive by email and a quote-prep summary is waiting the next morning. A photo lands in a shared folder and the inspection log is already written. Nobody talked to an agent. The work is just done.

The distinction that decides it

Strip the three options down and the question is not which product. It is:

Is this agent waiting to be asked, or is it running on a trigger?

Chat-resident agents wait. Triggered agents run. Everything else — which workspace, which model, whether the agent has its own keypair — is downstream of that, and much less consequential to whether the thing earns its keep.

The trap is that waiting agents are far easier to sell internally. They are visible. You can show one to the board in ninety seconds. A triggered agent that quietly removes four hours a week from someone's Tuesday is invisible by design, which makes it harder to get approved and harder to get credit for. Visible and useful are close to uncorrelated here, and a lot of AI budget goes to the visible one.

What chat is genuinely good for

None of this means chat is a mistake. It means chat is the wrong final destination for work that should be automatic — and the right place for three things:

• Supervision. An agent posting what it just did, where a human can see it and object. This is the highest-value use of a channel and it does not require the agent to live there.
• The ambiguous middle. Work that needs a human judgement call partway through. A channel is a good place for an agent to stop and ask.
• Proving the work. Before you automate a workflow, run it in chat for a fortnight. You will find out what the agent gets wrong while a human is still in the loop, and cheaply.

That last one is the practical sequence, and it is what we would suggest to almost any team of five to forty people:

1. Prove it in chat. Put the agent in a channel, run the workflow by hand, watch where it fails. Two weeks is usually enough.
2. Move it behind a trigger. Once the failure modes are known and handled, remove the human from the start of the process. This is the step most teams never take, and it is where the return is.
3. Keep the channel as the review surface. The agent posts what it did. Someone skims it. That is a different thing from the agent living there.

On Buzz specifically

Worth being clear, since it prompted the question. Do not move your team onto Buzz this quarter — it is early, Block says so, and the migration cost is real against a benefit most small teams cannot yet use.

Do take the idea seriously. A workspace where agents are first-class participants with their own identity and permissions is very likely where this ends up, whether the winner is Buzz, Slack's version of the same thing, or something not launched yet. When you get there, the agents worth having in the room will be the ones that already have jobs.

---

If you are working out which of your workflows should have an agent behind a trigger rather than a bot in a channel, that is the kind of thing we help with at Think and Form Limited. Get in touch at admin@thinkandform.co.nz.