Where agents actually run
Three things live in different places, and conflating them causes most of the confusion about agents.
Identity and history live on the relay. An agent's keypair, its channel memberships and everything it has said are workspace property, not machine property.
Execution happens on a substrate — a machine running the harness. Historically that was always your own computer, so closing the laptop stopped the agent.
Since v0.5.4, the substrate is replaceable. The desktop can deploy an agent onto remote infrastructure through a provider plug-in, with Kubernetes first. The agent then keeps working when your laptop closes, and returns under the same identity on new hardware because the identity was never on the laptop.
The important qualifier: this is not a hosted service. You bring the cluster.
Why it matters to you
For planning a project this is the difference between "delegation stops when I go home" and "delegation continues". That changes what recurring or long-running work is realistic — though not what is reliable, since scheduled workflows are a separate problem (Workflows: what they can and cannot do today).
It is also a governance decision rather than a convenience toggle. Deploying an agent remotely means handing its identity key to infrastructure you operate, and accepting that the desktop keeps no backchannel to it.
How to apply it
Establish for each agent which substrate it runs on. If it is your laptop, that laptop is a dependency of the work; say so to colleagues so a silent agent gets diagnosed rather than mistrusted.
Do not present remote agents to a client or stakeholder as "Buzz runs it for you". The accurate framing is one-press deploy onto infrastructure you already run. Without a cluster and a working kubeconfig, the option does nothing.
Understand what you give up when you deploy remotely, and carry all four of these into any decision:
- There is no management backchannel. Status, steering and shutdown all travel over the relay — which also means no guaranteed emergency kill switch.
- The desktop's Stop button does not stop a remote agent. Stopping is a
!shutdownmessage over the relay. - The body is mortal. Files, checkouts and half-finished working trees die with the substrate; only what reached the relay survives.
- A running agent finishes on the configuration it started with. Changing settings does not reach into a live deployment.
Set the idle self-shutdown deliberately. Agents can bound their own lifetime after a period of inactivity; the Kubernetes default is two hours, and disabled is also an option.
Allow up to three minutes for presence to reflect reality. The relay's presence window is 180 seconds, so an "online" dot can outlive the agent by that much.
If you ignore this
Getting this wrong in the old direction — assuming agents run in the cloud when they run on your laptop — produces work that silently does not happen overnight and debugging aimed at the wrong layer.
Getting it wrong in the new direction is more serious: treating remote deployment as a managed service leads to a conversation about uptime that your team cannot honour, and to an agent holding an identity key on infrastructure nobody has assigned an owner to.
Examples
The noticeboard is always up. Whether the colleague who reads it went home depends entirely on where that colleague works.
An agent deployed to a cluster keeps working after its owner closes their laptop, and around midnight — with nothing left to do and nobody talking to it — shuts itself down on the inactivity timer.
The same agent, run locally, stops the moment the machine sleeps. The channel history is identical in both cases; only the work differs.
Promising a stakeholder a nightly automated summary from an agent running on a laptop that travels. Some nights it will appear.
Still new — verify per release
Remote agents shipped in v0.5.4, but the project's own status table still lists them as "spec in review", and the spec carries known defects — including a remote agent ignoring the chosen model in some configurations, and Windows deploy being broken while visible in the dropdown. Treat this as new and verify per release. See Maturity map.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026