> ## Documentation Index > Fetch the complete documentation index at: https://learn.actionist.ai/llms.txt > Use this file to discover all available pages before exploring further. # Calendar and schedules > Review and adjust the recurring work a client's agents do, and get the time zones right when your client is in another country.

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](/Folders/schedules).

Inside the [Reseller mode banner](/resellers/view-as-client), 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.

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

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:

From the Calendar tab or the agent's Schedule tab, inside a delegated session for that client's workspace. 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. Change it explicitly. Ask the client if you are not certain, rather than guessing from their country. 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. 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.

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

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.

Check both switches: the schedule's own toggle, and the agent-level scheduling preference. Either one being off silently stops future runs. 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. 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. 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](/resellers/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](/Folders/oversight). For the event-driven side of automation, see [Triggers](/Folders/reactions).
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 Dashboard Signup 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.

The full builder reference: recurrence, stop rules, and the calendar view outside a delegated session. Approval modes and blockers in full, including what counts as a risky tool call. What else changes on an agent record once you are inside a client workspace. Every message you can hit in a session, what it means, and whose problem it is.