My agents die when I close my laptop
The pitch for coding agents is that they're tireless. They don't sleep, they don't get bored, they'll grind through your backlog at 3am while you dream about equity. It's a great pitch. There's just one small detail nobody puts on the landing page: the tireless worker is a child process of a desktop app on your laptop. Close the lid and your workforce ceases to exist.
I wrote last time about how these tools can't see a product that spans two repos. This one is about the other assumption baked into the whole category: that the agent lives where you live, on your machine, inside your session, tied to your lid being open. It's the same mistake in a different costume. The tool confused its own convenience for your reality.
The workforce that keeps banker's hours
Think about what we're actually being sold versus what we're getting. The promise is delegation. Give the agent a task, walk away, come back to finished work. But every orchestrator I've used runs the agent as a process inside the app. The app runs on your laptop. So the real contract is: give the agent a task, and then keep your laptop open, plugged in, and awake, like you're incubating an egg.
Kick off a chunky refactor in the evening and you have two options. Leave the laptop open all night like a maniac, or close it and accept that the work stops when you stop. A workforce that only works while you're watching isn't a workforce. It's a very expensive pet.
The fix is older than I am
Here's what makes this genuinely funny to me. The solution to "I need a process to keep running when I disconnect" is one of the most solved problems in the history of computing. You run it on a machine that stays on, and you connect to it over SSH. Put it in tmux and you can detach, reconnect from any device, and pick up exactly where you left off. People have been running week-long jobs this way since before I was born. It's boring. It's bulletproof. Every server on earth speaks it.
And it already works today, with zero orchestrators involved. SSH into a cheap cloud box, open tmux, run your CLI agent in a pane, detach, go to sleep. The agent works all night. In the morning you attach from your phone if you want. My dumb terminal setup can do the thing the polished desktop apps can't. That should embarrass someone.
What the orchestrators offer instead
The tools in this category are starting to notice the problem, and the remote stories they're shipping all seem to have the same shape: install our host service on the target machine, and connect through our app, sometimes through our relay in the middle. In other words, the answer to "can I run this on my server" is "yes, once your server runs our software."
I get why they build it that way. A host service they control gives them a consistent surface on every machine, and a relay makes networking simple for people who've never touched an SSH config. For a lot of users that's honestly fine. But notice what it costs. SSH is a universal substrate. Every machine I can reach, I can already reach, with keys and jump hosts and config that my infrastructure already trusts. A vendor's host service is a product-controlled substrate. Now there's a daemon to install on every box, a version to keep in sync, and if traffic routes through a relay, a third party in the middle of the connection. Try explaining that last one to any company with a real security team and watch the meeting end early.
The tell is what happens with machines the vendor didn't imagine. A random EC2 box. A bare metal server. A GPU machine in a lab. A box inside a customer's VPC. With SSH, all of these are just hosts in a config file. With daemon-first remoting, each one is a small installation project, assuming it's possible at all. The tool that should be making my machines more useful instead has opinions about which of my machines count.
And the machine that stays home is drowning anyway
There's a second reason agents shouldn't live on the laptop, and you can hear it. These orchestrators are heavy. Most of them are Electron apps carrying a full browser runtime, plus a terminal emulator per session, plus the git plumbing, plus whatever state sync keeps the UI live. Run a handful of agents and my fans announce it to the room. The agents themselves also compile things, run test suites, and hammer the disk, all while I'm trying to use the same machine to think.
So the current architecture manages a genuinely impressive double fault. The agents are fragile because they live on a laptop that sleeps, and the laptop is miserable because it hosts agents that never should have lived there. Both problems have the same fix. The laptop should be a window. The work should live somewhere built for work.
What persistence actually unlocks
It's tempting to file this under quality-of-life, but I think persistence changes what the tools are for. Session-scoped agents can only take tasks sized to your attention span. You give them twenty-minute jobs because you're going to sit there while they run. The moment agents survive your absence, the task size changes shape. Run the whole test suite against three different approaches and show me the comparison in the morning. Chew through this migration overnight and flag the files you weren't sure about. Watch CI and fix the flaky test when it reproduces.
The real product of a persistent agent isn't code, it's a decision waiting for you. You wake up, and instead of status bars, there's a short stack of judgment calls: approve this, pick between these two, look at this weird thing I found. That's actual delegation. What we have today is babysitting with extra steps.
The version I want
None of this requires inventing anything. It requires respecting infrastructure that already exists. Point the tool at my SSH config and treat every host in it as a place agents can live. Bootstrap over the connection itself, a thin worker or nothing at all, no permanent daemon required unless I opt into fancier features. Local execution stays available for quick stuff, and it should feel identical, because local is just one more host. My laptop becomes what it always should have been in this story: a screen with opinions.
Layer the managed, relay-style experience on top for people who want the easy path, sure. But the floor should be: any machine I can SSH into is a first-class home for my agents, today, with the keys I already have.
The bar to clear
Here's the test I'd hold any tool in this category to. It's the same test from my last piece, just aimed at a different layer: would we accept this for a human? If I hired an engineer and they told me "I stop working the moment you personally go to sleep, and I can only work inside machines running my proprietary agent daemon," that's not an engineer, that's a haunted printer. We'd never accept it. We accept it from agent tools because the category is young and the demos are shiny.
The lid of my laptop should not be the power switch for my team. That sentence is so obviously true that the only interesting question is why no tool has made it true yet. And once your agents do run all night on machines you barely think about, you slam straight into the next wall, which is that they produce more work than you can possibly review. That one's next: nobody can review a hundred agents.