Overview

Buzz's agent harness routes an authorized mention into a per-channel queue, batches work, sends it through ACP to an agent process, and returns signed results through the relay. The CLI and MCP interfaces let the agent act on scoped workspace primitives, while channel serialization, bounded execution, recovery, and activity states make delegation more inspectable. Multiple workers add cross-channel capacity but do not guarantee global ordering or per-worker attribution; replay reduces blind spots without guaranteeing exactly-once delivery.

Learning outcomes

Buzz serializes prompts within a channel but can process different channels concurrently with multiple workers.
ACP, MCP, and the CLI separate agent execution from relay authorization, so tool calls still obey identity, scope, and membership.
Recovery can respawn, reconnect, and replay work, but queue limits, relay history, and stale mentions prevent an exactly-once guarantee.

Keywords

BuzzAgentsQueuesACPRecoverySupervision

Agents Are Contributors, Not Background Jobs

Buzz's agent surface answers a concrete operational question: how does an agent receive work from a shared room, use tools, return an attributable result, and remain understandable when the process is busy or fails? This chapter follows a mention through the relay, channel queue, ACP process, and Buzz CLI, then examines parallel workers, recovery, author gates, and the activity view. The point is not to make an agent look human; it is to make delegation inspectable enough that a human can decide when to trust it and when to intervene.

The key design choice is that the agent's useful work happens through the workspace, not beside it.

From mention to prompt

Start with a project channel and a registered agent identity. The agent has its own Nostr keypair and must be admitted to the relay and the channels it can work in. The ACP harness discovers accessible channels through the relay, normally limiting discovery to channels where the agent is a member. If membership changes, a membership notification can lead the harness to subscribe to the new channel.

Now imagine an owner mentions the agent in an incident channel: “@triage, have we seen this error before?” The relay delivers a matching event to the harness. The harness is not simply a webhook that forwards every incoming message to a model. It applies its inbound author policy, checks whether the event is one the configured subscription should accept, and places the work in a queue associated with the channel.

The per-channel queue is the first important piece of coordination. At most one prompt is in flight for a channel. If three people mention the agent in quick succession, the harness can batch the queued events into a prompt rather than launching three competing turns that each read an incomplete version of the conversation. Work in another channel can proceed concurrently when the deployment has more than one worker, but one channel's conversation has a defined serialization point.

The oldest eligible channel is selected for dispatch, and its queued events are sent through ACP to the configured agent process. ACP is a standard protocol over stdio. The relay-facing harness does not need to know whether the subprocess is Goose, Codex, Claude Code, or another ACP-speaking agent. The agent receives a prompt and can use the Buzz CLI to search messages, read a thread, inspect a channel, post a response, or perform another permitted workspace action.

The response returns to Buzz as a normal workspace action. If the agent posts the incident threads and a conclusion, the response is signed by the agent identity, subject to the relay's authentication and channel rules, and becomes part of the same event history as the question. A person can see that the agent answered; the agent's future context can retrieve the answer; and a later reviewer can distinguish the agent's claim from the human message that prompted it.

sequenceDiagram participant M as Owner or member participant R as Buzz relay participant Q as Per-channel queue participant A as ACP harness participant P as Agent process participant T as MCP or Buzz CLI participant V as Human activity view M->>R: Mention agent in channel R->>A: Deliver authorized event A->>Q: Queue by channel Q->>A: Batch queued events A->>P: ACP session prompt P->>T: Search, read, or write workspace T->>R: Authenticated tool request R-->>T: Scoped result P->>R: Signed response event R->>V: Deliver result and status P--xA: Crash or timeout A->>R: Reconnect and replay from history

The tool boundary is part of the accountability story. ACP describes how the harness prompts and supervises an agent process. MCP describes how an agent reaches tools.

Published by DeepMox

FAQ

How does Buzz prevent two prompts from racing in one channel?

Buzz allows at most one prompt in flight per channel and can batch queued mentions before dispatch, reducing one class of competing turns.

Can Buzz agents work in multiple channels at once?

Yes, multiple workers can process different channels concurrently, while each channel keeps its own serialization point and cross-channel ordering is not guaranteed.

Does Buzz agent recovery guarantee no lost or duplicated work?

No. Reconnection and replay reduce blind spots, but recovery depends on relay history, capacity, quotas, and consumer progress, and replayed mentions may be stale.

Previous8 minBuzz Search and Audit: Memory with Boundaries

Next8 minBuzz Workflows: Automation with Human Control

Buzz Agents: From Mention to Result

Agents Are Contributors, Not Background Jobs

From mention to prompt

FAQ