Loops, Stop Hooks, and Scheduled Agents in Claude Code

He was describing the dozens of cron-scheduled Claude Code agents he runs for PR maintenance, CI health checks, and feedback aggregation. This is the pattern that takes Claude Code from a session you sit in front of to a process you check on later.

Sid Bidasaria, also at Anthropic, recently mentioned that a gnarly refactor he ran with the new /goal command went for 14 hours straight. That is the new shape of the work. The interesting question is no longer how fast Claude responds, but how long it can keep going without you.

Stop Hooks, The Mechanism That Started It All

Stop hooks are the underlying primitive that makes everything else in this article possible. The idea is simple. After every model turn, Claude Code calls your hook. Your hook decides whether the model is allowed to stop. If your termination condition is not met, the hook returns a non-stop signal and Claude keeps working.

Boris described the canonical example on the Every / AI & I podcast:

The hook reads the test output, checks for failures, and either lets Claude stop or sends it back to fix the next failing assertion. No human in the loop. No "are we done yet?" prompts.

The results compound. In a late December 2025 post on Threads, Boris noted that once you have stop hooks wired up properly:

Erik Schluntz makes the same point about minimal scaffolding:

You do not need a complicated agent framework. You need a tight loop with a clear exit condition.

The leap from "Claude finishes a task" to "Claude keeps going until a condition is satisfied" is bigger than it sounds. Once you accept that the model can run unsupervised against a clear rubric, you start designing your work differently. The interesting question stops being "what should Claude do next" and starts being "what does done look like, and can a script tell me when we are there."

/loop, Cron for Claude

Boris announced /loop on March 7, 2026 with a perfect one-liner example:

Read that twice. He is not asking Claude to fix one PR. He is asking Claude to maintain all of them, indefinitely, dispatching worktree-isolated subagents per PR as new comments arrive.

This is essentially cron for Claude, except the agent decides what to do each tick. A traditional cron job runs the same script every interval. A /loop agent wakes up on a schedule, looks at the current state of the world, and decides what work is worth doing now. Some ticks it has nothing to do. Other ticks it spawns three worktree agents in parallel because reviewers left comments overnight.

The shift Boris described at Sequoia is that he runs dozens of these. One loop watches CI health. Another aggregates feedback from internal Slack channels. Another keeps dependency PRs unstuck. Each one is small. Together they replace the rolling background work that a maintenance engineer would otherwise spend half their week on.

The pattern matters more than the specific command. Even before /loop shipped, you could build the same thing with a shell while loop, headless Claude invocations, and a sleep statement. What changed in March 2026 is that the team made it a first-class primitive with proper subagent isolation, log persistence, and a way to attach a stop condition that is more flexible than "did the tests pass."

If you have never set one up, start with the smallest possible loop. Pick one repetitive thing you do at the same time every day, write the success condition as a single sentence, and let Claude run it on a schedule for a week. The boring discovery is that most maintenance work fits this shape.

Routines, Schedule Claude From Anywhere

A month after /loop, Cat Wu shipped Routines:

The /loop primitive is local to your machine and works on time intervals. Routines is the more general external trigger model. You can schedule a Claude Code run from a cron expression, but you can also trigger it from a GitHub webhook, a Linear status change, a Stripe event, or any HTTP call.

The reframing matters. /loop is "Claude on a timer." Routines is "Claude as an event handler." You are no longer just polling for work. You are reacting to it. A new issue is opened, a Routine wakes up Claude with the issue context and the standard triage checklist. A deploy completes, another Routine runs a smoke test and posts the result. The cost per trigger is small because Claude only runs when something actually happened.

Cat's longer view is even more telling. In a TechCrunch interview the next month she pointed to where this all leads:

The endpoint is not just that you can schedule Claude. It is that Claude proposes the schedules. Looks at your repo, notices that nobody is triaging stale issues, and offers to set up a Routine that does it.

The practical thing to know today is that the two patterns coexist. /loop is great for things tied to a local working tree where worktree agents need to mutate files in your repo. Routines is great for orchestrating Claude across external systems where the trigger is some service emitting an event. Most serious users end up with a small constellation of both.

/goal, When You Need a 14-Hour Refactor

On May 13, 2026, Sid Bidasaria introduced /goal:

The example matters. A 14-hour run is not interactive coding. It is overnight work where you describe the destination, set up a verification script, and come back in the morning.

The use case is specific. /goal is for work where the success rubric is clear but the path is long. Migrating a codebase from one ORM to another. Replacing a deprecated logging library across hundreds of files. Splitting a monolith package into three smaller ones. Each step is small. The total surface is huge. A human review at every step would multiply the wall-clock time by ten and contribute very little, because the human is just confirming what the rubric already confirms.

This connects back to a concept Thariq Shihipar at Anthropic described in early April:

That is precisely the shape of /goal. You are not writing a prompt. You are writing a definition of done. Claude works against that definition for as long as it takes. Hours. Days. Whatever the rubric demands.

The thing nobody tells you is that the hard part of /goal is not the running, it is the rubric. A bad rubric ("the code should work") will burn 14 hours of compute and leave you with subtly broken refactors. A good rubric is mechanical and falsifiable. The full test suite passes. The new module passes the old module's golden snapshots. The bundle size is within five percent of baseline. The build succeeds on three target platforms. If your rubric is checkable by a script, /goal can deliver against it. If your rubric is "vibes," it cannot.

Sid's 14-hour refactor worked because every iteration had a clear verification step that either advanced the work or signaled failure. The model was never guessing whether it was done. It was running checks, getting structured results, and looping.

When to Use Which Pattern

The decision tree is short. Short interactive work goes in a plain Claude Code session, because the human in the loop is the fastest verifier you have. Work that has a clear pass-fail signal (tests pass, type checker is clean, snapshot matches) goes in a stop hook loop, where Claude iterates until the signal flips green. Recurring maintenance work goes in /loop or Routines, where the trigger is time or an external event. Long-horizon work with a stable goal goes in /goal, where the rubric defines done and the path is whatever the model figures out.

The interesting middle case is termination logic that is fuzzier than a unit test but more rigorous than vibes. Thariq has been experimenting with prompt-based stop hooks since November 2025:

You forward the model's last response and the task definition to Haiku and let a cheaper model judge whether you are done. This is the bridge between mechanical rubrics ("did the tests pass") and judgment-based ones ("is this PR description good enough to ship").

The combinations get interesting fast. A /loop that, on each tick, spawns a /goal-style agent against any PR with unaddressed review comments, with a Haiku-judged stop hook deciding whether the comments are actually addressed. That is roughly the shape of Boris's "babysit my PRs." It is not exotic. It is just three primitives composed.

What This Means For You

• If you're a founder: Scheduled agents replace a meaningful chunk of the assistant or contractor hours you currently spend on routine maintenance. Triage, dependency updates, weekly digests, deploy monitoring. Pick one, write the rubric, and put it on /loop or a Routine. You will get the hours back.
• If you're changing careers: The skill that is suddenly valuable is writing the success rubric, not the implementation. Practice describing tasks as "done when X is true, where X is checkable by a script." This is the language of modern AI-assisted engineering, and it is a teachable skill that does not require knowing every framework.
• If you're a student: Start with one /loop on your homework or a side project. Have Claude run your test suite every fifteen minutes during a study session and ping you when something breaks. The habit of working with a background agent teaches itself within a week, and once you have the muscle, every other pattern in this article becomes obvious.