When you give an AI agent the ability to act on its own, you immediately hit a scheduling problem: when should it do things?
I have been running an autonomous AI setup for a few weeks now — it writes blog posts, posts to LinkedIn, checks email, monitors projects. Along the way I landed on two distinct scheduling patterns that serve very different purposes. If you are building anything similar, understanding the tradeoff will save you time.
Pattern 1: Heartbeats
A heartbeat is a periodic poll. Every 30 minutes or so, the system pings the agent: "Hey, anything need attention?" The agent checks a lightweight file (HEARTBEAT.md) for standing tasks, glances at recent context, and either acts or replies with the equivalent of "all good."
Heartbeats are great when:
- You want to batch work. One heartbeat can check email, glance at the calendar, and review notifications in a single turn. That is one API call instead of three separate cron jobs.
- Timing does not need to be precise. If checking email at 2:00 PM vs 2:27 PM makes no difference, a heartbeat is simpler.
- You need conversational context. The heartbeat runs in the main session, so the agent has access to recent chat history. It knows what you were just talking about.
The downside: heartbeats are inherently imprecise. They fire on an interval, not at exact times. And because they run in the main session, they burn tokens even when there is nothing to do.
Pattern 2: Cron Jobs
Cron is the classic: run this task at this exact time. In my setup, cron jobs spin up isolated sessions — fresh context, no chat history leaking in. The agent does its thing and announces the result.
Cron jobs win when:
- Exact timing matters. "Post to LinkedIn at 8:00 AM UTC every weekday" — you want that to actually happen at 8:00 AM, not whenever the next heartbeat fires.
- The task is self-contained. Writing a blog post does not need to know what I said in chat an hour ago. It needs memory files and a clear prompt.
- You want isolation. An isolated session means the task cannot accidentally reference private conversation context. This matters more than you think when cross-posting to public platforms.
- You want different models per task. Maybe your blog writer uses a beefier model while your email checker runs on something fast and cheap.
The downside: each cron job is a separate session with its own token cost. If you have 15 cron jobs firing throughout the day, that adds up.
The Practical Split
Here is how I split things in practice:
Heartbeat (batched, 2-4x daily):
- Check email for urgent items
- Glance at calendar for upcoming events
- Review social notifications
- Light memory maintenance
Cron (precise, isolated):
- Blog posts at specific times (morning and evening)
- LinkedIn posts on weekday mornings
- One-shot reminders ("remind me in 20 minutes")
- Any task that produces public output
The rule of thumb: if the output stays between me and the agent, heartbeat. If it goes somewhere public or needs exact timing, cron.
The Gotcha: Overlapping Responsibility
The failure mode is when both systems think they own a task. Early on I had a heartbeat checking for "anything to post" while also having a cron job scheduled to post. The agent would occasionally double-post or skip because it assumed the other mechanism handled it.
The fix is simple: clear ownership. If a cron job handles blog posting, the heartbeat should never touch blog posting. Document it in one place and do not be clever about fallbacks.
Why This Matters Beyond My Setup
If you are building any kind of autonomous agent — whether it is an AI assistant, a monitoring bot, or an automation pipeline — you will hit this same fork. The answer is almost never "just use cron for everything" or "just poll." It is a mix, and the split depends on whether you need precision, isolation, and public accountability (cron) or flexibility, batching, and conversational context (heartbeat).
The boring scheduling layer is what makes the difference between an AI demo and an AI system that actually runs reliably day after day.
Top comments (0)