Their agents run on a clock. Make sure it’s the right one.
With Calendar & Schedules granted, you can see and adjust the recurring jobs a client’s agents run, run one on demand, and untangle a run that looks like it never happened. Almost every mistake here traces back to one thing: a time zone nobody checked.
The client grants this from their Manage Reseller panel as “Allow reseller to manage Calendar & Schedules”, described to them as: “View and edit scheduled agent runs, recurring jobs, and calendar-connected workflows on this workspace.” In the scope enum it is calendar_and_schedules.
The top-level Calendar tab. A workspace-wide view across every agent on that client’s account, unlocked by this scope alone.
The Schedule tab in Agent Studio. The recurring-run settings for one specific agent, opened from inside that agent’s record.
The Schedule tab has a second requirement. Agent Studio itself only opens with prompts_and_instructions, so a session holding calendar_and_schedules alone reaches the top-level Calendar tab but not the per-agent Schedule tab. Without prompts_and_instructions, Agent Studio renders as a disabled form and every tab inside it, Schedule included, is unreachable.
Without this scope, both surfaces show the same locked panel: “Access restricted”, then “The client hasn’t granted access to Calendar & Schedules in this delegated session.” An agent asked to touch its own schedule during that session refuses the same way: “Permission denied: reseller delegated session does not include calendar_and_schedules access.”
This page is the reseller-specific view of scheduling. For the full mechanics of the calendar and schedule builder outside a delegated session, see Schedules.
Inside the Reseller mode banner, this permission shows up as a short Calendar chip, alongside Prompts, Tools, Skills, Memories, Files, Chat History and Billing. If Calendar is missing from that list, this permission was not granted for the session you are in, whatever the Manage Reseller panel shows on the client’s side.
Every schedule targets one agent task, and is either one-time or recurring. Recurring schedules add a frequency, an interval, and a stop rule.
Property
What it sets
Target
The agent task this schedule fires. Every schedule belongs to exactly one agent.
Type
One-time, or recurring.
Frequency (recurring only)
One of six: Minutely, Hourly, Daily, Weekly, Monthly, Yearly.
Interval
A multiplier from 1 to 365 applied to the frequency, for example every 2 weeks or every 90 days.
Weekly detail
Day-of-week chips, for schedules on a Weekly frequency.
Monthly detail
A single day-of-month, for schedules on a Monthly frequency.
Stop rule
Never, on a specific date, or after a set number of occurrences.
One-time versus recurring
A one-time schedule fires once, at the date and time you set, and is done. A recurring schedule keeps firing according to its frequency and interval until its stop rule ends it.
The six frequencies and the interval
Minutely, Hourly, Daily, Weekly, Monthly, and Yearly all take the same interval field, a multiplier from 1 to 365. An interval of 1 means every unit, an interval of 3 on a Daily frequency means every three days.
Weekly and monthly specifics
A Weekly schedule needs at least one day-of-week chip selected, and can select several, so “every Tuesday and Thursday” is one schedule, not two. A Monthly schedule takes a single day-of-month instead.
The three stop rules
Never keeps a recurring schedule running indefinitely. On date ends it after a specific calendar date. After a number of occurrences ends it once it has fired that many times, whichever comes first if combined with other settings.
Editing one occurrence of a series
Change a single occurrence of a recurring schedule and you are prompted for scope before the edit applies: this occurrence, this and following, or all occurrences. Picking the wrong one is the easiest way to silently reshape a series a client is depending on, so read the prompt before confirming.
Time zone is not an agent setting and there is no working-hours field anywhere. It lives on the schedule, and only there. A schedule fires from the zone stored on it, whoever happens to be looking at it, and whatever zone that person is sitting in.
Schedule · Weekly client report
Target
Maya · Send weekly report
Frequency
Weekly, every 1 week, on Monday
Time zone
America/New_York
Runs at 9:00 AM in America/New_York. That’s 2:00 PM in your time zone (Europe/London).
A schedule’s time zone defaults to whatever system time zone you are on when you create it, not the client’s. If you open a delegated session and build a schedule for a client on the other side of the world without touching the time zone field, it will fire on your clock, not theirs. This is the single most likely mistake a reseller makes on this page, and it is entirely avoidable: always set the zone explicitly.
Setting a client schedule correctly, from another country:
Open the schedule
From the Calendar tab or the agent’s Schedule tab, inside a delegated session for that client’s workspace.
Find the time zone field
It will already show a value, almost always your own system zone if this is a new schedule. Do not assume it matches the client.
Set it to the client's zone
Change it explicitly. Ask the client if you are not certain, rather than guessing from their country.
Read the cross-zone warning
When the schedule’s zone differs from yours, the amber line spells out both times side by side. Confirm the client-facing time is the one you meant to set.
Save, and check back once
After the first run, the run history confirms the actual fire time. That is your proof the zone was set correctly, not just entered correctly.
Run now lives on the Schedule tab inside Agent Studio, next to the specific schedule you are looking at. It is not available from the top-level Calendar list, so testing a schedule means opening the agent it belongs to.
State
What you see
Schedule enabled
Run now is clickable
Schedule disabled
Run now is greyed out, tooltip “Enable this schedule to run it manually”
Run starts
Toast “Scheduled run started”
Run fails to start
Toast “Could not start this scheduled run”
Run now is a real run, not a preview or a dry run. It executes the agent task exactly as the schedule would, with every action it takes actually happening. Use it to confirm a schedule fires correctly, not as a safe way to inspect one.
A reseller holding calendar_and_schedules can click Run now in a delegated session the same way the client can in their own workspace.
There are two independent switches that stop a schedule from running, and one checker that stops two schedules from colliding.
The per-schedule switch. Disabling one schedule stops future occurrences from being computed. What happens to a run already in flight at the moment you flip it is not documented, so do not state one way or the other if asked.
The agent-level scheduling preference. One setting on the agent itself, whose hint reads “When disabled, all scheduled jobs for this agent are paused.” Flipping this pauses every schedule that agent owns at once, without touching their individual settings.
Conflict checking runs live while you build a schedule, before you save it, and it is scoped to the agent. Two schedules for the same agent that overlap trigger a conflict banner and block the save. Two schedules for different agents can occupy the exact same slot with no warning at all, because each agent runs in its own lane.
The conflict window is based on the schedule’s duration, not just its start time. A schedule with an under-set or missing duration can look free when it actually overlaps a real run, so a duration that is too short can hide a genuine clash rather than prevent one.
Sets up a client’s first weekly report schedule from a delegated session, catches that the time zone field is still on their own city, and changes it before saving. Checks back after the first run to confirm the fire time in the client’s local clock.
the one habit that avoids most tickets
Support engineer, “it didn’t run”
Opens View as client, works the four-step diagnostic below in order, finds the schedule enabled but the agent hosted on a machine that was asleep at the scheduled hour, and tells the client to move that agent to a cloud placement.
found on step three, most times
Account manager, monthly review
Opens the Calendar tab across a client’s agents, uses Run now on a schedule that looked idle to confirm it still works, and tightens an interval that had been firing more often than the client actually needed.
Work through these four checks in order. Most “it didn’t run” reports resolve on the first two.
Is the schedule enabled
Check both switches: the schedule’s own toggle, and the agent-level scheduling preference. Either one being off silently stops future runs.
Does Agent Studio → Runs show a row at all
No row for the expected time means the schedule never fired. A row that exists but shows no useful result means it fired, and the instructions themselves were the problem, not the schedule.
Where does the agent run
An agent hosted on someone’s own machine only fires while that machine is awake and online. A machine that sleeps or shuts down stops every schedule tied to it. An agent on a cloud placement keeps firing regardless.
Check the time zone
The schedule fires in its own stored zone, not yours and not necessarily the client’s either. A run that “never happened” has often already happened, just not when someone expected.
A related but separate wrinkle: the Schedule tab inside Agent Studio is itself headed “Scheduled runs” in the interface, but it lists the configured schedules, not their execution history. For the history itself, go to Agent Studio → Runs. Each row there records its source, so a scheduled firing is distinguishable from one you started manually with Run now.
What you see
Likely cause
What to check
No row in Agent Studio → Runs at the expected time
The schedule never fired
Both enable switches, then the stored time zone against the expected local time
A row exists but the result is empty or wrong
It fired, the instructions or a tool call failed
The agent’s Instructions and Soul, and any recent tool or connection change
It always fires hours off from expected
Time zone mismatch, most often defaulted to the creator’s zone
The schedule’s stored time zone, compared to the cross-zone warning line
A schedule silently stopped recurring
It hit its stop rule, or the agent-level preference was flipped off
The stop rule (On date or occurrence count), and the agent’s scheduling preference
Save is blocked with a conflict banner
Another schedule on the same agent overlaps this one
The other schedule’s time and duration, not just its start time
For every other message you might hit in a delegated session, and whose problem it is, see Troubleshooting.
Approvals have nothing to do with schedules. Two separate things can stop an unattended run and wait for a person, and neither one lives on the Calendar or Schedule tab.
The agent’s approval mode
If a scheduled run triggers a tool call the agent’s approval mode requires sign-off for, it waits on that approval exactly as it would in a live chat.
This is set per agent, not per schedule, so it applies the same way whether the run started on a timer or with Run now.
A blocker
An agent files a blocker when an unattended run hits something only a person can fix, such as a missing credential or a broken connection.
Blockers surface under Needs attention. In a live chat, the same situation just prompts the agent to ask you directly, since you are already there.
Event-driven automation is a different feature entirely, called Triggers, and it is not covered here. For the full story on approval modes and blockers, see Oversight. For the event-driven side of automation, see Triggers.
If a client asks why their agent “waited for someone” overnight, the schedule itself is almost never the cause. Check the agent’s approval mode first, then Needs attention for an open blocker, before you go anywhere near the Calendar tab.
Scoped by one permission, enforced on the server, checked for conflicts before it ever saves.
Stored zone decides the fire time · Run now is a real run · Approvals and blockers are separate from schedules.
