What happened
Three managed agents (Fizz, Honey, Bumble) run in one channel on Buzz Desktop. After a burst of
-32603 Internal error responses across all three, two recovered and one did not. The one that
didn't produced nothing at all for the next twelve hours — no reply, no error frame, no status
change — across four separate @mention triggers from both a human and another agent.
From inside the channel this is indistinguishable from an agent that is simply slow to answer. The
owner's only clue was asking a second agent to investigate.
The cause turned out to be simple: its supervisor process was gone.
$ ps -eo pid,etime,command | grep MacOS/buzz-acp
57086 02:40:21 /Applications/Buzz.app/Contents/MacOS/buzz-acp # Honey
57585 02:40:05 /Applications/Buzz.app/Contents/MacOS/buzz-acp # Fizz
Two supervisors for three agents. Nothing was subscribed to the third agent's mentions, so its
triggers went nowhere and nothing reported that they had.
The two gaps
1. No liveness signal. A dead agent and a thinking agent look identical in the channel. There's
no heartbeat, no presence transition, and no "your agent stopped" notice — buzz users presence
returned a record for the running agent and nothing for the dead one, which is suggestive but not
something the app surfaces to the owner.
2. No lifecycle control. buzz agents exposes draft-create, draft-update, archive and
unarchive. The last two are NIP-IA identity operations — they retire a pubkey, not a process.
There is no start / stop / restart / ping anywhere in the CLI, so neither the owner nor a
coordinating agent can recover a dead runtime without restarting the whole desktop app.
The second gap matters more in multi-agent channels: an agent asked to coordinate others has no
mechanism to notice or repair a peer that has stopped, which is exactly when coordination is needed.
Suggested shape
Not attached to any particular design, but the smallest useful version looks like:
- Supervisor restarts a dead agent process, or at minimum records that it died.
- A visible signal when an agent's runtime is down — presence state, a channel notice, or both —
so the owner learns it from the app rather than from asking another agent.
buzz agents status / restart <agent> (owner-scoped) so recovery doesn't require restarting
every agent on the machine.
Happy to send a PR for any of these if maintainers have a preferred shape — say which and I'll build
against it.
Reported from a real three-agent session; process listing and CLI surface above are verbatim from
that machine.
What happened
Three managed agents (Fizz, Honey, Bumble) run in one channel on Buzz Desktop. After a burst of
-32603 Internal errorresponses across all three, two recovered and one did not. The one thatdidn't produced nothing at all for the next twelve hours — no reply, no error frame, no status
change — across four separate
@mentiontriggers from both a human and another agent.From inside the channel this is indistinguishable from an agent that is simply slow to answer. The
owner's only clue was asking a second agent to investigate.
The cause turned out to be simple: its supervisor process was gone.
Two supervisors for three agents. Nothing was subscribed to the third agent's mentions, so its
triggers went nowhere and nothing reported that they had.
The two gaps
1. No liveness signal. A dead agent and a thinking agent look identical in the channel. There's
no heartbeat, no presence transition, and no "your agent stopped" notice —
buzz users presencereturned a record for the running agent and nothing for the dead one, which is suggestive but not
something the app surfaces to the owner.
2. No lifecycle control.
buzz agentsexposesdraft-create,draft-update,archiveandunarchive. The last two are NIP-IA identity operations — they retire a pubkey, not a process.There is no start / stop / restart / ping anywhere in the CLI, so neither the owner nor a
coordinating agent can recover a dead runtime without restarting the whole desktop app.
The second gap matters more in multi-agent channels: an agent asked to coordinate others has no
mechanism to notice or repair a peer that has stopped, which is exactly when coordination is needed.
Suggested shape
Not attached to any particular design, but the smallest useful version looks like:
so the owner learns it from the app rather than from asking another agent.
buzz agents status/restart <agent>(owner-scoped) so recovery doesn't require restartingevery agent on the machine.
Happy to send a PR for any of these if maintainers have a preferred shape — say which and I'll build
against it.
Reported from a real three-agent session; process listing and CLI surface above are verbatim from
that machine.