@wpfleger96 @tlongwell-block, I have the working pieces locally and would like to align the remaining boundaries with Buzz before sending more PRs.
Buzz already has agent identities, personas, managed agents and snapshots. What is missing is one coherent path for creating a reusable agent, installing it as a distinct identity, giving it Project-owned tools, and updating it safely.
Today, moving a useful agent to another Project still means rebuilding its instructions, Skills and tool setup by hand. Updates also lack a clear authority boundary: a user may mean to change one agent, but the same edit can affect the reusable definition behind several agents.
I do not think this needs a new top-level object or product name. It can extend the concepts Buzz already has:
- An agent template holds reusable instructions, pinned Skills, model defaults and logical tool requirements.
- An agent has its own key, home, workspace and private settings.
- A Project connection holds the concrete MCP command or endpoint and its credentials. Credentials are never part of the portable template.
- An immutable version makes template changes reviewable and reversible.
- Agent Snapshot is the natural portable boundary for import and export.
Product flow
Editing an agent should offer two explicit actions:
- Edit this agent changes only that agent.
- Edit its template shows which agents use the template before anything is published.
Publishing creates a version. It does not silently change running agents. Update agents shows the exact instruction, Skill and tool changes, then lets the user choose which agents receive them.
A running update should finish the current task, start the selected version, verify that the agent is available, and restore the previous version if startup fails. The UI should show the actual state throughout.
Current work
The next slice should connect these pieces to Buzz's existing persona, snapshot and managed-agent records. It should not introduce a second agent registry or a separate update system.
The remaining decisions are the source of truth between a template and an agent, how logical tool requirements bind to Project connections, and how a version is rolled out or restored across local and hosted runtimes.
@adamazad @custard-pirate @shellz-n-stuff @kerpopule @sapience7-hub, this overlaps the installation, MCP, shared-instruction and hosted-agent work already in progress. I would appreciate a read on where these boundaries should meet.
@wpfleger96 @tlongwell-block, I have the working pieces locally and would like to align the remaining boundaries with Buzz before sending more PRs.
Buzz already has agent identities, personas, managed agents and snapshots. What is missing is one coherent path for creating a reusable agent, installing it as a distinct identity, giving it Project-owned tools, and updating it safely.
Today, moving a useful agent to another Project still means rebuilding its instructions, Skills and tool setup by hand. Updates also lack a clear authority boundary: a user may mean to change one agent, but the same edit can affect the reusable definition behind several agents.
I do not think this needs a new top-level object or product name. It can extend the concepts Buzz already has:
Product flow
Editing an agent should offer two explicit actions:
Publishing creates a version. It does not silently change running agents. Update agents shows the exact instruction, Skill and tool changes, then lets the user choose which agents receive them.
A running update should finish the current task, start the selected version, verify that the agent is available, and restore the previous version if startup fails. The UI should show the actual state throughout.
Current work
buzz-acp.The next slice should connect these pieces to Buzz's existing persona, snapshot and managed-agent records. It should not introduce a second agent registry or a separate update system.
The remaining decisions are the source of truth between a template and an agent, how logical tool requirements bind to Project connections, and how a version is rolled out or restored across local and hosted runtimes.
@adamazad @custard-pirate @shellz-n-stuff @kerpopule @sapience7-hub, this overlaps the installation, MCP, shared-instruction and hosted-agent work already in progress. I would appreciate a read on where these boundaries should meet.