“Scheduling an agent” means two very different things, and mixing them up is the most common reason a daily automation quietly does nothing.
Key facts
| Fact | Detail |
|---|---|
| Question answered | How do I run an AI agent unattended on a schedule? |
| Short answer | Running an agent unattended needs four parts, not one: a trigger that starts the session, a written task description the agent can follow without asking questions, permission to execute commands without a huma… |
| Reading time | ~2 min |
| Last updated | 2026-09-26 |
The first is a time-triggered pipeline: at 10:00, run this command. Fetch, build, validate, deploy, write a log line. That is a script with a clock attached, and Windows Task Scheduler has done this job reliably for decades.
The second is a time-triggered agent session: at 10:00, wake up, read the current state, decide what this run needs, and do it. That is a different object. It can author new work, not just verify existing work.
The four parts
An unattended agent run needs all four of these:
- Trigger - what starts the session. A system scheduler, or the scheduler built into the agent product itself.
- Written task description - the run cannot ask you a question at 10:00, so the instructions have to be complete: what to read first, what the steps are, what to do on failure, what “done” means.
- Execution permission - a session that waits for an approval click is not unattended. Either the run is allowed to execute commands on its own, or it will sit idle forever.
- Deterministic guard - the replacement for your judgement. A small script that inspects the diff and refuses to proceed if the run touched anything it should not have.
Skip the fourth part and the automation eventually surprises you. Skip the third and it does nothing at all.
Why “success” can still mean “nothing happened”
A job can exit cleanly and publish nothing. The publish line in its log is the only thing that tells you which case you are in:
- review mode - validated and built, but deliberately stopped before deploying;
- mechanical-only pipeline - the job never had a step that authors content, because that step needs a model, not a script;
- guard blocked - the run was refused because the working tree was not in the expected state.
All three look like a green tick from the outside. If you are debugging a daily job, read its log rather than its exit code.
A sane rollout
Run in review mode first. After a few cycles, read the logs and check that the runs did what you expected. Then switch the same job to auto - keeping the guard in place. The guard is what makes it safe to stop watching; without it, every automatic run is a bet.
If you would rather drive the agent yourself and keep the schedule only for the mechanical parts, that is a perfectly good setup - just be clear about which half is automated, because that is the half that will keep working while you sleep.
MOOGH runs agent sessions on Windows: describe the task, review the plan, approve the steps, read the log afterwards. Get it from the official download page.
Related reading: