Most teams have a list they never quite finish. The weekly security review. The monthly analytics summary. The competitor check. The quarterly revenue narrative. None of it is urgent in any given week, all of it matters over a quarter, and every item survives on someone remembering.
The obvious move is to point an AI assistant at it. That works exactly once. Next week you rebuild the context, re-explain the format, and re-read output you cannot compare to last time because you asked slightly differently.
The useful question is not "can AI do this?" It is "does this deserve a schedule?" Those are different tests, and the second one is stricter.
The four-part test
Work belongs on a schedule when all four of these are true.
1. The responsibility is stable, even when the inputs are not
The instruction "audit this repository for newly introduced security risk" holds for fifty weeks. The repository, the diff window, and the findings change every time — the responsibility does not.
Compare that to "help me think through our security posture." Also valuable, also AI-shaped, but the shape of the request changes every time you make it. That is a conversation, and conversations do not benefit from a cron expression.
The test: could you write the instruction once, today, and still mean it in three months? If the answer requires "well, it depends on what's going on," you have a conversation.
2. The value comes from noticing change
Recurring output earns its keep by making differences visible. A weekly audit that reports the same fourteen issues every Monday gets skimmed by week three and ignored by week six.
The routines that stay useful are the ones asked to compare: what changed since the last run, what is new, what resolved, what nothing happened to. That framing turns a report into a signal.
If the answer is genuinely the same every period, you do not need a routine. You need to fix the thing.
3. Someone can tell whether it was done well
This is the one people skip.
A scheduled routine runs unattended. If nobody can look at the result and say "yes, that is right" or "no, it missed the point," you have automated the production of confident text and nothing else.
Practically, this means the work has to leave evidence. A security audit cites file paths. An analytics report cites the query it ran. A revenue summary states its date range and its assumptions. Deliverables that cannot cite anything are the ones where unattended generation goes quietly wrong.
4. The consequences of a bad run are recoverable
There is a real difference between a routine that produces a draft and one that publishes. Between one that opens a pull request and one that merges it. Between one that reads financial data and one that moves money.
Reversibility is a better guide than severity here. A routine that opens a pull request touching eight files is a bigger action than one that posts a sentence to a social account, but the pull request waits for a human and the post does not.
Start with work whose worst outcome is a wasted five minutes of review.
What fails the test, and what to do instead
| The work | Why it fails | Better shape |
|---|---|---|
| "Help me decide whether to raise prices" | Not stable; the question changes each time you ask | A conversation |
| "Summarise our current architecture" | No change to notice; the answer is the same monthly | A document, written once and maintained |
| "Tell me if anything looks off in production" | Nobody can judge the output against evidence | Alerts with thresholds |
| "Reply to inbound sales emails" | Irreversible, and wrong replies cost you the deal | Drafts a human sends |
| "Audit the repo for new risk every Monday" | Passes all four | A routine |
The part that is not about AI
Notice what the test is actually measuring. Stability, change-detection, verifiability, reversibility — none of these are model capabilities. They are properties of the work.
That is why "which model should I use?" is almost never the first question worth asking. A weak model on well-shaped work produces something you can check and improve. A strong model on badly-shaped work produces something fluent that nobody can evaluate, delivered reliably, forever.
Shape the work first.
Starting
Pick one item off your list — the one you have postponed most often. Write the instruction as if the person doing it will never be able to ask you a follow-up question, because they cannot. Say what the deliverable is, what counts as evidence, what is out of bounds, and what to do when something cannot be verified.
Run it once by hand. Read the trace, not just the result: what did it actually look at before it concluded anything?
Then, and only then, give it a schedule.
That last order matters more than anything else in this post. The point of a routine is not that it runs without you. It is that it runs without you after you have seen it work.
Work on Repeat runs recurring AI routines with approved tools, explicit limits, and a full trace of every run. See how it works, or read the documentation.