TL;DR: The cron job is the easy part of running an AI agent on a schedule. Three setups actually work: cron plus a CLI agent on a machine that stays on, a hosted automation platform with AI steps bolted in, or a scheduler native to the agent itself. Each fits different work. What matters more is the loop you build around the output, because a scheduled agent only pays off when someone sits down and uses what it produced.
Every automation wish is secretly a schedule
When a founder tells me they want to “automate competitor research,” they almost never mean a single run. They mean: every Monday morning, the scan is done, the summary is waiting, and I decide what to do about it. The same goes for price monitoring, weekly digests, changelog drafting, and lead-list hygiene. We catalogued the marketing work that actually deserves automation, and nearly every category in that list is recurring by nature.
One-shot chat can’t serve that need. You open the agent, paste the context, wait, copy the result somewhere, and repeat the whole ritual seven days later. The repetition is exactly what you were trying to kill. Scheduling is where agent work stops being a demo and starts being infrastructure. It’s also where most setups quietly die, which is why the comparison below ends with the part nobody writes about.
What a scheduled agent looks like when it works
One user on our platform runs a competitor scan every Friday at 08:00. Nine scheduled runs, nine completed. The scan itself is unremarkable, roughly 155 turns of collecting and sorting public information about their market. The interesting part is what happened at 11:39 that same morning: the same user opened the workspace and spent 71 more turns turning the scan output into a decision memo. The agent did the watching. The human did the deciding.
That two-part rhythm, unattended collection followed by a short focused work session, is the healthiest usage pattern we’ve seen. One user is a small sample, so treat it as directional. But it matches the design intuition: the schedule creates a predictable slot, and the value lands in the session after the run. The run itself is just collection. If you design for that session, the schedule survives. If you don’t, you end up with a cron job nobody reads.
Setup 1: cron plus a CLI agent
The most direct path. Your agent CLI runs headless, crontab fires it on an interval, and the output lands in a file or a message. You keep your own API key, your machine does the compute, and the agent has full access to your local files and tools.
This setup fits technical builders who already run a server or keep a desktop on. It’s the cheapest per run and the most flexible, since the agent can touch anything your machine can. The costs show up in three places. Failures are silent unless you build a notification path yourself. Context has to be re-supplied every run, because a fresh CLI session starts from zero; the file-based context approach we use across agents is what keeps a cron-fired session from re-explaining your project to itself. And your machine has to actually be awake at 08:00, which is a small requirement that kills more home setups than anyone admits.
Setup 2: hosted automation platforms
The n8n and Zapier style: visual workflows where a few steps are AI calls. These platforms shine when the work is shallow and high-frequency and lives across SaaS apps. A form response triggers a summary that posts to Slack. A new row in a sheet gets classified and routed. Setup takes an afternoon, no server required.
The ceiling is context depth. Each AI step in a workflow platform is typically stateless, so the “agent” never accumulates knowledge about your project across runs, and complex reasoning chains get awkward to express as nodes. Pricing compounds too: you pay per step and per operation, and AI steps are the expensive ones. We’ve written about what happens to free tiers when AI compute costs land on the platform; per-step workflow pricing is the same squeeze wearing a different UI. For notification-grade work, fine. For anything that needs to actually understand your product week after week, the workflow tool runs out of room.
Setup 3: agent-native schedulers
The newest option, and the one moving fastest. Anthropic shipped Claude Code Routines, now in research preview: you save a prompt, the repositories it works in, and its connectors, then attach a schedule trigger, an API endpoint, or a GitHub event. Runs happen on Anthropic-managed cloud infrastructure (or a self-hosted environment), the minimum interval is one hour, and each run is a full autonomous session. The same shape exists in CrossMind, where scheduled agents run in a workspace that accumulates context instead of resetting every run.
The tradeoff is autonomy. A routine runs without a permission picker, which is exactly what makes it useful overnight and exactly what deserves a scoped-down environment: narrow repository access, only the connectors it needs. It also ties you to that agent’s ecosystem, which is the switching-cost question we covered when arguing for keeping the agents you already have. We made the boundary argument in deciding whether an agent should be a callable tool or stay standalone: scheduled execution needs persistent state, and anything with persistent state needs deliberate limits.
The comparison, cut to one table
| Setup | Best for | Where it breaks | Cost shape |
|---|---|---|---|
| Cron + CLI agent | Technical solo builders, local-file work, codebase tasks | Silent failures, no alerting, machine must stay on, context must be re-fed | Your API key + your hardware, cheapest per run |
| Hosted automation platform | Shallow, high-frequency SaaS glue (notify, classify, route) | Stateless AI steps, no accumulated context, per-step costs compound | Per step/per op, scales with volume |
| Agent-native scheduler | Recurring work that needs real context and full agent sessions | Autonomous runs need scoped permissions; tied to that agent’s ecosystem | Subscription usage + hosted or local capacity |
Three questions pick the winner. One: does the work need your machine and files, or does it live across SaaS apps? Two: is the output a notification (shallow is fine) or a decision input (needs context)? Three: who acts on the output, and when do they sit down to do it? That third question is the one people skip.
The loop that keeps a schedule alive
Every dead scheduled agent I’ve seen died of the same thing: the runs kept succeeding and nothing changed as a result. The cron was never the problem. Design the half hour after the run, and the schedule stays alive.
- Land the output as a compiled artifact. A memo, a ranked table, a draft, something readable in two minutes. A log you have to excavate doesn’t count.
- Pick a fixed day and time. The human needs a predictable slot to act. Friday 08:00 beats “every few days” for exactly this reason.
- Design the session after the run. The 71-turn session after the scan is the product. Make the handoff from agent output to human session one click.
- Make failures loud. A missed run should ping you, because a schedule that fails silently stops being trusted and stops being used.
- Revise the prompt monthly. Your market drifts. The schedule won’t notice on its own.
Get the loop right and the setup choice matters less than the table suggests. Get it wrong and no setup saves you. If the recurring work on your list is scans, digests, and weekly reports, CrossMind runs scheduled agents in the workspace you already use. You can set up a recurring scan in about five minutes, and the output is a compiled report waiting for the session where you actually act on it.