# Cron is the wrong primitive for inbox and calendar watchers

Scheduled checks can ship a demo, but inbox and calendar assistants need event-aware wakeups with evidence and delivery semantics.

Published: 2026-05-24
Updated: 2026-05-24
Canonical: https://watch.qordinate.ai/blog/cron-is-the-wrong-primitive-for-inbox-and-calendar
Markdown: https://watch.qordinate.ai/blog/cron-is-the-wrong-primitive-for-inbox-and-calendar.md
Author: Rahul Jain
Author URL: https://www.linkedin.com/in/rahul_got_lazy
Image: https://watch.qordinate.ai/images/blog/cron-is-the-wrong-primitive-for-inbox-and-calendar.jpg

Tags:
- cron
- inbox agents
- calendar agents
- event-driven agents

## Short answer

Cron is useful for reconciliation, but it is a weak default for inbox and calendar agents. These domains are event-shaped: messages arrive, invites move, attendees change, and deadlines approach. A proactive assistant should wake from relevant change, not from the fact that five more minutes passed.

## Key takeaways

- Inbox and calendar workflows are sparse, noisy, and context-dependent.
- Cron creates repeated empty checks and pushes relevance decisions into expensive agent turns.
- Google Workspace, Microsoft Graph, GitHub, and Zapier all expose patterns that separate change detection from work execution.
- Event-aware watches should carry evidence: sender, organizer, thread, attendees, changed fields, and timing.
- Cron still belongs as a backstop for reconciliation and missed delivery recovery.

## Cron makes the demo easy

It is tempting to build the first proactive assistant as a scheduled prompt:

"Every 15 minutes, check my inbox and calendar. If anything important happened, tell me."

That works well enough to record a demo. It is also the shortest path to an assistant that reads too much, spends too much, and interrupts too often.

The problem is not cron itself. Cron is a good primitive for predictable jobs. The problem is using clock time as a substitute for user relevance. Inboxes and calendars do not become important every 15 minutes. They become important when a specific kind of event changes the user's future.

## The sources already know about change

Modern productivity APIs are built around change signals. Gmail has push notifications through Google Cloud Pub/Sub: https://developers.google.com/gmail/api/guides/push. Google Calendar exposes push notifications for resource changes: https://developers.google.com/workspace/calendar/api/guides/push. Microsoft Graph supports change notifications and also publishes throttling guidance that makes wasteful polling painful at scale: https://learn.microsoft.com/en-us/graph/change-notifications-overview and https://learn.microsoft.com/en-us/graph/throttling.

Even no-code automation tools expose this distinction. Zapier documents polling intervals because polling cadence is a product and cost decision, not a free background detail: https://help.zapier.com/hc/en-us/articles/15700915877133-Set-up-custom-polling-intervals-in-your-Zaps.

The agent stack should learn the same lesson. Detect change cheaply. Evaluate relevance before waking the expensive assistant. Deliver only matched work.

## Inbox watchers need field semantics

An inbox event is not just text. It has sender, recipients, thread, time, labels, attachments, previous replies, and organization context.

A cron-based assistant often collapses that into "read recent mail and decide." That pushes the entire relevance problem into a model turn. It also makes subtle mistakes more likely. A customer escalation sent to the user is different from a newsletter mentioning the same customer. A message where the user is `to` is different from one where the user is only `cc`. A vendor invoice is different from a billing incident.

The watch should encode those field semantics before the agent wakes:

- which senders or domains matter;
- whether `to`, `cc`, and forwarded threads have different meaning;
- which labels or folders are in scope;
- which phrases are evidence versus noise;
- whether the event is new, updated, or already handled.

That is not overengineering. It is how you keep a helpful assistant from becoming a second inbox.

## Calendar watchers need change semantics

Calendar events are deceptively hard. The interesting thing is often not the event itself, but what changed.

Was a meeting created, moved, cancelled, shortened, or expanded? Did the organizer change? Did an external attendee join? Did a location become a video call? Did the meeting move inside a travel window? Did a prep deadline become impossible?

Cron sees a snapshot. A watch should see a delta.

For example, "wake me if an enterprise customer meeting moves within 24 hours" depends on organizer, attendees, account identity, old time, new time, and current time. Asking an agent to rediscover all of that on every scheduled turn is both expensive and fragile.

## What should replace blind polling

The better pattern has four steps.

First, sources emit change. This can be a webhook, Pub/Sub notification, API delta token, or periodic lightweight sync.

Second, a match layer evaluates durable watches. It does not need to solve the whole task. It needs to decide whether the event deserves a downstream agent turn.

Third, the delivery layer queues matched wakeups with evidence. This matters when the assistant is local, offline, or busy.

Fourth, cron reconciles. It checks for missed notifications, expired watches, stale permissions, and backfill windows. Cron becomes the safety net, not the main sensor.

## The human problem is interruption quality

Inbox and calendar assistants live close to attention. Users will forgive a missed digest before they forgive repeated false alarms.

This is why the system should preserve "why now?" Every delivered wakeup should be explainable: this source changed, this watch matched, these fields were evidence, this is what the agent is allowed to do next.

That explanation does more than build trust. It gives users a way to tune the watch instead of abandoning the assistant.

## FAQ

### Should I never use cron for an agent?

Use cron for scheduled reports, stale-state cleanup, backfills, and reconciliation. Avoid using cron as the only way to discover whether an inbox or calendar event matters.

### Are push APIs reliable enough?

They are useful but not magical. Production systems still need retries, expiration handling, missed-event backfill, and rate-limit aware sync. That is why cron remains valuable as a backstop.

### What is the first improvement over polling everything?

Start by storing watches as explicit future conditions. Then evaluate new inbox or calendar changes against those watches before waking the full assistant.

## Further reading

- https://developers.google.com/gmail/api/guides/push
- https://developers.google.com/workspace/calendar/api/guides/push
- https://learn.microsoft.com/en-us/graph/change-notifications-overview
- https://learn.microsoft.com/en-us/graph/throttling
- https://help.zapier.com/hc/en-us/articles/15700915877133-Set-up-custom-polling-intervals-in-your-Zaps