The problem
The bridge in #3389 connects one agent at a time. But the runtime on the other side already knows its whole roster. Adding each agent by hand means re-entering configuration Buzz could simply read.
What we propose
- Add New team → Remote team in the Agents view.
- Show the remote roster first. Nothing is created until the owner chooses.
- Pick which agents join, and which channel they join.
- Keep the names and avatars the source already uses.
- Give each selected agent its own Buzz-local identity.
- Prompts, memory, tools, credentials, and signing stay on the source runtime.
The UI calls this Remote Team. Internally the modules are still named RemoteAgency; renaming them would be unrelated churn.
Screenshots
Before:
After:
These use neutral test fixtures.
Not in scope
- AGNTCY Directory lookup
- Keeping an agent's original identity in Buzz
- Enforcing Space or project permissions on the source runtime
- MCP Apps rendering
- Leave, revoke, and refresh actions
Questions for maintainers
- Does New team → Remote team fit how teams work today?
- Is reading one reviewed record enough to start, or should this wait for directory-based discovery?
- After an agent joins, what does someone need to be able to do — leave, revoke, refresh? Which of those are required for a first version?
The problem
The bridge in #3389 connects one agent at a time. But the runtime on the other side already knows its whole roster. Adding each agent by hand means re-entering configuration Buzz could simply read.
What we propose
The UI calls this Remote Team. Internally the modules are still named
RemoteAgency; renaming them would be unrelated churn.Screenshots
Before:
After:
These use neutral test fixtures.
Not in scope
Questions for maintainers