Skip to main content
RECURRING WORK

​
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 permission

​
One toggle, two surfaces.

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.
The building blocks

​
What a schedule is made of.

Every schedule targets one agent task, and is either one-time or recurring. Recurring schedules add a frequency, an interval, and a stop rule.

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.
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.
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.
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.
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.
Read this section twice

​
Every schedule remembers its own time zone.

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.
On demand

​
Running one now.

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.

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.

Two switches, one checker

​
Enabling, disabling, and conflicts.

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.
In practice

​
How resellers actually use this page.

Agency owner, new client abroad
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.
one pass per client, no surprises
Diagnose in order

​
When a scheduled run looks stuck.

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.

For every other message you might hit in a delegated session, and whose problem it is, see Troubleshooting.

Not a schedule feature

​
What actually pauses a run for a human.

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.
Calendar and schedules

​
Recurring work, set to the right clock.

One scope, two surfaces, and one field that decides whether a client’s agents run on time or on yours.

Open the DashboardSignup as a Partner

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.

Keep going

​
Next steps.

Schedules

The full builder reference: recurrence, stop rules, and the calendar view outside a delegated session.

Oversight

Approval modes and blockers in full, including what counts as a risky tool call.

Agents, prompts and instructions

What else changes on an agent record once you are inside a client workspace.

Troubleshooting

Every message you can hit in a session, what it means, and whose problem it is.