Setting Up Scheduled Runs

Set up a scheduled run and your AI employee will wake up at the times you choose, do the work, and leave the results in chat, even when you’re not looking. A daily morning briefing, an hourly site check, a one-off “remind me in 30 minutes”: they all use the same simple mechanism.

What can I do with it?

A scheduled run is a simple loop: the employee works, leaves the result in chat, and a push notification lets you know it’s ready. You step away, your employee works, you check the answer when you come back.

Two ways to set up a scheduled run

1. Just tell the employee in plain language

Easiest path. Type it into chat the way you’d ask a person.

“Every morning at 8, pull the top 5 AI news stories from yesterday and summarize them.”

“Check this page every hour and only tell me if the price changes.”

“Come back in 30 minutes and recheck the result.”

The employee will register the scheduled run itself. A “Scheduled run registered” card appears in chat showing the next run time and the exact instruction it saved. You just confirm it looks right.

An employee can have up to 5 of its own active scheduled runs at any one time. Recurring and one-time scheduled runs count toward the same shared cap. Scheduled runs you add yourself from the UI are not subject to this cap.

2. Set it up from the UI

The Automatic runs menu (/agents/<employee>/schedules) has two distinct sections.

Self check-in (looking around on its own)

At the top of the page, the Self check-in toggle decides whether the employee looks around on its own, even without you, and handles what needs doing. Leave it on and at each check-in the employee actually takes care of any pending work within the tools and permissions you’ve allowed, then decides on its own when to check in next: less often when there’s nothing to do, more often when something’s pending. Rather than picking a fixed interval, it reads the situation each time and sets the next check-in point. Check-ins use AI too, so they spend SU. Just below, “Next self check-in: …” shows the next scheduled time.

Clicking the toggle saves immediately. If you only want the employee to move when you call it or when a scheduled run fires, turn self check-in off and use “Add scheduled run” below to register specific times only.

Add scheduled run (recurring or one-time)

For more precise timing, press Add scheduled run. At the top of the form there’s a Repeat / Once switch, then a Name (optional) field, then the request box. Both the name and the request are shared by both modes, so switching modes keeps whatever you’ve typed in either.

Why bother naming it: the title shown on scheduled run and run history cards comes straight from this name (e.g. “Morning news briefing”). Leave it blank and the card falls back to a truncated preview of the request instead. That’s fine for a one-off, but a long request makes for a long, hard-to-scan card title, so it’s worth naming anything you’ll reuse. You can change the name any time from the edit screen, up to 120 characters.

When you choose Repeat

1. Set the repeat rule. Pick one of two shapes at the top:
   • At a specific time: tap the days of the week you want (quick buttons for Daily and Weekdays), then pick a single time. The employee runs once on each chosen day, at that time. Example: Weekdays + 9:00 AM → fires once every weekday morning at 9.
   • Every (interval): pick one of 30 min · 1 h · 2 h · 3 h · 6 h · 12 h, and it repeats at that interval around the clock, every day. (There’s no way to restrict this to specific days or hours from this screen; for that, ask the employee in chat, as noted below.)
   • Your account timezone is applied automatically and shown at the top of the box (e.g. Asia/Seoul).
2. Save. The new scheduled run appears in the list with the next run time. The request you typed above is sent to the employee verbatim at every scheduled run. This scheduled run always carries the fixed instruction you gave it.

When you choose Once

1. Pick when it should run:
   • Quick picks: tap In 1 hour · Today 6 PM · Tomorrow 9 AM · Next Monday to jump straight to that time. Any option that’s already in the past drops off the list automatically.
   • Or enter a date and time directly.
   • You can schedule anywhere from 1 minute from now up to 1 year out. For anything further, use a recurring scheduled run and turn it off once you no longer need it.
   • Once you pick a time, a confirmation preview shows up, e.g. “Runs once at Aug 12 (Wed), 9:00 AM · in about 7 days.”
2. Save. It fires exactly once at the time you picked, then the scheduled run turns itself off. The run stays in your run history.

Either way, saved scheduled runs show up in the list with a Once / Repeat badge on the card so you can tell them apart at a glance. Once a one-time scheduled run fires, its badge changes to Done.

From the list you can:

• Toggle active/inactive: pause a recurring scheduled run without deleting it; it’s skipped until you re-enable it. A one-time scheduled run can be toggled too, as long as it hasn’t run yet. Once it fires, it can’t be reactivated, so the toggle disappears.
• Edit: for a recurring scheduled run, change the instruction (request) and the repeat rule (days/time, or interval). For a one-time scheduled run, change the instruction and the scheduled time only (converting it to recurring isn’t supported); one that already ran can no longer be edited.
• Delete: remove it once you no longer need it.
• Show/hide inactive scheduled runs: keep the list tidy when you’ve parked a few.

A scheduled run left inactive for 90 days is permanently deleted from the server (the self check-in toggle is the one exception; it’s always kept). If you plan to reuse it later, re-enable it or edit it within that window.

The iOS and Android apps offer the same editor, so you can add and manage recurring and one-time scheduled runs on the go.

Any repeat rule the UI’s “Add scheduled run” can’t express (a precise minute-level time, or an interval that should only run during certain hours, e.g. “every 2 hours, but only 9 AM to 6 PM on weekdays”), ask the employee directly in chat instead, and it will register a more precise rule for you. One-time delayed runs can be registered from the UI directly, or by asking in chat.

Automation cadence suggestions

Even without a scheduled run already in place, your employee may notice on its own that a certain kind of request keeps coming back on a regular beat. For instance, seeing that the last few times you asked for something, it was always on a Monday morning, around the same hour. When it spots that, it will add one short question to the end of its reply, something like “Want me to just do this on that schedule from now on, without you having to ask?”

The key thing to understand: that question is only a suggestion; nothing gets created just by the employee asking it. The employee is only naming the day and time it actually observed. A recurring scheduled run only comes into existence after you clearly say yes in chat. Once you do, a new recurring scheduled run is created the same way as under “Set it up from the UI” above, and from then on it shows up in the Automatic runs list like any other, and you can review, edit, or delete it there. If you decline or don’t respond, nothing happens, and the employee may ask again later if the same pattern shows up again.

This kind of suggestion won’t repeat if a scheduled run already covering that work exists, and it won’t appear for occasional, irregular requests that don’t form a clear pattern.

On a team: only offered when there’s a saved workflow

Work you hand to a team is watched the same way, but a team has one extra condition. The suggestion only appears when the team has already saved a workflow for that kind of work (see the “Team task list” section of Building Teams of AI Employees for how to save one). If there’s no saved workflow, the result can vary each time, so it’s never run unattended.

When the same kind of work you asked the team to do lines up on a regular beat, the Next steps card that appears in team chat once that work finishes gets one more item, something like “Run ‘Weekly report’ automatically every Monday at 9 AM.” Check it and press Do selected work, and a recurring scheduled run is created right there. From then on, the saved workflow starts as a new task automatically at that time. The timezone follows whoever most recently asked for that work, and the scheduled run is created under the name of the employee who owns the workflow, so it shows up in the team’s Scheduled runs tab alongside every other scheduled run.

If you decline or don’t answer, nothing gets created, and the team may ask again later if the same pattern keeps showing up. It also won’t suggest again once a scheduled run already covers that work.

If the saved workflow is deleted, the employee who owns it leaves the team, or the person who accepted the automation loses access to the team, the automatic run turns off and its link to the workflow is removed. If the same pattern is observed again later, the suggestion can come back.

A team scheduled run created this way can’t have “what it does” (the saved workflow) changed from the scheduled run edit screen. To change what it does, edit the team’s saved workflow itself; the run time can still be changed there like any other scheduled run.

How an automatic run plays out

  [Registered scheduled run]
       │
       │ Run time arrives
       ▼
   Employee wakes up automatically
       │
       │ Picks tools and does the work
       │ (only tools you've already enabled are available)
       ▼
   Drops the result into chat
       │
       │ ┌──────────────────────────────┐
       └▶│  Push notification fires     │
         │  Open the chat to read it    │
         └──────────────────────────────┘

The result lands in your chat exactly like a normal message would. The message is tagged with which scheduled run woke the employee and what instruction it was given, so you can tell a scheduled answer apart from your own back-and-forth, even days later.

Where do I see the result?

• In chat: the answer arrives as a new message. A “Started by scheduled run” tag and the original instruction are shown alongside it.
• Push notification: if mobile / desktop notifications are on, you get a ping when the result lands. Tap it to jump straight to the chat.
• Automatic runs menu: each scheduled run card shows the total run count and next run time. For the last run time, check the run history below.
• Run history: the employee’s Logs menu (/agents/<employee>/logs) shows scheduled run records (success/failure, timestamp). Note that the Logs view currently shows the run history of the first scheduled run in the list only. To review a specific scheduled run’s history in detail, open it directly from the Automatic runs menu.
• Scheduled run timeline in Home and team screens: below the employee table in Home, and at the bottom of the Scheduled runs tab on each team’s detail screen, every visible employee gets its own row on a shared timeline. In Home it starts collapsed, so click its title (Scheduled run timeline) to expand it (the expanded state is remembered in this browser). Centered on “now,” a filled dot marks a time in the last 24 hours when that employee actually ran, and a hollow ring marks its next scheduled run within the coming 24 hours, so you can scan when a whole group of employees has run and is about to run, in one glance. Click a row to expand that employee’s scheduled runs right there and add or edit them.

Safety rails

Because automatic runs spend SU (AI usage unit) while you’re away, several guardrails are in place:

A scheduled run can only use tools you already enabled, and Approval Required tools stay frozen until you approve them in person. Your employee works inside the limits you set ahead of time.

Common patterns

Daily morning briefing

Get news / stock / inbox summaries at a fixed time each day. Wake up, open the chat, done.

Watch + alert only on change

“Check this page every hour and alert me only if the price moves.” Quiet by default, loud only when it matters.

Periodic cleanup

Run heavy weekly summaries or data cleanup early Sunday morning so they don’t fight with your weekday work.

One-off delayed run

“Come back in an hour and recheck this.” Ask in chat, or set it up yourself from “Add scheduled run → Once” by picking a date and time. Once it runs, the scheduled run deactivates itself. It won’t fire again and you don’t have to clean it up.

Next steps

• Equipping Tools: pick the tools your employee will use while you’re away
• Skills & the Autonomous Skill System: package repeated work into a skill for more reliable automation
• Sharing an AI Employee Externally: how the public version outside visitors chat with differs from your own scheduled runs

Advanced

You don’t need any of this for normal use. Skip unless you want fine timing control or are debugging odd behavior.

Scheduled run types

Self check-in is separate from this table. It’s a single always-present automatic run per employee, toggled at the top of the page, and it’s never created via “Add scheduled run”.

The “Add scheduled run” button in the UI supports both Repeat (fires a fixed request on a set day/time or interval) and Once (fires once at a time you pick), both different from the self-pacing self check-in. The UI’s repeat rule is limited to two shapes (“a day/time, once” or “a fixed interval, all day”), so anything more precise (minute-level timing, or an interval restricted to certain hours) requires asking the employee in chat, which registers it using its scheduling tool with a standard cron expression.

One-time vs recurring

A one-time run deactivates itself after it fires. A recurring run keeps going until you stop it, but whether it auto-expires depends on how it was created:

• A recurring scheduled run you asked the employee to set up directly in chat stays active indefinitely, with no expiration.
• A recurring scheduled run the employee registers on its own initiative (say, during a self check-in) auto-expires after 7 days by default, so forgotten scheduled runs don’t keep firing forever.
• Either way, if you specify a lifetime yourself (“just keep this for two weeks”), that value wins, up to 90 days.

Picking a time (cron expressions)

Under the hood, when the employee registers a cron scheduled run it uses standard cron notation. Times are stored in UTC and shown in your local timezone.

Asking in plain language (“run at 8 AM Korea time”) lets the employee handle the timezone conversion for you.

Concurrency protection

A single employee only ever has one execution line active.

• If scheduled run times overlap, or a previous run is still going when the next one’s time arrives, only one runs.
• If a run is in flight when the next slot comes due, the next slot is skipped or queued, never doubled.
• If the employee is busy with something else or waiting for your answer at the scheduled time, that slot is not dropped right away. It is retried shortly after (first after 1 minute, then at growing gaps of up to 15 minutes), but only within 1 hour of the scheduled time and before the next scheduled time. If it still can’t run, that slot is skipped.
• Even when multiple servers try to fire the same scheduled run at the same instant, the system ensures only one of them actually runs it.
• After a system restart, scheduled runs that were “due” while the system was down are realigned forward to a fresh future time and resume cleanly.

So no, your employee can never accidentally fire the same task 60 times in an hour.

When many employees share the same cron expression (e.g. 0 * * * *) they could otherwise all fire at the same instant. To spread that load, every employee-registered recurring (cron) scheduled run automatically gets up to 180 seconds of random delay added to its start time. This is automatic (there is nothing to configure), and it does not apply to one-time delayed runs.

What the Home and team timelines actually show

The scheduled run timeline at the bottom of Home and the team screens only ever shows a 48-hour window centered on now: 24 hours back, 24 hours forward.

• Each filled dot is one run (turn) that actually started at that time. If the same employee runs several times close together, the dots overlap and read as density.
• An employee with too many dots (e.g. one that runs every minute) has its oldest dots dropped, and that fact is shown as a ⋯ mark at the left edge of its row, so it’s never silently trimmed.
• A hollow ring is drawn once per active scheduled run, at its single nearest upcoming run. A next-run time that’s already in the past (not yet picked up, or pushed out by active hours) is never drawn as if it were still coming.
• If the next run is more than 24 hours out, the timeline only shows a ▸ arrow at the right edge to say “something’s coming, just outside this window”. It never invents a position for it.
• Self check-ins and condition watches share the same axis, distinguished by color.

How self check-in picks its next time

When self check-in is on, the employee recalculates the next check-in time every time a check finishes, based on two things:

• Anything already on the calendar: a delayed task waiting to run, or a new message/webhook that just came in, whichever comes soonest
• A minimum check-in cadence: by default, a full check-in is guaranteed at least once every 8 hours (up to 3 times a day)

The next check-in is set to whichever of those two comes first. If the employee decides there’s nothing worth checking right now, that only pushes the minimum-cadence floor later; it never pulls it earlier. The computed time is also always at least 15 minutes after the check that just finished. Active hours (your notification window) play no part in this calculation. Self check-in keeps running on its own timing outside those hours too; active hours only decide whether the result reaches you as an immediate push or waits until the window reopens.

When an automation cadence suggestion appears

• It’s judged from the employee’s own record of “I finished this kind of work” declarations, not from scheduled runs you registered in chat. A pattern needs at least 3 occurrences of the same kind of work before the check even runs, and it only looks at the most recent 8.
• It only fires for work that already has a saved way of doing it (a workflow) you previously approved. If the approach varies each time, running it unattended would produce inconsistent results.
• It only fires when the completion times clearly line up on a daily, weekly, biweekly, or monthly beat. If the times are scattered or the interval is ambiguous, it stays quiet rather than guessing at a cadence.
• It won’t suggest again if an active scheduled run already covers that same kind of work.
• The suggestion isn’t a separate card like the one shown when you ask for a scheduled run directly. It’s one short sentence tacked onto the end of the employee’s normal reply, and your answer in that same chat decides whether anything gets created.
• Work handed to a team is judged the same way (at least 3 occurrences, looking at the most recent 8 only), but as noted above it only fires when the team already has a saved workflow for that task type. Instead of a sentence at the end of a reply, it’s one item on the Next steps card shown when that work finishes. If the saved workflow is deleted, its owning employee leaves the team, or the person who accepted the automation loses team access, an already-active automatic run turns off and its link to the workflow is removed, so it never sits silently disabled; the suggestion can come back once the same pattern is observed again. A scheduled run created this way still counts against the absolute active scheduled run ceiling one employee can hold (max 20) and the same same-time duplicate check.

Limits and retention

Scheduled runs you create yourself from the UI are not subject to the active scheduled run cap, and they don’t auto-expire unless you set that yourself.