How it runs itself on a schedule
A lot of the work in this portfolio happens without anyone asking for it. The Monday report, the nightly reflection, the morning shipment check: the assistant wakes itself up, does the job, and delivers the result. You set it once, and then it just happens.
A look under the hood: how an AI runs on a schedule with no human in the loop, and why the schedule survives a restart, a crash, or a deploy without ever being lost.
The short version
You say when: every Monday at nine, every night, every few hours. That schedule is saved, and an always-running part of the system checks the clock and fires each task the moment it's due. When a task fires, it spins up your own sealed environment, runs the assistant against the task exactly as if you'd typed it, and delivers the result to the right place. Then it works out the next run time and goes back to waiting. A scheduled task is really just a message the system sends to itself, on a timer.
That's the whole idea. The rest of this page is the shapes a schedule can take, and the thing that makes it trustworthy: it doesn't forget.
The loop that needs no one. A saved schedule comes due, the system wakes itself (green), runs the task in your own environment, and delivers the result. Same path a live message takes.
Three ways to say when
A schedule can recur, repeat on an interval, or fire once. Between them they cover everything from a nightly job to a one-off reminder to a follow-up that some other event kicks off.
A recurring schedule runs on a familiar calendar rhythm, weekday mornings, every Monday, nightly, always in your own timezone. An interval schedule runs every so often, every few hours, say. And a one-time schedule fires once at a chosen moment and then it's done, which is also how the system handles work that some event triggers: when something happens that needs a follow-up a bit later, it quietly queues a one-time task to handle it. A one-off that fails is retried a few times before it gives up, so a transient hiccup doesn't silently drop it.
It doesn't forget, and it doesn't double-run
The schedule is written down, not just held in memory, so it survives restarts, deploys, and crashes. Reboot the machine and every schedule is still exactly where it was. And each due task is claimed by one worker only, so it runs once, never twice.
This is the difference between a real scheduler and a script that runs until something knocks it over. Because the schedule lives in durable storage, nothing is lost when the system restarts, it comes back up and picks right up where it left off. A claiming mechanism makes sure that when a task is due, exactly one worker takes it, so you never get a double-sent report even across a restart. And a watchdog keeps an eye on the whole thing: a task that runs too long or is overdue gets surfaced for a human to look at, rather than stalling in silence.
Why you can rely on it. The schedule is saved to disk, not held in memory, so a restart, deploy, or crash doesn't lose it. It comes back and carries on (green).
It runs away from nothing
Automation that can misfire needs limits, and this has them. A recurring task that keeps failing is paused automatically instead of hammering forever. A one-time task retries a bounded number of times, then stops. Nothing loops out of control.
The point of an unattended system is that you don't have to attend to it, which only works if it's disciplined about failure. So there are budgets: if a scheduled job errors over and over, it's paused and flagged rather than left to keep erroring on every cycle; one-off jobs get a limited number of retries and then give up cleanly. Combined with the watchdog that surfaces anything stuck, the result is a system that runs itself for real, quietly doing the work when it should, and raising its hand when something's wrong instead of failing in the dark.
You set it once. It remembers forever, runs exactly when it should, exactly once, and tells you if something goes wrong. That's what 'runs itself' has to mean to be worth anything.