Workflows: what they can and cannot do today
Workflows are automation scoped to a channel, with five trigger types — a message, a reaction, a posted diff, a schedule, or a webhook — built in a visual editor, and traced runs you can inspect afterwards.
Two things are true about them today and both belong in any plan that uses them. Scheduled execution is unreliable: the characteristic failure is an agent describing the task rather than performing it, reported independently by multiple teams. And approval gates do not work end to end — the schema, API, tool and UI all exist, but the executor does not suspend and resume, so a run reaching an approval step is marked Failed.
What changed in v0.5.18 is the authoring side, and it changed a lot. Workflows are no longer written as raw YAML: there is a route-addressable editor with a form mode and a YAML mode that convert losslessly in both directions, structured trigger filters, deterministic template variables with autocomplete in message text, plain-language summaries on workflow cards, and a warning before you activate something likely to fire constantly.
What did not change is the executor. Upstream says so plainly — scheduling "remains the already-shipped implementation" — and the approval gate still fails with a structured approval_not_supported code naming WF-08. Four releases and a full editor later, that has not moved.
Why it matters to you
Buzz keeps shipping the surface before the semantics. This is the clearest instance: the authoring experience is now better than most automation tools, sitting on execution you cannot yet trust to run on a schedule or pause for a human.
The practical consequence is that workflows have become easier to build wrong. A polished editor invites you to build the five-step automation that the executor will quietly fail to run, and the polish reads as maturity.
If your team wants human sign-off before certain agent work proceeds, the approval gap is the significant one. The approval gate is the natural enforcement mechanism for that rule, and it is exactly the piece that is missing. Until it lands, oversight in Buzz holds by convention rather than by system.
That is not a reason to avoid Buzz. It is a reason to say so explicitly in a project design rather than assuming a control that is not there.
How to apply it
Ask what happens if a workflow silently does nothing for two weeks, and let the answer decide whether to automate it unsupervised.
Prefer reaction triggers where possible — a human adding an emoji puts a person in the loop by construction.
Filter at the trigger. An unfiltered message trigger fires on everything in the channel, including replies the workflow itself caused. The editor's structured conditions make this cheap, and the activation warning will tell you when you have skipped it.
Read the semantic summary on the card before activating a workflow someone else wrote. It is the fastest audit of a shared library you have.
Pair anything recurring with a verification agent whose only job is confirming the work happened. See Set up a lead agent and delegation pattern.
Check effects rather than run traces. The trace is trustworthy about whether and how a run failed; a run marked complete still says nothing about whether anything changed.
For approvals, use the manual pattern: the agent produces, posts, and stops with a standing instruction not to proceed without a human reply. The approval message is a signed event, which is most of what the gate would have given you.
Re-test after each Buzz release. This is the area most likely to improve — and the area where improvement has so far arrived everywhere except the executor.
If you ignore this
Silent failure costs more than loud failure, because it consumes trust rather than attention. Users describe a hidden tax on every delegated task — the background worry that it did not happen — and that tax is what makes an agent team feel like work rather than leverage.
Building the check in from the start removes it, and costs about an hour.
Examples
A daily 9am workflow "check email and list actions" produces a message every morning describing what it would check. It looks like it is working for as long as nobody opens the result carefully. The editor it was built in gave no hint of this, because the problem is downstream of authoring.
A workflow with a request_approval step fails rather than waiting. The workflow is written correctly; the feature is not finished. The run tells you so — approval_not_supported, pointing at WF-08 — so the diagnosis is free even though the wait is still missing.
Designing a project's approve-before controls around Buzz's approval gates. They do not currently exist as a working control, whatever the UI suggests — and the better the UI gets, the more convincing the suggestion.
Last checked: Buzz v0.5.20, 2026-09-02.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026