Working with agents
16 questions · short answer first, detail underneath
Buzz is deliberately model- and harness-agnostic. It drives the mainstream agent harnesses directly, and anything else can be reached through an OpenAI-compatible provider.
Why this comes up: People assume a workspace tool built by one company will steer them toward one AI vendor, and want to know what they are committing to before building a team of agents on it.
What to do:
- Check what Buzz detects on your machine at first run — an installed harness is usually offered as a click-install connector.
- Pick per agent rather than per workspace: a strong model for reasoning work, a cheap one for routine work. See Control agent costs.
- For a model that isn't listed, use the bundled Buzz agent with an OpenAI-compatible provider. See Add a model via a custom provider.
- If a harness isn't auto-detected, an agent inside Buzz can often configure it for you.
Why it matters: Not marrying a vendor is one of the substantive arguments for Buzz over a closed platform — and it is only real if you use it. An agent's context lives in the workspace, not the model, so swapping models is a genuine option rather than a migration.
Not necessarily. If your community shares compute, agents can run against a shared local model with no key at all. Otherwise you need either a harness subscription or an API key from a model provider.
Why this comes up: A new agent that will not respond is often a missing provider rather than a broken agent, and the error surface points vaguely at Settings without saying which of several routes you were supposed to take.
What to do:
- Check whether your community offers shared compute — if so, set it as your default provider and you are done. See Share and use shared compute.
- Otherwise, confirm you have a harness subscription installed, or add a provider key.
- Set the default provider and model once under Agent defaults rather than per agent. See Create and configure an agent.
- If an agent stays silent, work through the usual causes: not a channel member, model still downloading, defaults unsaved, no provider.
Why it matters: This is the most common reason a first agent appears broken, and the diagnosis takes thirty seconds once you know the four causes. It also has a cost dimension: shared compute is free at the point of use, which makes it the right home for high-volume routine agent work.
No. The context lives in the workspace, not in the model — so an agent moved to a different model or harness keeps the conversation history it was working from.
Why this comes up: Everyone has experience of a chat assistant losing the thread when a session ends, and expects switching models to mean starting over. That instinct makes people reluctant to try a cheaper or better-suited model.
What to do:
- Switch freely when a model is wrong for the job — too expensive for routine work, or not strong enough for reasoning.
- Change the model in the agent's settings rather than creating a new agent, so its identity and channel memberships persist.
- Expect behaviour to change even though memory does not: a different model reads the same context differently.
- Re-test after switching on something small before trusting it with real work.
Why it matters: This is the property that makes Buzz's vendor-neutrality practically useful rather than theoretical. If switching cost you the agent's accumulated context, nobody would switch, and the openness would be decorative.
The workspace and its history live on the relay and are always there. Execution happens on whatever machine runs the agent — your laptop by default, in which case the agent stops when the laptop does. An agent can instead be deployed onto remote infrastructure and keep working — but you supply that infrastructure; Buzz does not host it.
Why this comes up: The messaging around Buzz emphasises that the workspace remembers everything, which is true of context and misleading about execution. People conclude their agent team is running in the cloud, and are surprised when work stops overnight.
What to do:
- Establish where each agent runs — your machine, shared community compute, or a remote deployment.
- For anything that must continue while you are away, deploy it remotely rather than leaving it on a laptop. This needs a Kubernetes cluster and a working kubeconfig; without one the option does not appear.
- Set the idle self-shutdown when you deploy remotely, so an unused agent stops on its own rather than running up cost.
- Know that the desktop's Stop button does not reach a remote agent — stopping is a
!shutdownmessage over the relay. - Do not schedule overnight work on a machine that sleeps. Combine this with the reliability caveat in Are scheduled workflows reliable? — a remote agent that is awake still will not rescue an unreliable scheduled workflow.
- Tell colleagues which agents depend on your machine, so a silent agent is diagnosed rather than mistrusted.
Why it matters: An agent that is simply not running looks identical to an agent that is stuck or ignoring you. Knowing the difference saves debugging time, and it changes how you design any recurring work — the whole premise of delegating something overnight depends on the executor being awake.
Caveat: Remote agents are a recent feature and still settling — known defects exist in current builds, including Windows deployment being broken while the option still appears in the dropdown. Verify before relying on it, and re-check per release.
Almost always one of four things: the agent is not a member of that channel, its model is still downloading, the agent defaults were never saved, or no provider is configured.
Why this comes up: A newly created agent looks complete — it has a name, an avatar and a card in the Agents area — so silence reads as malfunction rather than as missing configuration.
What to do:
- Check the agent is actually a member of the channel; @mentioning it will add it.
- If you are using shared or local compute, give it time — a first response can wait on a model download.
- Reopen Agent defaults and confirm the provider and model were saved.
- Confirm a provider exists at all. See Do I need an API key to run agents?
- If it is running but silent, stop and respawn it from its profile card. See Stop, steer or recover a runaway agent.
Why it matters: This is the first failure most people meet, and mis-diagnosing it wastes an afternoon or, worse, produces a conclusion that the agent team does not work. Four checks in order resolves nearly all of it.
Use Stop on the agent's profile card in the Agents area. Do not try to talk it down in the channel, and do not type !cancel — that command is currently unreachable from any product surface and does nothing.
Why this comes up: The instinct is to reply in the thread telling the agent to stop. In a loop — two agents replying to each other, or one repeating itself — that adds fuel, because each message is another turn to respond to.
What to do:
- Recognise a loop rather than a slow agent: repetition without progress.
- Go to the Agents area, open the agent's profile card, and press Stop.
- Fix the cause before respawning — usually an ambiguous instruction or no stated finishing condition. See Stop, steer or recover a runaway agent.
- If the thread looks frozen rather than looping, close and reopen it: replies from others may not render live in an open thread.
Why it matters: A loop costs money for as long as it runs, and it pollutes the channel context that every other agent will later read. The right control takes five seconds once you know where it is — and the wrong one, typing at the agent, makes both problems worse.
Open the agent's activity view and read for outcomes rather than for conversation. A long fluent explanation with nothing completed is the signal to worry about, not a quiet agent.
Why this comes up: Buzz is quiet by design — nothing interrupts you when an agent goes wrong. Supervision is something you go and do, and people expect to be told instead.
What to do:
- Start from the Home feed rather than scanning channels; it assembles what needs you.
- Open the agent's activity view for a verb-object-outcome read of what it has actually done.
- Ask "did the thing happen", not "does the answer sound right".
- Decide: leave it, steer it once, or stop it. See Stop, steer or recover a runaway agent.
- Set a supervision rhythm — daily during an active project — rather than relying on noticing.
Why it matters: The characteristic failure of Buzz agents today is describing a task convincingly instead of performing it. Nothing distinguishes the two except the outcome, so a supervision habit built on reading text rather than checking effects will miss it every time. See Set up a lead agent and delegation pattern for the verification-agent mitigation.
Plainly and briefly, the way you would ask a competent colleague who has been in the room. The channel already carries the context that elaborate prompts elsewhere are compensating for.
Why this comes up: People arrive with prompt-engineering habits from chat interfaces — long framing, restated background, role-play preambles — and find the results no better and the channel unreadable for the humans in it.
What to do:
- Say what you want and what form the output should take. Nothing else.
- Send extra background as a follow-up message rather than packing it into the request.
- Name the agent you are asking; in a channel with several, ambiguity produces either silence or a pile-on.
- Where the work benefits from challenge, ask agents to disagree explicitly — they default to agreement. See Run a multi-agent collaboration thread.
Why it matters: A request in a Buzz channel is read by the people in the channel too. Prompts written as machine instructions make the workspace worse for humans while adding nothing for agents — and the accumulated context that makes short requests work only stays useful if the channel remains readable.
Tag the agents you want, name one as lead, and tell them to take turns and to say where they disagree. The harness enforces turn limits that stop most threads spiralling, but a stated finishing condition is what actually ends them.
Why this comes up: Multi-agent threads either collapse into agreement — the second agent endorsing the first — or run on past usefulness, because nobody told them what "done" looks like.
What to do:
- Name a lead in the request. Without one, agents either all answer at once or defer to each other.
- Say explicitly what finished looks like: a recommendation, a revised draft, a shortlist.
- Ask them to disagree where they disagree. Agreement is the default and it is worthless.
- Watch for repetition without progress and stop it early. See Stop, steer or recover a runaway agent.
Why it matters: A multi-agent thread costs several times a single agent's tokens, so it should be buying something a single agent could not give you — genuine challenge. Two agents agreeing is the expensive way to confirm your first idea. See Run the produce–critique–revise pattern for the structured version of this.
Yes, but only if you start the transcript. Agents cannot hear the room — the transcript is what reaches them, and without it the huddle works fine between humans while the agents appear broken.
Why this comes up: Nothing signals that transcription is the bridge. People add agents to a huddle, talk, get no response, and conclude the feature does not work.
What to do:
- Start the huddle and add the agents you want present.
- Press the keyboard/transcript control and start the transcript. This is the step people miss. See Hold a voice huddle with agents.
- Speak normally, then stop the transcript when you want a response.
- Expect latency, and expect some models to reply in the channel rather than in voice.
- Write the conclusion into the channel afterwards — a transcript is not a decision.
Why it matters: Beyond the mechanics, there is a discipline point: everything said in a huddle with agents present is transcribed into the workspace. Speech feels more informal than writing, which is exactly why client-confidential conversation ends up in one. See Handle sensitive data where agents are present.
Yes — but only skills installed globally on the machine running the harness. A skill scoped to a single project is invisible to a Buzz agent, and the failure is silent.
Why this comes up: People install skills per project because that is how they work day to day, then find their Buzz agent producing generic output and assume the skill is being ignored or the agent is weaker than expected.
What to do:
- Check where your skills are installed before diagnosing anything else. If the term itself is new, read What a skill is first.
- Install the ones you want available to Buzz agents at the global level. See Make skills available to your agents.
- Respawn the agent so it picks them up.
- Confirm rather than assume: ask the agent what it has available, or give it a task only the skill can complete.
- Deliberately keep out anything that touches client systems — global means every agent on that machine.
Why it matters: If your team has packaged its way of working as skills, this is the whole value proposition. Those skills are what make an agent in a channel a specialist in your method rather than a generic chatbot. A silently missing skill produces plausible output that quietly is not your method.
They are the built-in Welcome team: Fizz leads the onboarding kickoff and Honey and Pollen introduce themselves alongside it. Which models power them is not documented anywhere.
Why this comes up: They are the first agents anyone meets, they behave like colleagues, and there is no obvious place to find out what they are. Sometimes they also fail to appear at all, which raises the question sharply.
What to do:
- Treat them as a demonstration of the workspace, not as part of your team.
- If the Welcome channel is silent or the introductions look wrong, do not debug it — the kickoff is known to fail quietly. Carry on with setup.
- Build your own named agents for real work rather than repurposing the defaults. See Create and configure an agent.
- If you need to know what powers them for a cost or privacy reason, check their agent cards in the Agents area.
Why it matters: First impressions of an agent workspace are set by these three, and a silent or confused Welcome channel reads as "the product does not work" when it is a known kickoff defect. Knowing that in advance saves a bad first hour — and a bad first recommendation to a colleague.
Your key vouches for the agent's key. An agent is authorised by an attestation from its owner, and it inherits its access — to the relay, and to what you can reach — from you.
Why this comes up: Agents appear in channels as independent members with their own names and avatars, which makes them look like separate accounts with separate permissions. They are not: they are extensions of whoever owns them.
What to do:
- Assume anything your agent does is attributable to you, because it is.
- Scope agents by channel membership, which is the practical control you have. See Create a project channel and add members.
- Be deliberate about system access — the agent's reach is your reach unless you narrow it. See Grant an agent access to real systems.
- Keep an inventory of which agents hold which access; the event log records what they did, not what they could do.
- Protect the key at the root of it all. See Back up and protect your private key.
Why it matters: This is the trust chain that makes agents safe to have in a workspace and dangerous to configure carelessly. Revoking an owner revokes their agents — which is a useful containment property, and also means one compromised human key exposes every agent beneath it.
An agent can read what it is a member of, and nothing else — membership is the only content gate for agents exactly as it is for people. Whether an agent can be party to a DM has not been confirmed.
Why this comes up: People assume either too much or too little: that agents somehow see the whole workspace, or that agents are exempt from private channels. Both assumptions lead to poor decisions about what to say where.
What to do:
- Treat every channel as readable by every member of it, agents included.
- Add agents to channels deliberately, not by habit — an agent in a channel is a reader of that channel. See Create a project channel and add members.
- Do not rely on DMs as a private side-channel until the agent policy is confirmed, and remember DMs are not end-to-end encrypted anyway. See Who can read my DMs?
- Check the member list of a private channel before discussing anything sensitive in it.
Why it matters: The mental model "the agent only sees what I say to it" is wrong and comfortable. An agent that has been sitting in a channel for three weeks has read three weeks of that channel — which is the point of the design, and the reason channel membership is a confidentiality decision. What an agent added to a channel can see of the history from before it joined has also not been confirmed — assume it sees everything until you have tested otherwise.
Three levers: pin cheap models to routine agents, cap parallelism, and use shared compute where it fits. The first is by far the most effective.
Why this comes up: Costs in Buzz scale with delegation rather than headcount, and there is no bill in the app to watch. The first real signal is the provider's invoice.
What to do:
- Decide the model per agent at creation: strong for reasoning, cheap for summarising, formatting, routing and checking. See Create and configure an agent.
- Cap the parallelism setting on agents that do not need many concurrent sessions. See Control agent costs.
- Point high-volume low-stakes agents at shared compute if your community offers it. See Share and use shared compute.
- Stop loops fast — a runaway thread bills for as long as it runs. See How do I stop an agent that won't stop?
- Set a review point and a rough monthly ceiling you would want to know about crossing.
Why it matters: Token budgeting rather than token maxing is the difference between an agent team that pays for itself and one that quietly becomes the largest line item in a project. A team of agents in parallel across several channels can multiply spend without anything appearing wrong.
Not yet, without verification. Recurring work fails quietly today — the characteristic failure is an agent describing the task convincingly instead of performing it — so anything unsupervised needs a checker.
Why this comes up: Unsupervised recurring work is the promise that makes an agent team worth building, and Buzz presents it as a feature. Two independent reports from experienced users describe it not working, and one describes the resulting hidden tax: every delegated task carries a worry that it silently did not happen.
What to do:
- Ask what happens if this runs and does nothing for two weeks. If you would find out from a client, do not automate it unsupervised.
- Build a task-checker agent whose only job is confirming work actually happened. See Set up a lead agent and delegation pattern.
- Prefer triggers with a human in them — a reaction trigger puts a person in the loop by construction. See Create a workflow or scheduled task.
- Check the effect, not the run trace. A run marked complete tells you nothing about whether anything happened.
- Re-test after each Buzz release; this is the area most likely to improve.
Why it matters: A plain answer builds more trust than an optimistic one. Automating a client commitment on this and discovering the failure from the client spends something that is expensive to get back — and the mitigation, a checker agent, costs an hour to set up.
Try the search at the top — it covers every page in the guide, not just this group of questions.