Running agents on the go
Here's the problem I actually had this month.
One of the products I'm building is a field-service app — inspections, quotes, the whole job flow for a gasket business (chicagogasketservice.com). And the thing about a field-service app is you can only really test it in the field. So I've been out there: walking jobs, marking up units on the phone, watching the app behave on a real device in a real shop instead of in a simulator on my desk.
Which is exactly what the product needs. It's also been quietly killing my development time.
Because every time the field surfaced something to fix — a layout that broke on the real screen, a number that came out wrong, a flow that felt clumsy in the hand — I couldn't do anything about it until I was back at the laptop. The actual building required the machine. So the loop was: spot the problem in the field, sit on it for hours, drive home, finally open the laptop, half-remember the context, fix it. My velocity dropped and it wasn't because I was working less. It was because the work was stranded on a desk I kept walking away from.
The objective became simple: keep building while I'm away from the computer.
Not a lighter version of the work on a phone. The real work — the same agent, the same codebase, the same context — just reachable from my pocket.
Turns out that's four tools and one skill. Most of the afternoon I spent setting it up was me tripping over my own configuration, not the concept. Here's the whole thing, including the parts that bit me.
The mental model that makes it click
The phone never runs the work. The phone is just the window.
My compute stays on my hardware. The coding agent, the tools, the file system, the project context — all of it lives on the laptop at home. The phone opens a terminal into that machine and watches it work. I close the app, drive to a job, the agent keeps running on the laptop. I open it again from the shop floor and I'm right back in the same session.
Once that clicks, the rest is just plumbing.
The stack
Tailscale — a private mesh network across every machine I own. Laptop, phone, all on one secure network, each reachable by name from anywhere. This is the foundation; nothing else works until it does. Devices talk directly and end-to-end encrypted — it doesn't care whether the phone is on cellular at a job site or on the same wifi as the laptop. It just connects.
SSH (Remote Login) — the laptop accepts an encrypted shell. One toggle in system settings. With the mesh network in front of it, that shell is only reachable from my own devices — never exposed to the public internet, so the attack surface is basically my own network.
tmux — persistent terminal sessions that survive disconnects. This is the one skill worth an afternoon. Without it, closing the phone kills whatever was running. With it, I start a named session once and the agent keeps going whether the phone is open, locked, or in my pocket on a drive between jobs. Detach, reattach later, everything exactly where I left it.
An SSH client on the phone — the actual window. Point it at the laptop's name, log in with a key, and I have a terminal. Then I type the same commands I'd type at the desk: start the session, launch the agent, describe the fix the field just showed me.
And the unexpected win: voice. The phone keyboard's dictation drops straight into the terminal, so I can talk the fix to the agent the moment I spot it — standing in the shop, not three hours later from memory. Terminal apps often block dictation; the stock keyboard committed text cleanly. That alone closes most of the gap between "noticed it in the field" and "it's being fixed."
The parts that actually slowed me down
The build-in-public bit, because the tutorial version where everything works first try is a lie.
The tool was already installed — twice. The mesh client was on my laptop from an app store install months ago. I tried to install it again from the command line, it failed trying to overwrite the working copy, and I spent a minute sure something was corrupted. It wasn't — it was two copies of the same thing fighting. Check what's already there before you install.
The two devices were on different accounts. Phone connected, laptop connected, still couldn't see each other — because I'd signed them into different identities. A mesh network only meshes devices on the same account. Re-logged the laptop onto the matching account and both machines snapped into the same network instantly.
The classic: wrong username. The last error — "connection could not be established" — sent me hunting through firewall and network settings. It was the username field in the SSH client. The most boring possible cause, after all the exotic ones.
None of these are hard. All of them are the kind of thing that turns a 20-minute setup into an afternoon, and nobody writes them down. So: written down.
Why it matters more than "cool, mobile"
The mobility is nice. It's not the point.
The point is the loop closed. The agent that knows my projects, my conventions, my whole system runs on hardware I control, with context that never leaves it — and now I can reach it the instant the field hands me a problem. No more stranding the fix until I'm back at the desk. I describe it from where I'm standing, the work starts on the laptop, and it's done or close by the time I'm home.
That's the difference between using an agentic workflow and owning one. The compute stays mine. The phone is just a thin pane of glass over it — and that pane turned out to be exactly what I needed to stop losing dev time to the road.
Four tools, one skill, one afternoon. If your building keeps pulling you away from the machine you build on, this is the fix.