Scheduled Work for AI Employees: Time Zones, Late Starts and the Morning That Never Ran
A robot employee becomes genuinely useful when nobody has to remember to give it work. That is what regular tasks are for: instead of asking every morning, you attach a routine to a robot once and the system takes over. In the Firmspace Robot Office a routine is short — a sentence describing the job, a cadence and a time of day. The sentence is the whole task, so it is worth writing the way you would brief a new colleague: what to check, in which period, and what to do with the result.
A robot can hold up to five regular tasks, and each one has its own rhythm: every day, on working days only, on a chosen weekday, or once a month on a chosen date, always at a time you set. The blog robot that ships with the platform, for example, is configured to write one landing-page article every Monday and every Thursday at nine in the morning, saved as a draft for a person to publish. That is the pattern worth copying: a routine should produce something a human reviews, not something that goes out on its own.
The scheduler wakes up every minute and asks a simple question about each routine: is it due now? Answering that honestly turns out to be mostly a question about time zones, not about clocks. A firm has a country, and the country decides the time zone the routines follow — Germany uses Europe/Berlin, Ukraine uses Europe/Kyiv, Uzbekistan uses Asia/Tashkent. Nine in the morning means nine in the morning where the firm actually is, not where the server happens to run. Without that, a routine set by a Berlin firm would drift by an hour twice a year and eventually fire in the middle of the night.
Each routine remembers the date of its own last run, computed in the firm's time zone rather than in UTC — which matters, because the same UTC instant can be two different calendar days in two offices. A routine that has already run today stays quiet. This single field is what turns a per-minute check into a once-a-day event, and it is the reason the same routine does not fire again after a server restart later in the afternoon.
The interesting case is what happens when the server was unavailable at the appointed hour. The system does not simply drop the day. A routine may still start up to six hours late, which covers a restart, a short outage or a deployment. Beyond that window it is skipped, and the day is left behind rather than replayed. The choice is deliberate: a morning briefing delivered at eleven at night is noise, and a payment reminder sent long after the moment it belonged to is worse than one that waits for tomorrow.
There is one more ordering rule, and it shows which risk the designers feared most. Before a routine's task is created, the routine is marked as already run for today. If anything fails in between, the result is a missed day, not a repeated one. Running the same job twice creates two identical customer e-mails or two identical orders, and that kind of damage is visible to the outside world; a skipped day is usually invisible and can be run by hand. The system prefers the failure you can fix quietly, and it writes the reason into the row rather than leaving a mystery.
When a routine does fire, everything that follows behaves like any other hand-made request. The task lands in that robot's own queue, one task at a time, with other robots continuing in parallel. The same skill limits apply, and the same mode applies: in the asking mode every change the robot proposes waits for your approval, while in the automatic mode it acts and reports. A routine changes when work starts — it does not quietly widen what the robot is allowed to do.
It is worth being clear about the cases where nothing happens at all, because they are silent by nature. The automation section has to be part of the firm's plan, the firm must not be blocked, and the robot itself has to be switched on; the task is also subject to the plan's daily AI limit, and a robot that only watches the platform never takes tasks. If any of those conditions is not met, the scheduled moment simply passes. No error appears on your screen, no message arrives, and the morning looks like any other morning that had nothing scheduled. That is the honest risk of automation on a timer.
The way to live with that risk is not to trust the schedule but to look at the record. Each run leaves a task with its own text, source, timestamps, status and the list of actions it performed or proposed. Checking that list is a thirty-second habit, and it answers the only question that matters: did the thing I set up actually run, and what did it touch? A routine that has not produced a task for three days is a fact you can see, whereas a routine you merely believe in is a fact you cannot.
This is the real reason scheduled work suits a small firm so well. The instructions are not sophisticated. Review yesterday's leads. List invoices that are overdue or about to fall due. Remind the team on Monday about quotes that went quiet. Report on stock that is running low. None of it is clever, all of it is forgettable, and forgotten work is exactly what leaks out of a small business. Handing it to a robot on a timer does not make the work smarter — it makes it happen, and leaves a record that it happened.