A Week of Loops: From Prompting an AI to Managing a Small Team of Them

For a while now I've used herdr to keep track of my many Claude Code sessions. Most of them are ordinary: I open one, work through a task, and close it.

But more and more of them stopped ending. I'd start a session, give it a job and run /loop, so it repeated the job every hour: check on this, report on that, tell me if something changes.

Those sessions came with a routine of their own. On Friday I paused each one by hand so it wouldn't run all weekend, and on Monday I resumed them one by one. Every new one also made herdr more crowded. The sessions I was actively working in got mixed in with a growing pile of hourly jobs that mostly just needed to keep running.

Moving the long-running ones out to a place of their own seemed like the natural next step. So on Monday I started building automator, a background service that runs Claude Code on a schedule. A loop is a standing job (a prompt, a schedule and a set of rules) that runs over and over without me in the room. A schedule like "hourly on weekdays" replaces my Friday and Monday routine.

By Friday automator had 29 commits and I had written 22 loops. This post covers what I built, what kinds of work the loops did, what they cost, and the question I care about most: does this change how I work with AI?

Short answer: yes. I went from working with an AI to managing a small team of them.

What I built

automator grew in roughly this order. Each step came from a problem the previous step exposed.

1. The core. Schedules, and one long-lived Claude Code session per loop, so a loop remembers what it did last time, just like my /loop sessions did. Long sessions get kept small enough to resume. Everything runs on my Claude subscription rather than API credits.
2. Watching runs. A transcript for every run, links to the artifacts and pull requests each run made, a conversation view, and a way to continue or fork a loop's session in my own terminal when I want to take over.
3. Reaching me. Questions I can answer in place, a Needs you list, Slack DMs, email and a daily digest.
4. Reacting. Runs started by Slack mentions, DMs and channel posts, not just by the clock.
5. Giving each loop a home. Every loop gets its own HTML page with action buttons, shareable behind sign-in.
6. Governing loops.
   • budgets and preflight checks;
   • allow and block lists for tools;
   • Claude helping me edit a loop's settings;
   • loops that oversee other loops and propose changes for me to apply;
   • backups and soft delete.

Notice how little of that list is about making Claude smarter. Most of it is about seeing what happened, getting my attention at the right moment, and limiting what a loop is allowed to do.

Here's what one loop looks like. Dependabot triage runs every Saturday morning across my GitHub org. It closes Dependabot PRs that are no longer needed, merges safe bumps, and asks me about the rest. This run found one patch bump that carried a security fix, checked that it qualified, merged it, and explained why:

What the 22 loops did

The loops fell into about five kinds of work.

Kind	What it looks like	What happened
Watching	A loop that checks on a long-running change every hour	The two watch loops ran 69 times between them, and caught real problems I'd have found much later on my own.
Reacting to events	A loop that answers when someone mentions it in Slack	55 runs. I turned off DMs as a trigger once automated notifications started burning runs.
Regular upkeep	Status reports, dependency updates, work logs, weekly summaries	Each replaced a manual chore or an older scheduled job, which I then deleted.
Improving systems	Loops that look for something to make better, and loop-doctor	They opened 9 PRs. loop-doctor found a cost bug in automator itself and sent the fix I merged as PR #1.
Working with people	Loops that help me with my colleagues	Created in the last two days; none has run yet.

My favourite line in that table is loop-doctor's. It's a loop whose job is to review other loops, and the first bug it found was in the tool running it. The very first merged PR on automator was written by one of its own loops.

What it cost

About 170 runs, with a recorded API value of $959.

That number needs three caveats:

• It's too high. Until Thursday's fix (the loop-doctor PR above), many runs were recorded at their session's running total instead of their own cost. loop-doctor estimated the overcount at about 6x for the loops it checked.
• It's API value, not money billed. The loops run on my subscription.
• It's concentrated. Three loops account for 84% of it: the two hourly watches and the Slack loop.

The lesson from the third point is simple. Reading a big context every run, every hour, is what costs. A loop that wakes up hourly and rereads the world is expensive even when nothing changed.

Does it change how I interact with AI?

Based on what I actually did this week, yes, in four ways.

1. I stopped prompting and started writing job descriptions

A loop prompt isn't a question. It's a standing job description: the scope, what counts as evidence, what never to do, and when to tell me. My best ones read more like onboarding notes for a new teammate than like a chat message.

That moved my work to the edges. I spend time before, writing the job, and after, reviewing results. Much less of it happens in the middle, at the keyboard, watching tokens stream.

2. The AI comes to me now

Even my /loop sessions used to wait in a terminal tab until I went and looked. Now loops show up on their own, in Needs you, Slack DMs and the digest, and then they wait for me.

Several of the changes I asked for this week were about exactly that moment of being interrupted:

• seeing the question together with its context;
• titles I can click straight through;
• keeping my scroll position;
• making a run read like a conversation.

My attention became the scarce resource. A lot of the week went into making checking in cheap, and much less into making Claude smarter.

3. Trust is something I build into the setup, not a feeling

I moved from asking "will it do the right thing?" to deciding what it's allowed to do:

• read-only settings for the Slack loop;
• blocked tools;
• merges only after my approval;
• soft delete;
• proposals that I have to apply;
• treating Slack messages and PR text as data, not instructions.

It's also telling where Claude Code's own safety checks stopped an agent this week: merging without review, deleting infrastructure, a loop changing its own tool permissions. Those are the decisions I still keep for myself, and I made each of those calls by hand. That split feels right.

4. It improves itself, and it's starting to point at people

loop-doctor reviews other loops, and every run can suggest changes to its own skill, so the system gets better between my sessions, not only during them.

And the last three loops I wrote aren't about code at all. They use AI to help me be a better colleague: noticing who to thank, understanding a teammate's PR before I review it, and announcing merges in my voice. That's a different relationship from "write my code".

What I'm watching

This isn't all upside. Four things could quietly go wrong.

• Needs you could become another inbox. If I start clearing it without reading, my oversight is in name only.
• The cost of always-on context. The hourly watches cost the most. I need to weigh them against the real problems they catch, not keep them because they feel safe.
• Text written by other people. Slack-triggered loops read messages that anyone can write. For those loops, the blocked tools matter more than the prompt does.
• Drift. When a loop works well unattended, I stop reading it. Running loop-doctor every week is my check against that.

Where this leaves me

A week ago, my loops were terminal tabs in a crowded herdr that I paused every Friday. Now they're a set of jobs that run while I'm doing something else, come to me when they need a decision, and get reviewed by another job when I'm not looking. herdr is back to holding the sessions I'm actually working in.

That's less like using a tool and more like managing a small team, and it turns out automator is mostly the tooling for managing them well: job descriptions, an inbox, permissions, budgets and a weekly review. The model was already capable. What was missing was everything around it.

---

If you enjoyed it, you can buy me a coffee ☕.