Agents & Automation · Layer III / Practitioner

Automate a workflow as a Claude routine

A routine is a saved instruction Claude runs on its own, on a schedule or an incoming signal. What it replaces, and why an unattended run has to be written tighter than one you watch.

Nº 026 · Vol. I·10 min read· Updated July 2026

Read first Automate the step that slows you down (Covers the four parts of any proactive automation (trigger, worker, access, receipt). This guide is one concrete way to build one.)

“a routine runs your instructions without you in the room”

Fig. 1 · The routine shape Event → Routine → Output

Event

Routine

pull the unread mail
draft each reply
send me a Slack update

plain language, not wired nodes

Output

✦ Slack update sent

Fire an event and the light runs the same path the lesson describes: a trigger, plain-language steps, an output. The middle is words you write, not boxes you wire.

A routine is a saved instruction that Claude runs on its own. You write out a task once, pick what sets it off (a time of day, an incoming web request, a direct call from your own code), and from then on it runs without you. The work happens on Anthropic’s servers rather than your machine, so it fires whether or not your laptop is open. The clearest way to picture one: the same prompt you would type into a live session, except it runs on a timer and reports back when it is finished.

01A saved prompt that runs itself

The example in the source video is a morning inbox routine. It reads the unread mail, checks each sender against earlier threads for context, drafts replies in the owner’s voice, and sends a Slack message with the summary and the drafts. It runs at 5:10 a.m., before he wakes up. He never starts it by hand.

Three things can set a routine off: a schedule, a web request that another service sends when something happens (a webhook), or a direct call from code you control. The last one matters more than it sounds, because it lets one routine hand work to the next: a finished sales call sends a transcript, which starts a routine that drafts the follow-up email. That is how small automations chain into a larger one.

02The same shape, minus the wiring

Every automation has the same three parts: an event that starts it, some logic in the middle, and an output it hands to another service. A schedule fires at 5 a.m., a chain of steps runs, and the result lands in Slack or a customer-record system.

The older no-code builders, tools like n8n and make.com where you assemble a workflow by dragging boxes onto a canvas, put all the work in that middle part. You wire the boxes together, set up a login for each service, and match every field by hand. That middle is where the hours went.

“Might make more sense just to one-shot it as a routine.”

Nick Saraev, “Claude Routines Just Dropped, And It's Perfect” · 15:01

A routine keeps the same event and the same output and replaces the hand-wired middle with plain-language instructions. You describe the steps instead of building them. The proposal generator that took the video’s author two to three hours to wire together is now a paragraph of instructions he can stand up in a couple of minutes. This is the same trigger-worker-output shape from Automate the step that slows you down, with the worker written rather than assembled.

03Write it to run unattended

An unattended run is the whole point, and it is also the catch. In a live session you read along and steer when the model drifts. A routine gives you no such chance, so the instruction has to be right the first time and every time.

“The routine occurs entirely hands-off, meaning that it basically needs to work almost perfectly every time.”

Nick Saraev, “Claude Routines Just Dropped, And It's Perfect” · 10:29

So write a routine tighter than a prompt you plan to babysit. A few habits do most of the work:

Spell out more context, not less. The model cannot ask you a follow-up mid-run, so everything it needs has to be on the page.
State a clear sign of when the job is done, such as “once finished, send me a Slack update.” That gives the run a definite end.
Name each step plainly to shrink the room for a wrong turn.

This is the same care that Brief the model like a brilliant new hire asks for, turned up because the work runs alone. Keeping a long unattended run honest is its own subject in Guardrails for hours-long agent runs.

04When a routine is the right tool

Not every workflow belongs in a routine. Running a task through a model costs more per step than running it as plain computation in a purpose-built tool, so moving a heavy flow that already works can raise the bill and buy you nothing. A stable, high-volume pipeline is often better left where it is.

The case for a routine is build time. When a task would take hours to wire together by hand, and you could instead describe it in a paragraph and have it running in minutes, the routine wins. Reach for it on new work you have not built yet, not as a blanket move of everything you already run. The gain is that changing it later is a sentence, not an afternoon of rewiring.

FAQ

A routine runs the same kind of instruction you might type into a live Claude session. What is the main difference, and why does it change how you write the instruction?

It runs unattended, on Anthropic's servers, started by a schedule or a signal instead of by you sitting there. In a live session you watch the work and correct course partway through. A routine gets no correction, so the instruction has to carry everything up front, meaning the full context, the exact steps, and a clear sign of when the job is done. You write it to fail as rarely as you can, because no one is there to catch a wrong turn.

In the event, logic, output shape, which part does a routine change, and to what?

The middle part, the logic. Older no-code tools had you build that middle by hand as a chain of drag-and-drop steps, with logins and field-matching to set up for each one. A routine replaces the hand-built chain with plain-language instructions. The event that starts it (a schedule, a web request, an API call) and the result it produces (a Slack message, a customer-record entry) stay the same.

The video warns against moving every existing no-code workflow into a routine. Why?

Running work through a model costs more per step than running it as plain computation in a tool built for that job, so moving a heavy flow that already works can raise the bill for no gain. The case for a routine is build time. A flow that would take hours to wire together by hand, you can stand up in a single pass by describing it. Reach for it on new work, not as a blanket move of everything you already run.

Sources

Nick Saraev · “Claude Routines Just Dropped, And It's Perfect”
cited at 0:05 · 6:14 · 7:50 · 10:29 · 15:01