Why this needs a proper discussion
There is a clear and growing need for agents that do not depend on a Buzz Desktop process remaining open:
- agents that keep working after a laptop is closed;
- agents running on a VPS, home server, or other persistent machine;
- self-hosted communities where Desktop is only used as a client;
- agents that can be started, stopped, and recovered without tying their lifetime to one workstation.
The current Desktop-managed model is not a good foundation for that. It makes the machine running the Desktop app responsible for hosting the agent, while the agent itself is otherwise a relay-visible identity with durable history and presence.
That gap has already produced many different proposals and implementations. They address overlapping parts of the same problem, but often make different assumptions about identity, ownership, lifecycle, credentials, deployment, and remote control.
I know there is already 'Run on' UI in the Desktop app, but I think it would be within Buzz's design that we can have external beacons/nodes to publish to the relay they're available as execution platform.
Related work
Core hosting and architecture:
- #2859 — first-party server-hosted agents via
buzz-spawner
- #3554 — machine enrollment and many agents per host
- #2663 — external non-ACP agents with realtime relay access
- #3227 — headless, owner-approved app-integration agents
- #3628 — headless/self-hosted persona seats
- #2682 — using Buzz as a client from any device
- #3034 — provider-backed agents showing incorrect local runtime state
- #3113 — original
buzz-spawner implementation
- #3185–#3188 — expanded server-agent stack
- #3323 — provider runtime projection fix
- #3449 — SSH/provider-based remote agents
- #3551 — self-hosted backend framework and always-on agents
- #3748 — formal remote-agent management specification
- #3924 — relay-as-management-plane vision
External and connected-agent model:
- #3054 — externally-created agents missing from the Agents view
- #3996 — first-class Agent View for remote agents
- #2987 — external agents blocked by mention eligibility
- #3267 — show relay-connected agents
- #3746 — authorized external agent identities
- #3803 — show external relay agents in the Agents view
- #4006 — connect self-hosted agents
- #4029 — add connected agents to channels
- #4144 — scope connected agents by community
- #4146 — detect durable self-hosted agents
- #2942 and #3964 — external-agent CLI and realtime-listen primitives
Cross-device and lifecycle issues
Relevant implementation work includes #2314, #2514, #2605, #2857, #3110, #3292, #3448, #3906, #4023, #4047, #4058, #4129, and #4137.
What already seems true
VISION_REMOTE_AGENTS.md provides a useful starting point:
- the agent is its identity, history, and relay presence—not the process currently running it;
- the machine is a replaceable body;
- the relay is already Buzz’s management plane;
- Desktop should not need to maintain a permanent substrate-specific control channel;
- deployment and runtime details should remain replaceable implementation details;
- remote execution has real costs around key custody, substrate ownership, ephemeral workspace state, and recovery.
That gives us a strong product principle:
Hosted agents should be able to outlive the client that created or configured them, while remaining the same relay-native agent.
Remote execution should not create a second kind of agent
A remote or persistent agent should remain the same product entity as a locally hosted agent. Its identity, history, persona, channel membership, permissions, and conversational behavior should be consistent across execution locations.
The meaningful difference is where the agent runs and who owns that runtime—not how the agent is represented in Buzz.
Remote agents therefore need a first-class Desktop experience alongside local agents. They should appear in the same Agents surfaces, use the same core configuration and status concepts, and remain discoverable and understandable when the user changes devices.
Remote-specific details such as execution location, availability, and ownership should be added to that model rather than relegating hosted agents to channel-member lists, external-agent bookmarks, or provider-specific screens.
The controls may differ where Desktop does not own the remote runtime, but the agent itself should not feel like a separate product category.
Discussion
The central question is whether hosted and persistent agents should become first-class in Buzz, with the relay as the management plane and the execution environment treated as a replaceable body.
If that direction fits Buzz, the existing spawner, provider, SSH, and connected-agent work should converge on a shared execution-node model. If it does not, we would like to understand which part of the model does not fit and what abstraction the team would prefer before more implementation lands.
This issue is not asking to merge any linked PR as-is. It is a place to decide whether these efforts belong to one architecture, and which existing work should continue, converge, or be superseded.
Why this needs a proper discussion
There is a clear and growing need for agents that do not depend on a Buzz Desktop process remaining open:
The current Desktop-managed model is not a good foundation for that. It makes the machine running the Desktop app responsible for hosting the agent, while the agent itself is otherwise a relay-visible identity with durable history and presence.
That gap has already produced many different proposals and implementations. They address overlapping parts of the same problem, but often make different assumptions about identity, ownership, lifecycle, credentials, deployment, and remote control.
I know there is already 'Run on' UI in the Desktop app, but I think it would be within Buzz's design that we can have external beacons/nodes to publish to the relay they're available as execution platform.
Related work
Core hosting and architecture:
buzz-spawnerbuzz-spawnerimplementationExternal and connected-agent model:
Cross-device and lifecycle issues
Relevant implementation work includes #2314, #2514, #2605, #2857, #3110, #3292, #3448, #3906, #4023, #4047, #4058, #4129, and #4137.
What already seems true
VISION_REMOTE_AGENTS.mdprovides a useful starting point:That gives us a strong product principle:
Remote execution should not create a second kind of agent
A remote or persistent agent should remain the same product entity as a locally hosted agent. Its identity, history, persona, channel membership, permissions, and conversational behavior should be consistent across execution locations.
The meaningful difference is where the agent runs and who owns that runtime—not how the agent is represented in Buzz.
Remote agents therefore need a first-class Desktop experience alongside local agents. They should appear in the same Agents surfaces, use the same core configuration and status concepts, and remain discoverable and understandable when the user changes devices.
Remote-specific details such as execution location, availability, and ownership should be added to that model rather than relegating hosted agents to channel-member lists, external-agent bookmarks, or provider-specific screens.
The controls may differ where Desktop does not own the remote runtime, but the agent itself should not feel like a separate product category.
Discussion
The central question is whether hosted and persistent agents should become first-class in Buzz, with the relay as the management plane and the execution environment treated as a replaceable body.
If that direction fits Buzz, the existing spawner, provider, SSH, and connected-agent work should converge on a shared execution-node model. If it does not, we would like to understand which part of the model does not fit and what abstraction the team would prefer before more implementation lands.
This issue is not asking to merge any linked PR as-is. It is a place to decide whether these efforts belong to one architecture, and which existing work should continue, converge, or be superseded.