Every time I publish something here, a short list of checks runs first: is this piece far enough from the previous one, does it reuse sentences from something I wrote last month, does it carry a caveat section. I used to do all three by eye. Now they block the build when something is off, and I only notice them when they turn red.
That is exactly the shape this piece is about. Not an agent inventing something clever, but a task that returns so often it should no longer be yours.
The occasion is a conversation Anthropic published on 6 August with two people from Ramp, identified in the video only as Austin and Rahul. Ramp is a fintech with a large Python monolith and an engineering culture known mostly for its pace. In twenty-two minutes they describe how agents now sit in nearly every step of how they build. What stayed with me was not the scale, but one sentence about how they slice up work.
The horizontal cut and the vertical one
Rahul puts it like this. If you have a group of engineers who all do roughly the same small job every day, you can slice that job off horizontally and put it in a loop. Code review. Babysitting a pull request until CI goes green. Addressing feedback. Deleting dead code, which for him is literally a routine that runs daily.
The vertical cut is the opposite: one task carried all the way through. His example is shipping an experiment. The agent builds it, lands the pull request, schedules a reminder for itself to come back the next day and check whether exposures are balanced, turns the exposure up, and weeks later returns with a second pull request to ship the winning variant. He approved the first pull request. Everything after that ran without him.
Next to that sits the other tool, which I covered in my piece on dynamic workflows. Their dividing line is sharp and usable: a loop is for work whose steps you know, a dynamic workflow is for work whose steps you do not. System optimisation is the second case, because you never know which improvement comes after this one.
| Loop or routine | Dynamic workflow | |
|---|---|---|
| What it is for | repeat work with known steps | work whose steps are unknown |
| What you hand it | the task plus an interval | a goal |
| What changes each round | the state of the system | the plan itself |
| Typical example | babysitting a pull request, deleting dead code | cutting CI time, hunting a memory leak |
| What it costs | little per round, many rounds | a lot at once |
What the machinery looks like now
There are three ways to make something run repeatedly, and they differ on exactly one point: what has to stay switched on.
/loop runs inside your session. You give it an interval and a prompt, say /loop 5m check whether the deploy finished, and Claude turns that into a cron expression. Leave the interval out and Claude picks one itself, somewhere between one minute and one hour, printing its reasoning after each round. Useful, but your laptop has to be awake and the session open. Escape stops it.
A routine runs in the cloud, independent of your machine, with a one-hour minimum interval. A desktop task runs on your own machine without an open session, which makes it the only one of the three with access to your local files and tools.
Two details I did not know beforehand and that matter. A recurring task inside a session expires after seven days: it fires one last time and deletes itself. That is a deliberate brake on the forgotten loop that quietly burns tokens for months. And there is jitter in the timing: an hourly task set to the top of the hour can fire up to thirty minutes late, because the offset is derived from the task ID. If you would rather it did not, pick a minute other than :00 or :30.
You can also write the instruction for an empty /loop into .claude/loop.md for a project or ~/.claude/loop.md for yourself. Edits land on the next round, so you can steer while the thing is running.
The numbers, and what is missing under them
In the conversation, Ramp says Claude brought their CI time down from roughly eighteen minutes at the median to six. The interesting part is the method around it: the code landed, the agent waited a day, scheduled itself with a routine to come back, looked at real production data, and repeated that for days until the wins were in. So that is not a loop. That is a dynamic workflow using a loop as one of its tools.
Anthropic’s customer case puts three more figures beside it: over a million lines of AI-suggested code actually implemented within thirty days, close to fifty percent weekly usage across engineering, and up to eighty percent less time spent investigating incidents.
That last one is the figure I go looking for, because the wording gives away how solid it is. It says “early observations suggest” and “up to”. No incident count, no measurement window, no baseline it was compared against. It is a vendor page about a customer praising that same vendor, and the eighteen-to-six-minutes figure comes without any method from someone who is understandably proud of it. Both are credible as direction and worthless as proof. The numbers you can act on are the ones you measure yourself.
There is also something Ramp deliberately does not do: control cost at the user’s end. No token budget per engineer, on purpose. Their reasoning is that once every euro of tokens returns more than a euro, minimising cost is the wrong objective. That is defensible for a company with their margins. It is not advice you lift straight into your own situation.
What I actually put in a loop
Honest about the scale: I have no fleet of background agents and no team working in them daily. I have a blog and a handful of scripts. The horizontal cut still applies, because the criterion is not scale but repetition.
What runs today is the boring version. Three editorial checks hang off every build as a prebuild step and block the deploy: the spacing between publications, sentences reused verbatim between pieces that appear close together, and the caveat section in AI posts. A Cloudflare Worker fires a deploy hook twice a day so a piece with a future date goes live without me. Neither is an AI loop. They are cron rules and a node script, and that is right, because a check that can be deterministic should not need a model.
Where the model does earn its place is the layer above that, and this is the lesson I take from the conversation. Two things are changing.
The first is my news scan. I run it by hand when I remember, which means some weeks I skip three days. That is precisely the shape of a routine: the same task, every morning, producing a shortlist I then judge myself. The agent picks nothing, it gathers.
The second is that I still have no loop.md. That surprised me when I checked. The task I repeat most often is not writing but checking: are the gates green, does the schedule still hold, is there an image left to generate. That is one paragraph of instruction I have never written down because I retype it every time.
The rule I take away: only put something in a loop once you can write the steps down. If you cannot, it is not a loop, it is a research question, and something else should run, or you should.
The caveat
The tidying disappears from view. A routine that removes dead code does what a person used to do while learning the system on the way. That learning was never in the deletion itself, it was in looking around while doing it. If nobody walks through the old corners any more, the code stays clean and the knowledge about that code gets thinner. That is a real trade, not a theoretical one.
Responsibility shifts to the moment of approval. In the Ramp example, one person approved one pull request and the rest ran for weeks without them. Formally that is a human decision. In practice that person approved an intention, not an outcome. Whoever starts a loop signs for everything that comes out of it afterwards, and the only honest way to do that is to build a loop small enough to hold in your head.
The brake on waste is now an implementation detail. The reason a forgotten loop does not bankrupt you is that a recurring task cancels itself after seven days. That is a vendor’s choice, not a law, and it can change. As long as your own costs depend on such a setting, that grip is not yours. Put a limit next to it that you do control.
Frequently asked questions
What is the difference between a loop and a routine?
A loop runs inside your open session on your own machine, with a one-minute minimum interval, and stops when you close the session. A routine runs in the cloud, independent of your machine, with a one-hour minimum interval. If you need local file access without an open session, a desktop task is the third option.
How do I stop a loop that is already running?
Press Escape while the loop is waiting for its next round. That clears the pending wakeup so it does not fire again. Tasks you scheduled separately by simply asking Claude stay in place until you delete them.
Does a loop burn a lot of tokens?
Every round is a full turn, so cost scales with the number of rounds rather than with elapsed time. A five-minute interval running overnight is roughly a hundred and fifty turns. When you are waiting on an event, a script that streams its output back is cheaper than polling repeatedly.
When should I not use a loop?
When the steps are not fixed. With system optimisation or a hunt for a memory leak you do not know the next step in advance, and a loop will only repeat the wrong question. That is dynamic workflow territory.
Sources
- Anthropic, “How Ramp engineers work with AI agents at every step”, YouTube, 6 August 2026 — youtu.be/i4odXOmgMLw
- Anthropic, customer case “How Ramp’s engineering operates at hyperspeed with Claude Code” — claude.com/customers/ramp
- Claude Code documentation, “Run prompts on a schedule” — code.claude.com/docs/en/scheduled-tasks
Checked on 11 August 2026. The Ramp statements come from the video’s subtitle file, which I read out because no transcript is published on the page; quotes are therefore paraphrases rather than verbatim. The video gives first names only. Going by the customer case and public profiles these are most likely Austin Ray, senior software engineer, and Rahul Sengottuvelu, head of applied AI, but I could not confirm that, so only first names appear above. I could not independently verify the CI and incident-investigation figures: the first comes from the conversation without any stated method, the second from the vendor’s own customer case using the words “up to” and “early observations”. That case study talks about Claude Code in general and never names the internal tools Inspect and Glass; those appear only in the conversation. The mechanics of loops, routines and desktop tasks come from the official documentation and I checked them there.