Skip to content

Scheduled tasks

Recurring work on a calendar, each execution in a fresh box, with a memory of what previous runs found.

Where
ScheduleIn the app (sign-in required), opens in a new tab.
Reading time
4 min read

How it works

A scheduled task is recurring work. Each execution gets its own box: the task's description is handed to the agent there (Claude Code, Codex or OpenCode) with the instruction to start implementing, and the box reports back as it goes. A task that has not reported itself started within 15 minutes, or finished within 60, is marked failed and an admin is told, a run that silently never happened is the failure this watchdog exists to catch.

Three kinds of task:

  • Run a prompt, a prompt, in a fresh box running Claude Code, Codex or OpenCode (the task's Agent choice; if that agent has no account that can run, the run goes to the other). It may name an info-only workspace, in which case the prompt goes into that workspace's box (and its agent), repos checked out and context to hand. That is what "audit this every Monday" is. Only an info-only workspace may be named: a scheduled prompt typed into a normal workspace's live session would interrupt whoever is working there, in a box that can push.
  • Send a task to an agent, the same dispatch, with the box booted as that persona and restricted to the tools you pick for this task.
  • Post a chat message, no box at all; a message into a workspace's chat on a schedule.

Frequencies are Once, Every day, Selected weekdays and Every N days.

Continuity

Scheduled work used to go nowhere, and the reason was structural: every execution got a brand-new box, the box was destroyed afterwards, the brief told the agent to treat the request as standalone, it carried no history, and nothing a run learned was written anywhere a later run could find. Run 1 and run 40 were the same run with a different date.

Continuity is the fix. A task publishes under subjects and reads them back: on every dispatch, DevBench assembles a "what previous runs of this task already established" section, the last few executions with their outcomes, and the documents they published with summaries and links, and folds it into the prompt. The closing line now says the opposite of what it used to: this is one execution of a recurring task, continue from what is above, and leave something the next one can continue from.

The Health view answers why a schedule is not accumulating anything, in plain language: seventeen runs and zero documents; continuity switched off; runs lost to a signed-out session; runs closed by the watchdog rather than reported. Consolidate folds a task's whole history into one digest document that supersedes the previous digest.

Steps

Following along? Tick each number off as you go.

  1. Open Schedule from Automate in the top bar (or the search: Ctrl Ctrl, ⌘ ⌘ on a Mac).

    Schedules is the list; Calendar is every schedule on the day it runs; Health says which schedules are not building on their past runs.

  2. Press New schedule.

  3. Pick what it does: Run a prompt, Send a task to an agent, or Post a chat message.

  4. For Run a prompt, choose the Agent that runs it, or leave it on the default.

    If that agent has no account able to run when the task fires, the run goes to the other agent instead, and the run's box says why.

  5. Write the description as you would brief a colleague.

    Acceptance criteria, links, background, this is the whole prompt the run gets.

  6. Choose the frequency and the time.

    Times are in your browser's timezone.

  7. For an agent task, pick the agent and tick the tools this task may use.

    An unticked tool does not exist for that execution.

  8. Set the subjects it publishes under, and leave continuity on.

    That is what makes run 40 different from run 1.

  9. Save it, then open Calendar and click a day to see what ran and open one run's transcript.

  10. Check Health occasionally.

    It names the schedules that are running and learning nothing, and why.

Worth knowing

  • A Run a prompt task (claude_prompt in the API) may only name an info-only workspace. The serializer refuses anything else at write time, and the scheduler refuses again at run time.

  • If the knowledge graph cannot be read, the briefing is skipped and the task still runs. A memory that fails is bad; a scheduled task that does not happen is worse.

Read next

AutomationAgentsNamed personalities, a system prompt, a set of specialties and the tools they carry, that you can mention in a chat or give recurring work to.Knowledge and filesDocs and the knowledge graphMarkdown documents with share links, filed under subjects and linked to each other, so a later reader, or a later scheduled run, can find them.Getting startedTasks for youAction items that need a person, as opposed to the workspace board, which is work for the agents.
Report a problem