Issue:
I'm running a multi-agent organization where each primary agent is a Buzz agent backed by its own Hermes profile and gateway. Per the organization's workflow, the overseer agent is responsible for assembling project clusters and creating project update channels on the relay when a new project is approved.
Today this requires a manual, out-of-band step: the overseer agent has to request that a channel be created, and the human operator has to drop to a terminal and run buzz channels create themselves. The agent can see channels and post messages, but it can't create them.
It would be much cleaner if the agent could create channels directly as part of its normal tool loop — i.e., when the overseer determines a project needs a channel, it calls a tool and the channel appears, with the agent's own identity as the creator.
Current state
The Buzz adapter (plugins/platforms/buzz/adapter.py) shells out to buzz.exe for message send/receive, reactions, channel listing, and DM discovery. It does not expose channel lifecycle commands (channels create, channels update, channels archive, channels delete, etc.).
There is no hermes-buzz toolset defined in toolsets.py. Buzz is wired purely through the platform adapter plugin. Other platforms (Telegram, Discord, Slack, WhatsApp, etc.) have corresponding hermes-* toolsets that bundle _HERMES_CORE_TOOLS plus platform-specific tools — Buzz has nothing equivalent.
Agents running via the Buzz gateway (buzz-acp / hermes-acp) don't get a terminal tool, so they can't shell out to buzz.exe on their own to fill the gap.
The credentials needed (BUZZ_PRIVATE_KEY, BUZZ_CLI_PATH, BUZZ_RELAY_URL) are already present in each hermes agent's profile .env and consumed by the adapter — they're available, just not accessible from a tool.
What's needed
A hermes-buzz toolset (and underlying tool module) that lets a Buzz agent manage channels via tool calls. Minimal version:
A tool module (e.g. tools/buzz_channels.py) following the existing self-registration pattern (registry.register() at module level, same as discord_tool.py, slack_tool.py, etc.).
One or more tool actions — starting with channels_create, optionally expanding to channels_update, channels_archive, channels_delete, channels_list. The Discord tool's action-enum pattern (single tool dispatching to multiple handlers) seems like a good fit.
Credential resolution — the tool reads BUZZ_PRIVATE_KEY, BUZZ_CLI_PATH, and BUZZ_RELAY_URL from the profile's secret scope / env at call time, and shells out to buzz.exe (sync subprocess.run() or async asyncio.create_subprocess_exec(), matching the adapter's existing _exec_buzz() pattern).
A hermes-buzz toolset entry in toolsets.py (or rely on the auto-generator at toolsets.py lines 795-809 if the Buzz platform is registered in the platform registry — it is, via adapter.py register()).
Profile enablement — the toolset needs to be addable to a profile's platform_toolsets so it can be scoped to specific agents (e.g. only Electryone gets it, not every Buzz agent).
Example workflow
The overseer agent is in a cooperative planning conversation and determines a project needs a channel.
The overseer calls buzz_channels → action=create, name="Project X Updates", type=stream, visibility=private, description="...".
The tool shells out to buzz.exe channels create ..., the relay creates the channel under the overseer's identity, and the tool returns the channel UUID + details.
The overseer now has the channel and can post to it (via the existing adapter send() path) — all in-thread, no human terminal step.
Why this matters beyond one organization
Any multi-agent setup running on Buzz where agents need to provision their own channels (project channels, sub-project channels, working groups, ephemeral channels) would benefit from agents being able to do this directly.
It closes the gap between "agent can read/post in channels" and "agent can manage channels" — the latter is currently a human-only action.
It brings Buzz in line with how other platforms are tool-enabled (Discord has discord/discord_admin, Slack has its tools, etc.). Buzz is currently the odd one out.
Non-goals / optional scope
I'm not asking for a full channel lifecycle admin suite day one — channels_create is the immediate need. update/archive/delete/list can follow.
I'm not asking for the adapter itself to change — the tool can shell out to the CLI independently. The adapter and the tool are separate paths to the same binary.
I'm not asking for this to be enabled by default for all Buzz agents — toolset scoping per profile is the right model.
Issue:
I'm running a multi-agent organization where each primary agent is a Buzz agent backed by its own Hermes profile and gateway. Per the organization's workflow, the overseer agent is responsible for assembling project clusters and creating project update channels on the relay when a new project is approved.
Today this requires a manual, out-of-band step: the overseer agent has to request that a channel be created, and the human operator has to drop to a terminal and run buzz channels create themselves. The agent can see channels and post messages, but it can't create them.
It would be much cleaner if the agent could create channels directly as part of its normal tool loop — i.e., when the overseer determines a project needs a channel, it calls a tool and the channel appears, with the agent's own identity as the creator.
Current state
The Buzz adapter (plugins/platforms/buzz/adapter.py) shells out to buzz.exe for message send/receive, reactions, channel listing, and DM discovery. It does not expose channel lifecycle commands (channels create, channels update, channels archive, channels delete, etc.).
There is no hermes-buzz toolset defined in toolsets.py. Buzz is wired purely through the platform adapter plugin. Other platforms (Telegram, Discord, Slack, WhatsApp, etc.) have corresponding hermes-* toolsets that bundle _HERMES_CORE_TOOLS plus platform-specific tools — Buzz has nothing equivalent.
Agents running via the Buzz gateway (buzz-acp / hermes-acp) don't get a terminal tool, so they can't shell out to buzz.exe on their own to fill the gap.
The credentials needed (BUZZ_PRIVATE_KEY, BUZZ_CLI_PATH, BUZZ_RELAY_URL) are already present in each hermes agent's profile .env and consumed by the adapter — they're available, just not accessible from a tool.
What's needed
A hermes-buzz toolset (and underlying tool module) that lets a Buzz agent manage channels via tool calls. Minimal version:
A tool module (e.g. tools/buzz_channels.py) following the existing self-registration pattern (registry.register() at module level, same as discord_tool.py, slack_tool.py, etc.).
One or more tool actions — starting with channels_create, optionally expanding to channels_update, channels_archive, channels_delete, channels_list. The Discord tool's action-enum pattern (single tool dispatching to multiple handlers) seems like a good fit.
Credential resolution — the tool reads BUZZ_PRIVATE_KEY, BUZZ_CLI_PATH, and BUZZ_RELAY_URL from the profile's secret scope / env at call time, and shells out to buzz.exe (sync subprocess.run() or async asyncio.create_subprocess_exec(), matching the adapter's existing _exec_buzz() pattern).
A hermes-buzz toolset entry in toolsets.py (or rely on the auto-generator at toolsets.py lines 795-809 if the Buzz platform is registered in the platform registry — it is, via adapter.py register()).
Profile enablement — the toolset needs to be addable to a profile's platform_toolsets so it can be scoped to specific agents (e.g. only Electryone gets it, not every Buzz agent).
Example workflow
The overseer agent is in a cooperative planning conversation and determines a project needs a channel.
The overseer calls buzz_channels → action=create, name="Project X Updates", type=stream, visibility=private, description="...".
The tool shells out to buzz.exe channels create ..., the relay creates the channel under the overseer's identity, and the tool returns the channel UUID + details.
The overseer now has the channel and can post to it (via the existing adapter send() path) — all in-thread, no human terminal step.
Why this matters beyond one organization
Any multi-agent setup running on Buzz where agents need to provision their own channels (project channels, sub-project channels, working groups, ephemeral channels) would benefit from agents being able to do this directly.
It closes the gap between "agent can read/post in channels" and "agent can manage channels" — the latter is currently a human-only action.
It brings Buzz in line with how other platforms are tool-enabled (Discord has discord/discord_admin, Slack has its tools, etc.). Buzz is currently the odd one out.
Non-goals / optional scope
I'm not asking for a full channel lifecycle admin suite day one — channels_create is the immediate need. update/archive/delete/list can follow.
I'm not asking for the adapter itself to change — the tool can shell out to the CLI independently. The adapter and the tool are separate paths to the same binary.
I'm not asking for this to be enabled by default for all Buzz agents — toolset scoping per profile is the right model.