How I Automate My Own Work With Agent Loops

Why I automate with loops

Most of my work is judgement: architecture decisions, tradeoffs, knowing which problem is actually worth solving this week. But a surprising amount of it is not. It is the same coordination, the same checks, the same small reports, repeated on a schedule. That work does not need me. It needs a reliable loop that never forgets a step and never gets bored on the fourth repetition.

A loop, in the sense I mean here, is an agent running the same task over and over: on a timer, on its own judgement of pace, or on a fixed schedule in the cloud. I lean on three of them every day. The rest of this article is how I set them up and, just as important, where I stop them.

The three loops I actually use

The first is a fixed-interval loop: a task that runs every N minutes inside a live session. The second is a self-paced loop: the same idea, but the model decides how long to wait before the next run based on what it is waiting for. The third is a scheduled cloud agent: a bounded task that runs unattended on a cron schedule, with no terminal open at all.

Each one trades immediacy for autonomy. A fixed-interval loop is right there in front of me and easy to interrupt. A scheduled agent runs while I sleep but has to be trusted to finish on its own. Picking the right one is mostly about how closely I need to watch the work while it happens.

Running a loop in a live session

The simplest loops live in a session I have open. When I need to watch something that changes on its own, a deploy finishing, a CI run going green, a queue draining, I put it on a fixed interval. In Claude Code the command is /loop with an interval and a slash command or prompt:

/loop 5m /babysit-prs

That runs the task every five minutes until I stop it. The one rule that matters here is to match the interval to how fast the state actually changes. Polling a deploy every thirty seconds when it takes eight minutes just burns work for no new information. If the thing I am watching updates every few minutes, I check every few minutes, not every few seconds.

Sometimes I do not know the right interval in advance, or it changes as the task progresses. For that I drop the interval entirely and let the model pace itself, scheduling its own next wake-up based on what it is waiting for:

/loop monitor the staging deploy and tell me the moment it finishes

The useful instinct here is to think in cache windows, not round numbers. A wait under five minutes keeps the working context warm, so it is cheap to check back often while something is actively moving. A longer wait pays to reload context, so it is worth it only when there is genuinely nothing to do until then. The mistake is the middle: waiting exactly five minutes pays the reload cost without buying much idle time. So I either check back quickly or commit to a real pause, and let the loop decide which.

Scheduling agents in the cloud

The loops above live in a session I have open. The work that runs while I am asleep is different: it goes to a scheduled cloud agent, a routine on a cron schedule that runs unattended. A morning pull-request triage, an overnight summary of new errors, a weekly dependency check. I do not have to be there, and there is no terminal to keep open.

A scheduled agent only works if the task is crisp and bounded, and if it has a clear place to put its output. Vague instructions plus no audience produces work nobody reads. So each routine answers two questions before I schedule it: what exactly is done when this finishes, and where does the result land, a Slack message, a draft email, a file I will see in the morning. If I cannot answer both, it is not ready to be a loop yet.

The principles that keep a loop safe

Automation that runs without me watching is only as good as the guardrails around it. Five rules carry almost all the weight.

Idempotent: every run must be safe to repeat. I design the task so a double-run does not double-charge, double-post, or double-anything. The loop should be able to run twice by accident and leave the world in the same state.

Bounded: every loop needs a stopping condition or a sane fallback, or it spins forever. A loop that waits on an event also gets a maximum it will wait, so a stuck dependency does not turn into an infinite poll.

Escalate exceptions: the loop handles the routine and pings a human for the genuinely unusual. This is the same pattern my Plain Freight agents use to run shipments, the machine owns the ninety percent that is predictable, and a person gets the ten percent that is not.

Observable: a loop you cannot see is a loop you cannot trust. Each run leaves a trace, a message, a log line, a status, so I can reconstruct what it did without rerunning it.

Manual first: I run a task by hand until I understand its edge cases, then I wrap it in a loop. Automating a process I do not yet understand just automates the mistakes faster.

Where the loop ends and I begin

The line I draw is simple. Loops own the repeatable, I own the judgement. A loop can chase a deploy, summarise overnight errors, and nudge a stuck pull request without me. It cannot decide whether a tradeoff is worth making, whether a risk is acceptable, or which of three problems deserves my week. That is taste, and taste does not loop.

Done well, this is leverage, not laziness. Every repetitive step I hand to a reliable loop is an hour I get back for the work that actually needs a human. The goal was never to remove myself from the work. It was to remove myself from the parts of it that never needed me in the first place.