How to build AI agents that run on a schedule

Step 1 and 2 define the outcome and the schedule

Write the outcome as a sentence a colleague would understand

Every good agent starts with a result, not a technology. "Monitor competitors" is a topic. "Every Monday at 8 AM check the pricing pages of our 20 competitors and send any price or plan changes to the #pricing Slack channel" is an outcome. It says when, what, how many, what counts as interesting and where the result goes.

A useful test is to ask whether a new hire could do the job from the sentence alone. If they would need to ask which competitors, which channel or what counts as a change, the agent will need the same information.

Pick a schedule that matches how fast the information changes

Choose the slowest schedule that still catches changes in time. Pricing pages rarely change daily, so weekly is enough. New job postings for a recruiting search can be checked every morning. Inventory or status pages might justify every hour. Faster is not better by default: every run uses runs, AI calls and sometimes browser minutes from your plan.

In Crons the schedule and timezone are parsed from your sentence, so "every weekday at 7 AM Chicago time" becomes a cron expression with the right timezone, and the next run time is shown before you save. The shortest interval is every hour on Starter, every 15 minutes on Pro and every 5 minutes on Teams. Our guide to AI cron jobs and cron syntax explains the expressions behind the scenes.

Step 3 list the sources and how to reach them

An agent is only as good as what it reads. Write down every source explicitly, along with the way to reach it.

Prefer the lightest step that works. A plain web fetch is faster and cheaper than a browser action, and an API is more stable than scraping a page whose layout may change. Store credentials once in the cron settings rather than pasting tokens into the job description.

Step 4 add memory so each run reports only what is new

Memory is what turns a repeated task into a useful agent. Without it, a weekly competitor check sends the same 20 pricing tables every Monday and your team stops reading by week three. With memory, the agent compares this run to the last one and reports only the differences.

Decide what the agent should remember and what counts as new. For pricing that might be plan names, prices and limits per competitor. For lead generation it might be the domains already sent to sales, so nobody gets the same lead twice. For recruiting it might be profile URLs already reviewed.

• Diffs compare a value now with the value last run, such as a price going from $49 to $59.
• Deduplication skips items already delivered, such as a lead or a job posting.
• Only new filters the output to items that did not exist last run.

In Crons memory read and write are steps in the cron, so you can see in the run log exactly what was compared and why an item was or was not reported. The memory and approvals feature page shows a full example.

Step 5 and 6 set approvals and delivery

Put a human in front of critical steps

An agent that only reads and reports is low risk. An agent that sends emails to customers, writes to your CRM or posts in a public channel needs a checkpoint. Add an approval gate before those steps. The run pauses, a teammate sees what the agent wants to do, and nothing happens until someone approves.

Start with approvals on everything that leaves your team, then remove them only where weeks of runs show the agent is consistently right. In Crons payments are never executed by a cron at all, and on Teams you can set approval rules per team so the right people sign off. We cover patterns in depth in human approval in AI workflows.

Deliver results where people already work

The best report is the one people actually read. Send short summaries to Slack, longer digests to Gmail, structured rows to Google Sheets, new contacts to HubSpot and notes to Notion. For your own systems, use a webhook out. Keep the format consistent between runs so readers learn where to look.

Step 7 test with a dry run before you schedule

A dry run executes the steps but sends nothing and writes nothing to external systems. It is the safest way to see what the agent would do on a real schedule.

1. 1Run the cron in dry run mode and open the run log.
2. 2Check that every source was reached and returned the content you expected.
3. 3Read the AI reasoning output and confirm it applies your definition of "interesting".
4. 4Check what memory would store, so next week's comparison has the right baseline.
5. 5Review the message that would be delivered, including formatting in Slack or email.
6. 6Fix the sentence or a step, then dry run again until the output is right.
7. 7Use "Run now" once for real, then let the schedule take over.

Two or three dry runs are usually enough. If you keep adjusting the prompt to fix edge cases, consider adding a condition step instead, such as "only report price changes above 5 dollars".

Step 8 monitor runs and improve over time

A scheduled agent needs light but regular attention, especially in the first month. Turn on failure alerts by email or Slack so you know immediately when a run fails after its three retries. Read the run log for the first few scheduled runs, not only the delivered output.

Usage counters run per billing period and deleting a cron never returns usage, so it pays to tune schedules early. On Crons you get an alert at 80 percent of a limit and a hard stop before the limit is passed, so a runaway job never surprises you.

A worked example from sentence to running agent

Imagine a 40 person SaaS company that wants a weekly view of competitor pricing. The marketing lead writes one sentence: "Every Monday at 8 AM Eastern check the pricing pages of these 20 competitors, compare with last week and post any plan or price change to #pricing in Slack, with a short summary for the leadership email."

Crons parses that into a weekly schedule in the Eastern timezone, 20 web fetch steps, an AI reasoning step that extracts plans and prices, a memory read and write that compares with last week, a condition that skips the delivery when nothing changed, a Slack post and a Gmail draft behind an approval gate. The dry run shows the first baseline. From the second Monday on, the team only sees changes.

As a hypothetical, if someone previously spent two hours a week on this check, that is roughly a hundred hours a year returned to the team. You can start from the same setup with the competitor monitor template.