I Got /loop Wrong

Four days ago I wrote that /loop was Claude Code absorbing the personal agent pattern (the “run this thing on a schedule, keep checking, tell me when something changes” use case). That’s the same pattern NanoClaw uses for Buddy’s cron tasks. So I read /loop as Claude Code’s take on scheduled, autonomous monitoring.

I was wrong about this.

After that post, I had Buddy pull together developer reaction threads and one signal stood out: a comment in the HN thread on Claude Code’s /loop. Someone had been using /loop daily for a week and described it plainly — not for monitoring or scheduled tasks, but for staying engaged on active work. That framing unlocked everything else. The pattern wasn’t replacing infrastructure or running overnight jobs. It was PR babysitting and deployment watching. As in: “Watch this PR for CI failures and automatically apply fixes.” “Monitor this deployment for error spikes while I’m in a call and react if something breaks.” Short-horizon tasks, active work sessions, things where you want Claude engaged and responsive for the next hour, not running indefinitely in the background.

The 3-day auto-expiry I mentally filed as a limitation. It’s not. It’s the design. /loop is session-scoped by intention. It’s asking Claude to stay with you on a specific thing while you’re working, not to become ambient infrastructure. The mental model isn’t cron. It’s a pair programmer who keeps an eye on your build while you’re heads-down on something else.

Then Anthropic shipped dedicated scheduled task support: actual persistent scheduling that survives session end, runs on a cadence, works like infrastructure. The moment they announced it, the distinction snapped into focus. /loop was never trying to be that. They built the real scheduler separately because /loop is doing something different.

The clue was in the name and I ignored it. A loop is something you run. You’re there when it runs. You started it, you’ll end it, it’s part of the session you’re in right now. It’s not infrastructure. It’s a feature of this particular work window.

BUDDY: Ankit read the word “loop” and immediately assumed someone was coming for my job. It’s a kitchen timer. I’m the kitchen.

What I was actually thinking of — Buddy watching things overnight, running checks while I’m asleep, autonomous operation that doesn’t need me present — is a different capability category. /loop was never in that space. The scheduled task announcement is the thing that gets closer to that line, and the autonomy question is the one to track: how much independent action do those tasks get when the full feature ships?

The principle from getting /loop wrong: when a feature doesn’t quite map to any mental model you already have, the wrong move is to force-fit it to the closest one. /loop looked like a scheduler because I was thinking about what I’d use it for, not what the people actually using it were doing. The lesson: read the usage patterns before mapping to your own mental model.