ship‑while‑you‑sleep

agents on shift

Field notes  /  Agent tooling  /  Post #002

Every thread gets its own computer.

A couple of hours getting Amp’s self-hosted orbs to run on my Mac Studio, an agent that was confidently wrong twice, and why “fire it and walk away” feels so different from how I usually work.

By 9 min read

Every agent task I start now gets its own computer. A fresh, sandboxed Linux container boots on my Mac Studio, clones the repository, does the work and goes to sleep again when it’s done. My main machine never sees a half-finished checkout, a stray node_modules or a branch it shouldn’t have. That changes how it feels to hand work to an agent.

Getting there took a couple of hours of actual work, a wrong turn through Apple’s container tooling and a very instructive stretch of watching an agent be wrong. This is the story, and what it says about two ways of working with coding agents.

Why bother hosting orbs at home

The Mac Studio was already sitting and mostly idling on my desk, while most of my work happens on a Mac mini next to it. With a self-hosted provider, the repository checkout and build output live on my hardware instead of in a cloud sandbox. (What the agent reads and the commands it runs still flow back to Amp, as the docs spell out.) The docs also list self-hosted orbs as free for individuals and teams, so the experiment cost me nothing but time.

The docs list several recipes: Docker, Kubernetes, E2B, Modal and more. For a single Mac, the example is Apple’s own container tool, which runs every Linux container in its own lightweight virtual machine, with no Docker Desktop or Colima in between. That’s what I picked.

Host
Mac StudioApple silicon · macOS 26+
Runtime
Apple containerone lightweight VM per orb
Image
Amp’s default orblinux/amd64 via Rosetta
Per orb
4 CPUs · 8 GBnamed after its thread
Provider
amp orb provideroutbound HTTPS only
Snapshots
switched offevery new thread runs setup

The agent that couldn’t touch my Mac

Here’s the part that made me grin. I didn’t set this up alone: I asked an Amp agent to help. But that agent lives in an orb in Amp’s cloud (you get $10 for free after the free signup to spend on their hosted orbs), and it has no way to reach my Mac. It couldn’t run a single command on the machine it was designing for. It could read the docs, write files and test them against a stub of the container command, and that was it. I was the hands.

So the loop was: the agent writes a dispatch.sh and a setup.sh, I download them and run them on the Mac, I paste back what the terminal said, and the agent reads my logs and tries again. A cloud agent configuring a home server by remote control through a human. It worked better than it sounds, mostly because the agent wrote its dispatch script to be chatty: every step logs what it’s doing, which is the only reason any of the following was diagnosable.

The skeleton is small. On spawn, the script starts a container named after the thread and then runs amp orb bootstrap inside it, which dials home to Amp:

# spawn, heavily abridged
$ container run --detach --init --rosetta --platform linux/amd64 \
    --cpus 4 --memory 8G --name "$ORB_ID" "$ORB_IMAGE" sleep infinity
$ container exec --detach --env ORB_TOKEN="$ORB_TOKEN" "$ORB_ID" amp orb bootstrap

# and the provider itself, run in a terminal on the Mac
$ amp orb provider ./dispatch.sh --token=aop_live_…

A couple of hours, six surprises

The thread behind this post spans two days, but only because I kept doing other things in between. The actual work was a couple of hours.

~/orbs — what actually happened
  1. 01cliamp not on PATH · the Mac app doesn’t install it
  2. 02designApple container + Rosetta + a dispatch script
  3. 03orb #1first thread boots on the Mac
  4. 04orb #2no bootstrap connection within 120s
  5. 05snapshotcontainer commit breaks the start command
  6. 06zombiea dead container that never revives
  7. 07cwdediting a copy of dispatch.sh nobody runs
  8. 08orb #3spawns cleanly · healed itself

1. The CLI wasn’t there. The native Amp app doesn’t put amp on your PATH, and a self-hosted provider is a CLI job. A one-line install script fixed it. It also taught me that a runner (the Mac as a place to run threads) and an orb provider (the Mac as a factory for sandboxes) are different things, and the app only has UI for the first.

2. The first orb just worked. That was suspicious. A thread started, a container appeared, the agent cloned the repo and got going. I reported back, victorious. Then a second thread failed with this:

“spawn hook ran … but this thread accepted no amp orb bootstrap connection within 120s.”

— Amp, after a very long two minutes

That’s all Amp can tell you when an orb dies on arrival: it waited and nobody called. Everything useful is in your own provider log.

3. Snapshots, the first suspect. Amp saves a prepared copy of a project’s orb so that later threads skip setup, and the docs say Apple containers can do this with container commit. The agent found an open bug in Apple’s tool: a committed image remembers the first word of its start command as an entrypoint, so the documented sleep infinity turns into sleep sleep infinity. The container dies instantly, which is exactly the symptom I had. The agent’s first fix was a workaround. Then I ran it, pasted the error, and the workaround was wrong. The agent said so, and gave up on snapshots entirely: spawn now ignores them and always boots the base image.

4. The zombie. Then a project thread failed again while a no-project thread worked fine. The difference: my earlier failed attempt had left a container behind, and container start kept re-running the same broken command on it. A fresh name booted cleanly. So spawn learned to check that a resumed container actually stays up for about ten seconds, and to delete and recreate it from the base image if it doesn’t.

5. The wrong file. My console then printed a message from a snapshot code path that the final script cannot reach. The agent’s diagnosis: my provider was running an old copy of dispatch.sh. The provider resolves ./dispatch.sh against its own working directory, and I’d been replacing a different file in a different folder. Nothing humbles you like fixing the right bug in the wrong copy of the file.

6. It healed itself. A few seconds after I asked about the stuck orb, it came back. My console showed the new script finally doing its job:

~/orbs — amp orb provider ./dispatch.sh
  1. spawndispatchignoring snapshot snap-febd804b-…; booting …/amp-orb:latest
  2. spawndispatchcreated container from …/amp-orb:latest
  3. spawndispatchstarted amp orb bootstrap

The agent was wrong twice along the way: once claiming a bug in the docs that wasn’t there, and once with the entrypoint workaround. Both times it checked the evidence, retracted and moved on. Somewhat reassuring, in a thread where nearly everything was inferred from a screenshot of my terminal.

Where it landed

It works. A new thread spawns a container on the Mac Studio, boots from the base image, runs the repo’s setup, and later pauses. It’s not as fast as an Amp-hosted orb, and it’s a little clunkier: I run the provider by hand in a terminal. The setup script can install it as a launchd agent that starts on its own, which is the obvious next step. Day to day, though, it is what I was hoping for.

The part I like most is that each thread simply has its own checkout, so I no longer juggle git worktrees or multiple copies of a repository. And the Mac stays far cleaner than it ever did with agents working directly in my home directory.

The closest I’ve got to the Grok Bot workflow

People on X have been describing the Grok Bot workflow as transformative. I couldn’t really judge that from the outside. Self-hosted orbs are the closest and easiest way I’ve found to reproduce that workflow locally, and with them I can see what those users meant. You hand a task to an agent, it goes off into its own machine, and you stop supervising a session and start delegating work.

You stop supervising a session and start delegating work.

Why Amp left an impression

I should be upfront about how I use it: not on Amp’s own subscription, but with OpenCode Go as the model side. Even so, the product is polished: it’s the same experience across web, desktop and mobile. Other harnesses that let you choose your own model providers usually nail one of those three at best. Amp checks all of them.

I’ve followed one of the founders, Thorsten Ball, on X for a while, so I came in curious. Trying the product left a stronger impression than I expected. These people have great taste and are clearly living a couple of months in the future.

Fire and wait, or babysit?

The agent is also thorough in a way I’m not used to. It creates tests and verifications on its own, even for work that is mostly shell scripts. In the setup story above, it checked its scripts with ShellCheck and a stubbed container command before I ever saw them.

The downside: it’s slow. I recently did a comparable task with OpenCode, and Amp took much longer. To be fair, it wasn’t the same job: Amp’s version ran isolated in an orb, and it came with tests and verification I hadn’t asked for. Still, the wall-clock difference is real.

My guess is that the gap comes from a different philosophy. My usual quick-edit OpenCode workflow is about babysitting the model: reading the thinking traces, noticing when it drifts, steering by hand. That’s fast because I’m in the loop, and it costs my attention the whole time. Amp is closer to fire it, let it run, and be quite confident it comes back with something good. It spends its extra minutes on the checks I would have done myself, or skipped.

Babysitting buys speed. Fire-and-forget buys confidence.

If I want to see every token go by and steer on instinct, the babysitting setup stays my choice. If I want to drop a task before dinner and read the result afterwards, I now know where to put it. That’s the entire premise of this blog, after all.

If you want to try it

  • You need Apple silicon, macOS 26 or later, Apple’s container tool (start it once with container system start) and Rosetta, because Amp’s default orb image is linux/amd64.
  • Install the Amp CLI. The app alone doesn’t provide it.
  • Register a provider under workspace Settings → Orbs and keep the aop_live_… token it shows you once.
  • Write your dispatch script against the dispatch contract, and make every step log loudly. Then check which copy the provider actually runs.
  • If you hit the 120-second bootstrap timeout, read your provider log, not the thread.

Amp’s docs also point out that Apple silicon hosts can use an ARM64 orb image instead of the amd64 one. I haven’t tried it yet; it’s on my list.

Thanks to the agent that wrote my dispatch script through my copy-paste hands, and to Thorsten Ball and the Amp team for building something worth writing about.
Docs: ampcode.com/docs/orbs/self-hosted · Apple’s tool: github.com/apple/container