Agents that run on their own: automating a recurring task with a scheduled agent
The difference between an agent you invoke and an agent that runs on its own isn't technical, it's psychological. As long as I'm at the screen reading every response, a mistake gets corrected in seconds. Once an agent runs without me, the question changes: it's no longer "does it work", it's "what happens the day it doesn't".
Three ways to run an agent without thinking about it#
I distinguish three mechanisms, which answer different needs and are easy to confuse.
| Mechanism | Runs when | Survives closing the session |
|---|---|---|
Loop (/loop) | At a fixed interval or a pace the agent chooses | No |
| Scheduled agent (cron) | At a time or frequency set in advance | Yes |
| Hook | On a specific event (before a tool, on failure) | Only meaningful during a session |
The hook isn't really "autonomous" in the sense I mean here: it reacts, it doesn't plan anything. The loop is useful for a task bounded in time, a watch running while I work on something else. The scheduled agent is the only one of the three that keeps existing once I close my laptop, and it's also the one that demands the most rigor upfront.
Designing a scheduled agent that doesn't break anything#
Three rules I apply systematically, after seeing what happens when I don't.
1. Always a dry-run mode before the real action#
My todo-list-to-calendar sync agent accepts a --dry-run flag that shows
the plan without changing anything. I used it systematically the first
week, before letting the agent write directly. Without that mode, the
first parsing error would have created a dozen malformed events in a
shared calendar.
Dry-run isn't a training-wheels feature for beginners, it's a permanent step in a scheduled agent's lifecycle: every time the logic changes, I go back through dry-run before re-enabling real execution.
2. A strictly limited write scope#
An agent that reads broadly but only writes within a narrow, explicit scope tolerates its own mistakes better than an agent given broad access "just in case". My repo-watching agent is read-only: it summarizes, it never modifies anything. The one that writes to my calendar only touches events it created itself, identifiable by a marker, never existing events.
3. A visible feedback channel for silent failures#
A scheduled agent that fails without reporting it is worse than no automation at all: you believe the task is done, it isn't. I prefer an agent that notifies systematically, even on success, over a silent agent whose failure I discover three weeks later.
What I run today#
Three scheduled agents, with very different levels of trust:
- A daily sync from my todo list to Google Calendar, with explicit confirmation before any destructive change.
- A weekly summary of git activity across all my projects, read-only, so I don't have to reopen each repo one by one.
- A periodic audit of outdated or vulnerable dependencies across all my projects, with a prioritized summary rather than a raw list.
What the three have in common: none of them started out scheduled. Each one ran manually, invoked on demand, several times before I trusted it to run unsupervised.
The main trap: overtrust#
The temptation, once a scheduled agent has run correctly a few times, is to stop checking its results. That's exactly the moment a silent drift can creep in: an API update that breaks a call, a data format that shifts slightly. I keep the weekly summary as a safety net: even agents on autopilot produce a trace I review, at minimum once a week.
An agent that runs on its own isn't an agent you trust more, it's an agent designed so a mistake stays visible and reversible, even when nobody is watching the moment it happens.
