The two loops of building with AI agents

Last Tuesday I sat down with coffee around 6am and half my day was already done. Not by me. While I slept, an agent had posted the morning news to mycaminoguide.com, flagged two flaky Playwright tests on getbitwit.com, moved a subscription charge onto the right budget line, and left me three lines in Slack with one question that actually needed a human. I answered it in twenty seconds and started building.

That was the moment it clicked. I don't work in one flow anymore. I work in two. And the second one only exists because agents finally learned to drive a computer the way I do.

There's the real-time loop, where I'm hands-on building something. And there's a background loop that runs whether I'm at the keyboard or asleep. For about fifteen years "doing development" meant only the first one. Now the second one does as much work as I do. I call it double-loop development.

Loop one: the real-time build

This is the loop you already know. I open the editor, describe the feature, and Claude and I go back and forth until it works. Same as the last couple of years, except the back-and-forth is shorter now and I spend more time deciding what to build than typing it. That loop is mature. The one that changed my life this year is the other one.

Loop two started with machine control

For years agents were stuck in a chat window. They could write code, but they couldn't run anything. The thing that broke that open was OpenClaw, which gave an agent real control of the machine: the shell, the browser, the file system, across devices. That sounds small until you watch it happen. An agent that can open a browser, log into Stripe, and reconcile a charge is doing the actual job, not writing me instructions to do it later.

That's what made a background loop possible in the first place. OpenClaw turned "a few cron scripts" into something that can sit at the keyboard and operate. It's the foundation everything else here is built on, and it deserves the credit for the shift.

The catch: machine control lives on your machine

I hit the limit fast. Control of the computer runs on the computer. If my laptop sleeps, the loop sleeps. Close the lid on a flight and the Camino news doesn't post that morning. Powerful, but chained to one box that has to stay awake and online. A background loop that only runs when your machine is on isn't really a background loop.

Claude Tag, Dreams, and /goal push the loop to the cloud

This is where the loop leaves my desk. Three pieces extend that same autonomous control past my local server and into the cloud.

To be fair, I could already run agents in the cloud. Claude Managed Agents, GitHub Actions, a cron job on a server somewhere. But those always felt like part of my coding workflow: CI runs, build steps, things wired into a repo. Useful, just not something I'd hand to a chief-of-staff. Unless you're a one-person developer shop like me, in which case the chief-of-staff and the developer are the same tired person.

Anthropic just launched Claude Tag, and it runs in Slack, on a schedule, with no machine of mine involved. You give it a standing instruction, like a nightly check or a weekly digest, and it runs whether my laptop is open or shut. It watches channels, surfaces the thread that needs a human, and reaches into tools like Linear, GitHub, and Datadog to actually do the work. Tag is the part that took the loop off my laptop and put it somewhere that never sleeps. It's in beta for Enterprise and Team plans today, so this isn't a someday thing, it's running my mornings now.

/goal is what makes unattended work safe. You give the agent a finish line, "every call site compiles and the tests exit zero, and don't touch any other test file," and a separate fast model checks after each turn whether it's there. If not, the agent keeps going on its own. A clear finish line is exactly what you want when nobody is watching the screen. One caveat I got wrong at first: the evaluator only judges what the agent has surfaced in the conversation, so write the condition as something its own output can prove ("npm test exits 0"), not a vague "make it good."

Dreams keeps the loop from rotting. An agent that runs every day piles up duplicate and stale memory, things that were true in March and aren't now. A dream reads the old memory plus past sessions and writes a clean, deduplicated version. So the cloud loop gets sharper over time instead of drifting.

Put it together and the picture is simple. OpenClaw proved an agent could run the machine. Tag, /goal, and Dreams moved that control into the cloud, where it runs without my hardware in the loop at all.

The whole industry is moving here

I'm not the only one betting on background machine control as the next mode of work. OpenAI just shipped Computer Use in Codex, where you mention @Computer or an app name and the agent sees the screen, clicks, types, and operates desktop apps, running in the background on macOS while you keep working elsewhere. It took clear inspiration from what OpenClaw has been doing: drive the GUI like a person instead of staying boxed into the terminal. When two of the biggest labs are both building agents that quietly operate a computer in the background, that's not a side feature. That's the direction.

This is the new normal

I genuinely don't think double-loop development is a niche power-user setup anymore. If you build anything, an app, a newsletter, a small business, you have a loop-one self that makes things and a loop-two pile of work that keeps the lights on. Until now the second pile was all you. Now it doesn't have to be.

I'm not fully settled on it. Handing the boring-but-important work to something that runs while I sleep still makes me check its output more than I probably need to. But I'm not going back to doing it all myself, and I don't think you will either once you've felt a morning where half the work is already done.

If you want to try it, start with one job in loop two. Pick the most boring reliable task you do every week, the reconciliation or the QA run, and give it a standing instruction. That one's enough to make the split real.