scheduled agent tasks

Scheduled agent tasks sound simple: tell an agent to review the open pull requests every morning, or to work through a small backlog overnight. The difficulty is that an unattended agent has no one to ask. It cannot pause to confirm that the card is still relevant, that its scope is still approved, or that the repository is in a state where editing is safe. A cron line that launches a CLI will happily start work on something you closed yesterday. The sensible design is therefore the opposite of fire and forget. Each scheduled task should be an explicit record: what to do, against which card, in which mode, at what time. Before it runs, something should check that the task is still eligible and still authorized. After it runs, the outcome should be recorded as a fact to inspect, not assumed to be success. This page lays out those pieces and how Liquid Brain handles them.

Why unattended agents need explicit tasks

When you work interactively, you supply judgment continuously. You notice when the agent drifts, you decline a command that looks wrong, you stop when the scope creeps. A scheduled run removes all of that, so the judgment has to be moved earlier, into the definition of the task. An explicit task names its target, its prompt, its timing and its mode. Review mode and work mode should be different things, because reading a closed card to audit it is harmless while editing files on that card is not. A good scheduler also has an opinion about missed runs. If the computer was off at the scheduled time, silently replaying the job hours later against changed files is usually worse than recording that it was missed and letting you decide. The design principle is that nothing happens implicitly, and everything that does happen leaves a record.

Readiness, authority and what a status really says

Two checks matter before execution. Readiness asks whether the work can start at all: is the card in a state that allows it, does it have the scope the mode requires, is there capacity to run it, are the protections it depends on in place. Authority asks whether this specific execution has been approved, which is a separate question from whether someone wrote a scope on a card. Writing down what you intend is not the same as permitting it. After the run, read statuses literally. A launched event means a process started. A process exit means it ended. Neither says the objective was met. Verified completion needs its own evidence, typically a check that ran and a person who looked at the result. Interrupted or unknown runs deserve a review before any retry, because a blind retry on top of a half finished change compounds the problem.

How Liquid Brain schedules work

Liquid Brain lets you schedule explicit review or work tasks, with readiness and authority checks before execution [C1c]. Authority is modeled separately from scope: a card edit does not automatically grant execution permission [N09]. Configured command guards and scope controls check the work against declared boundaries [C5]. The Desk must be running for the scheduler to execute, since it is not a background operating system scheduler, and creation, launch and process exit do not establish verified completion [C1c]. Outcomes and attempts are recorded with the work [C4], and operations are tracked with durable receipts, with stale edits refused rather than silently overwriting newer work [N10]. Backups restore with dispatch paused, so a restored workspace does not resume agents on its own [N05]. You still review results yourself before accepting them.

QUESTIONS

Will a scheduled agent task run if my computer is off?

Not in Liquid Brain. Scheduling needs the Desk to be running, and it is not a background operating system scheduler [C1c]. For any scheduler, decide in advance whether a missed run should be replayed or simply recorded for review, because replaying old work against changed files can cause more harm than skipping it.

What is the difference between review and work mode for a scheduled task?

Review inspects a card and reports, so it needs no edit scope. Work changes files, so it needs an explicit scope and passes stricter eligibility and authority checks [C1c]. Keeping them separate lets you automate reading with less risk than writing.

How do I know a scheduled task actually succeeded?

Do not rely on the process exiting. Check the recorded outcome and any verification evidence, then accept the work yourself. Liquid Brain records attempts and outcomes with the card [C4] and states that launch and exit do not establish verified completion [C1c].

RELATED GUIDES

• Cards vs scheduled tasks: what starts an agent?
• How to preview work with the Liquid Brain harness CLI
• How to read Liquid Brain reports and provenance

RELATED HARNESS PAGES

• evidence gates for AI work Evidence gates for AI work: separate proposed from approved execution, run checks, and record outcomes so acceptance rests on evidence.
• Claude Code project management Claude Code project management as a workflow: run Claude from project cards, schedule tasks and review results before you accept them.
• agent run history and reports Agent run history and reports: what to record about AI agent runs, how to read usage coverage honestly and where unknown differs from zero.