Last week Block open-sourced Buzz — a workspace where AI agents sit in channels next to humans, with git, workflows, and voice on one relay. It's Apache-2.0, the team moves fast, and their VISION.md is unusually honest. The line that stopped me is in the status table: workflow approval gates are partially built, and "a run that hits a request_approval step is currently marked Failed" — they even gave the gap a name, WF-08.
I've spent months building approval gates for coding agents, so watching a well-resourced team ship the same category for free clarified something I should have seen earlier:
The gate is becoming a commodity. The handoff is not.
The 2am problem
Picture an agent halfway through a long run when the operator's laptop lid closes. Not a hypothetical — if you run coding agents unattended, this is Tuesday.
The obvious answer is "a cloud runner picks it up." But that sentence hides the actual engineering problem: how do you guarantee exactly one machine owns that work?
Because the failure mode isn't the run stalling. A stalled run is annoying but recoverable — you resume it, you lose some time. The failure mode is two executors both believing they own the thread: interleaved writes, diverging state, a git history with two authors who each think they're the only one. A stalled run costs you minutes. A split-brain run can cost you the working tree.
Two executors on one thread is worse than zero.
This is a lease problem, not a UI problem
Distributed systems solved this shape of problem a long time ago, and the answer wasn't smarter dashboards. It was leases and fencing:
- A lease, not a lock. Ownership expires unless renewed. The holder machine proves liveness by renewal; a crashed or offline holder loses ownership by default, without anyone needing to detect the crash.
- Short expiry. The lease term bounds your worst-case handoff latency. A 90-second lease means at most 90 seconds of ambiguity about who owns the thread.
- Fencing. The next holder takes over in a way that the old holder's late-arriving writes can't corrupt — the previous lease is dead, and work signed under it doesn't land.
None of this is exotic. What's new is applying it to agent runs, where the "resource" is a half-finished piece of work and the "nodes" are your laptop and a VPS.
What surprised me building this: the handoff itself is better modeled as a queued prompt handoff, not process migration. You don't teleport a running process; you hand the next eligible unit of work to whoever holds the lease. That distinction is what makes fencing tractable.
What Buzz's roadmap says, and doesn't
Buzz will finish WF-08 — the schema, endpoints, and UI already exist; the executor just doesn't persist and resume the approval yet. Mobile is in active development, push notifications are planned. All three, free and open source. If your mental model of an "agent safety product" is an approval prompt, that model now has a well-funded expiration date.
What I can't find anywhere in their vision document is the continuity half: what happens to a run in flight when the machine driving it goes away. No lease, no failover, no offline policy. I don't say that as a gotcha — their relay-centric model has different priorities, and WF-08 shows they take execution semantics seriously. I say it because it locates the actual open problem, the one nobody gives away free yet.
What I'm testing, honestly labeled
ThumbGate is my attempt at the lease half. The free browser dashboard pairs to the machine over outbound HTTPS — no inbound ports — and while your machine is online, it holds a 90-second lease and the work stays local. There's an optional paid Continuity add-on that can pick up eligible work on a fenced VPS when your machine drops, under an offline policy you set: auto, or ask-first.
The caveat, before you find it yourself: the live page says continuity is "still proving this out," and that's accurate. It works in my testing. It has not met the real world's full mess, and I'm not going to dress it up as if it has.
The open question I'd like help with, from anyone who runs agents overnight: how do you handle the handoff today? Cron-restart and hope? Accept the stall? Something smarter? I don't think anyone has fully solved this, and I'd rather compare notes than pitch.
Also available: the free dashboard is at thumbgate.app — runs in the browser, nothing to install. Buzz is at github.com/block/buzz; their VISION.md is worth your time.
Top comments (1)
The distinction between a stalled run and a split-brain run is the core insight: losing a few minutes is recoverable, while two executors writing to the same thread can corrupt both state and git history. The 90-second lease and fencing model make the handoff concrete, especially because a queued prompt is more realistic than pretending a live process can migrate cleanly between a laptop and VPS. The next engineering boundary is defining which work is safe to resume automatically; lease ownership can prevent conflicting writes, but only an explicit checkpoint and idempotency policy can make failover trustworthy.