Blog

Cloud agents that keep working when you close the laptop

Local agents are great until they are not. They eat RAM. They fight your editor for CPU. They stop when the lid closes.

Cloud agents flip that. You hand off a task, walk away, and come back to a diff, a test run, and a note about what still needs your call. I built Timekeep, a Philippine payroll app, 100% with agents. That does not mean 100% unattended. I still own the product decisions, payroll rules, and final review.

Before orbs: rent a VPS and live in SSH

The old way was simple on paper. Rent a server. Add an SSH key. Open a terminal. Hope typing does not feel like wet cement. Then install Node, Postgres, tools, clone the repo, copy env files, and remember which branch this box was for last week.

Once is fine. The fifth time is not. Two agents, two clean copies of the code, half-set-up boxes, and a list in your head of which IP has which unfinished work.

The lag is what drains you. Not only slow typing. Your editor is here. The tests and the agent are there. You paste errors one way and fixes the other. You copy files because you forgot which machine has the real version. The remote machine stops feeling useful. It just feels far away.

What Orbs change

Amp’s Agents in Orbs post names it cleanly: a remote machine where the agent keeps working without you watching. Not “SSH with a nicer skin.” Start an orb thread and Amp provisions the machine for it.

I still run agents locally. That is where I inspect a bug, try a fix, or shape a plan against the checkout already on my Mac. When the work no longer needs me, I ask the local agent to spin up an orb thread with what it knows and continue there.

Spin up an orb thread with what you know about this bug.
Ask it to fix it, then keep working here.

Amp’s agent-to-agent tools pass the context and relevant files to the orb while the local thread keeps going. That is the part I like. I do not have to choose local or cloud at the start. I can research locally, execute remotely, and pull the changes back with amp sync.

Make the repo ready

A bare clone is not a place to work. Amp runs setup files from the repo root. See their setup note and orbs manual. Timekeep’s shape:

Those file names are Amp-specific. The rule travels: setup should leave the agent able to install, migrate, seed, test, and open the app without asking you for a missing step. If setup is wrong, the agent burns tokens learning how to boot the app. If it is right, the first agent turn can stay on the real task.

The loop

  1. Pick a task with a clear end.
  2. Start an orb chat with the context it cannot fetch itself.
  3. Let setup finish. Review the diff. Open the app if UI changed.
  4. Sync or open a PR when the checks pass. Spend your review where being wrong costs the most.

Do not give an agent the final call on business rules, access control, or irreversible data changes. Tests can pass while the real-world rule is wrong. Do not send production secrets, fuzzy product calls, or work that still needs details you have not gathered. Wrong merges cost more than late ones.

I still use act and OrbStack for a full verification pass on my Mac before a push. Orbs for work without watching. GitHub Actions for the final remote gate.

Bottom line

You can still rent a server, SSH in, and fight the lag. Amp Orbs remove that dance. Put the real work in setup, resume, safe env defaults, and a way to open the app from the chat.

Once that is in the repo, closing the laptop is not the end of the workday. It is a handoff.

Appendix: other cloud agents

Amp is not the only way to run coding agents remotely. Alternatives include OpenAI Codex, Claude Code on the web, GitHub Copilot cloud agent, Cursor Cloud Agents, and Devin. I have not used all of them enough to rank them. Compare the loop: where a task starts, how the machine gets ready, how you steer it, and how the changes come home.