When Coordination Turns Into Work

Buzz's workflows and project surfaces test whether a shared event log can do more than preserve conversation. This chapter follows messages, reactions, pushes, and reports as they become coordinated work, then examines where approval, moderation, audit, and visible failure handling must interrupt automation. The practical judgment is whether Buzz is building a governable loop—relay coordinates, agents or external workers compute, people decide—or merely adding automation around a chat stream.

The distinction matters because a workflow can make an event consequential without making the workflow engine the source of truth.

The relay coordinates; workers do the work

Buzz describes workflows as channel-scoped YAML automation. A message, reaction, schedule, or webhook can trigger a run. The run can send a message, call an external webhook, add a reaction, request approval, or perform another supported action. The relay evaluates the trigger and coordinates the run; an agent or external worker performs the computation that may be needed. Results return to the channel as events that people and other agents can inspect.

This division keeps the event log at the center. A workflow does not need to become a private scheduler with its own conversation, identity, and memory. It listens to a relay event, resolves the relevant community and channel, performs a bounded transition, and can emit another event. The new event enters the same authentication, scope, search, audit, and delivery model as a human message. A workflow can create work, but it does not get to silently create a new definition of who is allowed to see or perform it.

The current executor makes that boundary concrete. A message action loads workflow-run and workflow metadata under the run's community, resolves the destination channel, obtains a serving write guard, and sends through an action sink. The community context is not decorative. A workflow identifier or channel name that happens to exist in more than one community must not cause a run in one community to act under another community's state.

The workflow language also separates a trigger from its action. A message filter can decide whether a particular event starts a run; conditions can decide whether a later step is reached; template variables can carry trigger text, author, or earlier step output into a message. This gives the event log a transition path into work without pretending that a trigger itself is the work. A webhook can ask an external service to build a commit, but the workflow still needs to record whether the call succeeded and what result should return to the channel.

That separation creates useful failure boundaries. A trigger may be valid while an action fails. A run may reach a conditional step and stop without sending anything. A delay may defer a transition, while a long-running human decision needs a persisted waiting state rather than a sleeping process. The repository's executor uses short bounded delays and identifies longer scheduled-resume behavior as future work. A workflow system that names these states is more dependable than one that treats every run as an undifferentiated “automation complete.”

Other actions expose the difference between a declared schema and a completed capability. The workflow format includes direct messages and topic changes, but the current executor reports those actions as not implemented. A request for approval can produce a generated token-like result, but the executor does not yet persist the approval record and resume from it.