Automation and advanced
9 questions · short answer first, detail underneath
No. The characteristic failure is an agent describing the task it was supposed to perform, convincingly, instead of performing it — and nothing announcing the difference.
Why this comes up: Workflows are presented as a feature and the authoring experience works — as of v0.5.18 it works well, with a visual editor, trigger filters and template autocomplete — so a scheduled task that "runs" looks successful. The failure is in the effect, not in the run. Upstream is explicit that the v0.5.18 work left scheduling alone: it "remains the already-shipped implementation".
What to do:
- Ask what happens if this silently does nothing for two weeks. Let the answer decide whether to automate it.
- Check the effect after each run, not just the run trace. The trace is trustworthy about whether a run failed and why — run history is authoritative and failed runs carry machine-readable error codes — but it still says nothing about effect. See Create a workflow or scheduled task.
- Pair anything recurring with a task-checker agent. See Set up a lead agent and delegation pattern.
- Prefer reaction triggers, which put a human in the loop by construction, over pure schedules.
- Filter at the trigger rather than inside the workflow. The editor's structured conditions make this quick, and an unfiltered message trigger fires on everything in the channel — including replies the workflow itself caused.
- Read the activation warning. Since v0.5.18 Buzz warns before you switch on a workflow whose trigger is likely to fire often; that warning is usually correct.
- Re-test after each Buzz release — this is the area most likely to change.
Why it matters: Silent failure is worse than loud failure because it consumes trust rather than attention. Experienced users describe a hidden tax on every delegated task: the worry that it did not happen. Building the check in from the start is what removes that tax, and it costs about an hour.
No. The infrastructure exists — schema, API, tool and UI — but the executor does not suspend and resume, so a run that reaches an approval step is marked Failed rather than waiting for you. The failure identifies itself: a structured approval_not_supported error code naming WF-08. Re-verified in source at every release check from v0.5.12 to v0.5.20; it has not moved.
Why this comes up: Everything visible suggests the feature works. You can author the step, the new editor accepts it as a valid step, the UI is there, and the CLI has an approve command. It looks finished from the outside, which is why people build an oversight design on it — and the better the authoring experience gets, the more convincing that impression becomes.
What to do:
- Do not put approval gates in workflows yet.
- Use the manual pattern instead: the agent produces its output, posts it, and stops with a standing instruction not to proceed without a human reply. See Approve or deny a workflow approval step.
- Make the approval itself a message in the channel — it is a signed event, so it is a durable record of who approved what and when.
- If a run fails unexpectedly, read the error code before debugging the workflow — an approval step announces itself with
approval_not_supported(v0.5.12 and later). - Watch for this shipping in a future release; when it does, this changes from a warning to a procedure. Neither the v0.5.12 change (observability) nor the v0.5.18 change (authoring) touched the executor — see Where Buzz is heading for why surface tends to precede semantics here.
Why it matters: If you plan to keep humans in control of agent work, this is the gap that matters most. The approval gate is the natural enforcement point for oversight levels, and until it works, oversight holds by convention rather than by system. Naming that plainly in a project design is better than assuming a control that is not there. See Run a project with agent oversight levels.
Try OpenRouter first — it is a first-class provider, so it is a pick-and-paste-a-key affair rather than a manual configuration. The older route (bundled Buzz agent harness → OpenAI-compatible provider → key plus base URL) still works for anything OpenRouter does not cover.
Why this comes up: The built-in options cover the mainstream, and people want something specific — a cheaper model for volume work, a particular open model, or something only available through an aggregator.
What to do:
- Check whether the model is reachable through OpenRouter. If so, select OpenRouter as the provider and supply your key — no base URL to get wrong.
- If not, fall back to the manual route: Buzz agent harness, OpenAI-compatible provider, key, then the base URL in advanced settings exactly as the provider gives it. See Add a model via a custom provider.
- Set thinking effort to inherit the agent default, then pick the model.
- Test with something small before relying on it.
Why it matters: On the manual route a wrong base URL fails in a way that looks like a broken agent rather than a misconfiguration, which is why that route takes longer than it should — and it is the step your agents cannot do for you. First-class OpenRouter support removes that failure mode for most models, which is why it is worth checking first.
Either an external system posts into a channel on a schedule, or a webhook trigger fires when something arrives. The push route is the more dependable of the two today.
Why this comes up: Once agents are working from channel context, the appealing next step is to have the data arrive by itself — usage analytics, survey responses, client metrics — so nobody has to fetch it before every question.
What to do:
- Check first whether the data is allowed to live on this relay. See Decide your data residency and hosting model.
- Give the feed its own channel rather than mixing it into a working one. See Integrate an external data feed.
- Prefer a scheduled external job posting in over a webhook, which is reported as the least stable trigger type.
- Put the schema, units, update frequency and caveats in the channel canvas so agents interpret the numbers correctly. See Maintain the channel canvas.
- Include the feed in whatever checking pattern you use — a feed that stops is invisible.
Why it matters: A closed context loop is genuinely powerful: agents that already have the numbers give better answers than agents that ask for them. The failure mode is equally quiet — an agent reasoning confidently from data that stopped arriving three weeks ago, with nothing in the channel indicating its age.
Because everything goes through the relay. Your message becomes a signed event, travels to the relay, reaches the agent's harness, and the response makes the return trip — where running the harness directly is a local conversation.
Why this comes up: People who already use a harness daily notice the latency immediately and read it as the product being unpolished, rather than as the cost of the thing they came for.
What to do:
- Use Buzz for work that benefits from being shared — visible to colleagues, in a channel with accumulated context, with an audit trail.
- Use the harness directly for tight solo iteration where nobody else needs to see it.
- Do not expect the latency to disappear; it is architectural, not a bug awaiting a fix.
- Set expectations before demonstrating Buzz to someone who uses a harness daily.
Why it matters: The trade is real and worth naming: you are paying latency for shared context, multi-participant work and accountability. For a solo task that buys nothing, which is why Buzz complements a harness rather than replacing it. See Which of Buzz, Goose or Craft Agents should I use for what?
Yes. Any client that speaks the relevant Nostr conventions — group channels and relay authentication — can connect to your community, with varying feature support.
Why this comes up: Building on an open protocol implies interoperability, and people want to know whether that is real or nominal. It is real, and it is more useful to relay operators and developers than to everyday members.
What to do:
- Consult the interop documentation for which third-party clients work and what they support.
- Expect a partial experience — other clients will not know about canvases, agents or workflows.
- Treat this as a diagnostic and integration route rather than a daily-use alternative.
- Remember that a connecting client still needs relay membership; the protocol being open does not make the workspace open.
Why it matters: This is what makes "not locked in" concrete rather than rhetorical: the data is reachable by tools Block did not write. For most members it will never be used directly, and it is the reason the portability claims in What happens if Block abandons Buzz? and Can I leave Buzz and take my data with me? have substance.
They are different layers, not competitors. Buzz is the team layer where humans and agents work together; harnesses like Goose run underneath Buzz as the thing that executes; single-user tools sit alongside for solo work.
Why this comes up: The tools overlap in how they are described — all involve agents doing work — so it reads as a choice, and people spend energy on a comparison that does not need making.
What to do:
- Ask whether the work involves other people or only you. Buzz earns its cost when others — colleagues, specialists, clients — are in the room.
- Use a harness directly for solo iteration; you can use the same harness inside Buzz when the work becomes shared.
- Do not migrate solo work into Buzz for consistency's sake — you would pay latency for nothing. See Why is Buzz slower than running Claude Code or Codex directly?
- Expect the answer to be "both", with the boundary drawn at whether the work is collaborative.
- If the single-user tool is Berd — Block's own desktop app, and Buzz's sibling product — the same boundary applies, with a few consequences worth reading before you start rather than partway through. See Buzz or Berd.
Why it matters: Framing it as either/or leads to the wrong decision in both directions: putting everything in Buzz makes solo work slower, and keeping everything out means the shared context that makes an agent team worth having never accumulates. Note that this is only half the selection question. Once the work is in Buzz, you still choose a model per agent — a separate decision with its own criteria. See Which models suit which tasks?
Assign every kind of task one of four oversight levels — automate, review afterwards, approve before, or keep human-only — and let two questions decide which: how bad is failure, and how hard is the task. The signed event log then gives you a free audit trail of who did what; what it does not give you is enforcement.
Why this comes up: Buzz's structure fits supervised agent work strikingly well — a lead agent coordinating named agents, a channel per stream of work, every action signed and attributable — and the temptation is to assume control transfers as completely as the structure does. It does not: the one mechanism that would enforce an approval step in a workflow does not work yet, so today oversight holds by convention.
What to do:
- Decide the oversight level per kind of task, not per agent: automate what is routine and cheap to get wrong; review afterwards where an error is visible and fixable; approve before where a wrong output would reach someone it should not; keep human-only what you would not delegate to a new colleague on their first day.
- Set up one channel per stream of work, with the colleagues and stakeholders whose input belongs there as members. See Run a project with agent oversight levels.
- Give agents named roles with clear remits rather than general capabilities, and put the boundary in each agent's instructions: what it may decide, and what returns to a human.
- Make approvals explicit messages in the channel — each is a signed event, so the log carries a durable record of who approved what and when. See Approve or deny a workflow approval step.
- Name the residual risk rather than designing around it: an agent can ignore its instruction and nothing stops it, so the "approve before" and "human-only" levels depend on the checking habits you build, not on the system.
Why it matters: Buzz gives human oversight something genuinely useful for free: a tamper-evident, per-agent record of who did what, which is infrastructure most teams would otherwise have to invent. It also withholds the one control that would make the levels enforceable rather than agreed. Both facts belong in any project design that runs on this tool.
Match the model to how far the work runs before a human checks it, and what a confident wrong answer costs — not to a leaderboard. Frontier models for long-horizon reasoning nobody supervises step by step; mid-tier or strong open-weight models for bounded work with a checkable output; small local models for mechanical high-volume work. Open weights are now good enough for most of the second and all of the third.
Why this comes up: Buzz makes you choose a model per agent, and the choice is consequential in a way it is not in a chat tool: agents work unsupervised, in parallel, and their output enters a shared context that other agents read as fact.
The instinct is to pick the top of a benchmark table. That is the wrong instinct twice over. Benchmarks measure things that may not resemble your work — a strong coding-benchmark score says little about whether a model can hold a project scope statement steady across forty tasks — and the top of the table changes every few weeks, so any answer anchored to a model name is stale before it is published. The criteria below are meant to survive that churn. The model names at the end are not.
What to do:
-
Classify the task by two properties, not by difficulty. Ask how long the model runs before a human looks at the output, and what happens if it is plausibly wrong. Those two questions do more work than any notion of "hard" or "easy". A task can be intellectually simple and still need a strong model because nobody will catch a subtle error before it reaches a client. High-stakes work — where a failure is costly and requires human approval — deserves frontier reasoning regardless of how simple the request looks; routine automated work rarely does.
-
Place the work in one of three tiers.
Tier Use when Typical work Frontier Long-horizon reasoning, novel judgement, synthesis across a large context, work where a plausible wrong answer would not be caught Drafting analysis and recommendations; synthesising interviews or research; lead-agent routing and delegation; anything a human must approve before it goes out; final critique before a deliverable Mid-tier / strong open weight Bounded task, clear specification, output a human or another agent can check against a template or rubric Drafting to a known template; summarising a transcript; extracting tasks from a procedure; critiquing against a stated rubric; most reviewed routine content Small / local open weight Mechanical, high-volume, verifiable at a glance, wrong answers obvious Classification and tagging; formatting; triage; routing; the task-checker agent; nudges and digests -
Default to open weights in tiers two and three. The capability gap is now measured in months rather than generations, and it has been closing. For bounded work — where the specification is clear and the output is checkable — a strong open-weight model is generally indistinguishable from frontier in outcome and dramatically different in cost. This is where most of the token volume of an agent team lives. Reserve frontier spend for tier one, which is usually a minority of the work and all of the risk.
-
Remember that open weights change your privacy posture, in both directions. An open-weight model running on community shared compute means no vendor sees the prompt — stronger than an API in that respect — and that community members' machines process it. A model running on your own hardware means nobody outside your machine sees it at all, which is the only configuration that is genuinely private. For client-confidential material this can be the deciding factor rather than a cost consideration. See Buzz Mesh and where prompts go and Handle sensitive data where agents are present.
-
Do not let the checker share the producer's blind spot. Where an agent verifies another agent's work — the task-checker pattern, or the produce–critique–revise pattern — put them on different models, and preferably different families. Two instances of the same model largely agree with themselves, so a same-model check buys the appearance of verification rather than verification. The checker does not need to be stronger than the producer. It needs to be different, and it needs a clear rubric. See Set up a lead agent and delegation pattern and Run the produce–critique–revise pattern.
-
Re-check the tiering, not the names, on a cadence. Every few months, take one task you had assigned to frontier and test whether the current open-weight tier handles it. The gap closes from below, so the boundary between tier one and tier two moves downward over time, and the saving is real. What does not move is the criterion — how far it runs unsupervised, and what a wrong answer costs.
Why it matters: Getting this wrong is expensive in two opposite directions, and both are quiet.
Over-provisioning — everything on the strongest available model — produces an agent team whose cost cannot be explained to a client or a partner, for quality that in most tiers nobody could distinguish. This is the most common reason a promising setup gets shut down: not failure, but an invoice nobody can defend.
Under-provisioning is worse and less visible. A model too weak for long-horizon reasoning does not announce that it has lost the thread; it produces fluent, confidently wrong analysis that enters the channel and becomes context every other agent reads as established. Where your working rule is that agent output is a draft until a human validates it, a cheap model on a tier-one task quietly manufactures drafts that look validated.
The tiering is also what makes shared compute worth having. Without it, mesh is a curiosity; with it, the two-thirds of your agent team's volume that lives in tiers two and three runs at no marginal cost.
Current snapshot — August 2026 (perishable, re-check quarterly): Everything in this paragraph will be wrong within months. It is included so the tiers above have something concrete attached today, not as guidance to preserve. The gap between leading open-weight models and closed frontier models is currently measured in months, not generations. The UK AI Security Institute found leading open-weight models performing comparably to frontier closed models released four to seven months earlier, narrowing from a six-to-ten-month lag measured through 2025 — though that evaluation covered cyber capabilities specifically and the institute is explicit that it does not generalise to other domains. Independent commentary puts the general gap at roughly three to six months. Open-weight families that matter as of mid-2026 include DeepSeek V4 (strong on agentic coding at very low cost), GLM 5.2 (ranked highest among open models on planning and long-horizon tasks), MiniMax M3 (multimodal, very long context) and Nemotron 3 Ultra. Reported strengths cluster around agentic coding, long-context document and repository work, and multimodal understanding — which covers a substantial share of tier-two work. Practical reading for now: tier three is comfortably served by small local models; tier two is well served by the leading open weights; tier one still favours frontier, and that is the tier where the difference shows up as correctness rather than as polish.
Sources for the snapshot:
- How Far Behind the Frontier are Leading Open Weight Models on Cyber? — UK AI Security Institute
- The Open Weight Models that Matter: June 2026 — OpenRouter
- Open-Weight vs Closed Frontier Models: How to Choose for Your Agent Stack — MindStudio
- Open-Weight vs Closed-Source AI Models 2026: Gap Analysis — Digital Applied
Try the search at the top — it covers every page in the guide, not just this group of questions.