Portable agent templates with Project connections and safe updates
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
@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
- #4164 adds structured, named MCP configuration to `buzz-acp`.
- #4588 adds Project-owned connection setup without placing credentials in portable agent data.
- #4600 defines a validated, runtime-neutral Skill bundle.
- #4271 can extend the same MCP document with HTTP transport.
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.
Contributor guide
Research direction
Start by reading the existing persona, Agent Snapshot, and managed-agent records, then review the related work in #4164, #4588, #4600, and #4271. The key questions are the template-to-agent source of truth, Project-connection binding, and version rollout or restoration. Done means these boundaries are resolved without a second registry or update system.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend-api-design, devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100