Change, arm, pause or resume one workspace schedule.

Use it to move, rename, pause or re-arm any schedule: a one-off at a set time ("make the poem 2am"), a recurring job ("move the Monday runway to Tuesday") or an event job. To move a one-off, send the new run_after and a cron_expression that matches its time of day, together.

REQUIRED: schedule_id (from well_list_schedules or the result of well_create_schedule). OPTIONAL: name, routine_summary, cadence_label, status_report, instruction, restore_well_instruction, method_name, method_params, cron_expression, trigger_name, timezone, run_after, max_occurrences, ends_at, approved_tools, status, verified.

Send exactly one: cron_expression for a clock, trigger_name (from well_list_schedule_triggers) for an event. An event routine takes no run_after or max_occurrences.

ends_at (ISO 8601 with an offset) is the moment after which the routine stops: no run happens after it, and the schedule completes once it passes. Send null to remove the end. It is part of what the user signs off, like the rhythm.

status takes "paused" (stop admitting runs, keep the approval) or "active" (resume a paused schedule, or turn a disabled morning brief back on). The first approval of a brief that was never approved also turns it back on. An approved edit keeps it off, so send status "active" after it to turn it on. "active" never arms a draft. Send status on its own, without the other fields. To end a schedule for good use well_cancel_schedule. To skip a few days and let it carry on by itself, use well_snooze_schedule: a pause lasts until the user resumes it.

status_report ("on_error", "on_success", "both" or "none") is the message the user wants after a run. Changing only status_report needs no new yes and draws no card: send it on its own, without verified.

verified: true arms the schedule with any fields sent in the same call. In Well's chat it asks the user for approval: the schedule is armed, and a changed version runs, only after the user approves the confirmation card, and until then the stored schedule is unchanged. Anywhere else the fields are saved as a draft edit and nothing is armed. Only a call that arms a schedule (verified: true) asks the user for approval, through a confirmation card in Well's chat, and the schedule is armed only when the user approves it. Outside Well's chat no card can be drawn, so verified: true arms nothing there: the call saves the schedule as a draft, and the user arms it from Well's chat. Two creates arm at once with no card on every surface, because the ask is the yes and the run writes nothing: an agent's routine (agent_seat_id), and a weekly_missing_invoices_total routine of kind prompt on a cron that fires once a week, with no approved_tools. Saving or editing a draft, pausing, resuming and cancelling draw no card. Editing the routine_summary, the cadence_label, the instruction, the method, the rhythm, the time zone, the start, the end limit or approved_tools returns the schedule to a draft, which runs nothing until it is armed again. Two exceptions. The creator's own edit of a weekly_missing_invoices_total routine that still fits the rule above (kind prompt, a cron that fires once a week, no approved_tools) keeps it armed on the new clock, and arms it when it is a draft, with no card and with Well's own instruction for that job. Moving only the hour and minute of the user's active afternoon or EOD touchbase, on the same weekdays and with a new cadence_label, keeps it armed.

A morning brief's instruction is the person's to change. Send instruction and a new routine_summary on a card, with verified: true, after a yes. To go back to Well's own brief, send restore_well_instruction: true on its own, with verified: true, after a yes. Before the yes, say in one line that the person's words replace Well's brief.

A cron whose day-of-month and day-of-week fields are both restricted fires when either one matches. To tie a weekday to its nth occurrence in the month, leave day-of-month as * and write the weekday, then #, then n, in the day-of-week field. A clock routine is held on Sunday in the user's time zone by default. The morning brief is never held by the Sunday gate; its default cron runs on weekdays. For another routine, only an explicit choice lifts the hold: name Sunday in the day-of-week field when asked for Sunday or all seven days (0 alone or in a list or range; * does not name Sunday), save sunday_routines as receive, or set a one-off time. A meeting or Sunday habit does not lift the hold. A routine already scheduled for Sunday must have Sunday removed from its schedule to stop it; other routines already have the default hold. For a cron, two runs of a schedule must be at least 30 minutes apart, and the rhythm must fire at least once a year. A rhythm outside that range is refused, never adjusted: explain the rule to the user and let them choose a rhythm that keeps it.

The user never reads the instruction, the cron or a trigger name: the instruction is the detailed brief for the run, and a person does not read a contract. Show the user only the routine_summary, when it runs (with the status report choice) and the permissions, in plain words, and never paste the instruction, a cron expression or a trigger name into the chat. The confirmation card shows the same three things, built by Well from the stored schedule.

routine_summary and cadence_label are written for the user, in the language of the conversation, as plain text with no markdown. routine_summary says what will happen, and who or what outside Well each change reaches. cadence_label says when it runs. For a clock it says the rhythm in words and says the same thing as cron_expression: write both in the same call. Well computes the next run dates from cron_expression and shows them beside cadence_label, so a label that disagrees with the cron is visible to the user. For an event it says the event in plain words, such as "Each time a Qonto payment is matched to an invoice", and never the trigger_name. A call that changes cron_expression, trigger_name or timezone must also send a new cadence_label, and a call that changes the instruction or the method must also send a new routine_summary: a call without them is refused. Changing the timezone of a routine Well set up makes it stop following the person's profile time zone for good, so send timezone only when the person asks for another zone.

The result states status and next_run_at. Quote them to the user, and say the stored approved_tools in plain words, never as tool names.

WORKFLOW: for a change to the job, the rhythm, the end limit or the permissions, run the /schedule conversation again on the changed parts, show the user the routine_summary, when it runs and the permission list as they will stand, get an explicit yes, then call this tool once with the changed fields and verified: true. Exception: when the user moves their own active afternoon or EOD touchbase to another hour on the same weekdays, send cron_expression and cadence_label and omit verified. Any weekday or other change follows the approval flow above. A pause or a resume needs no approval.

The conversation that produces a good schedule (what the run needs, which jobs cannot run alone, the rhythm advice and the permission list the user signs off) belongs to the /schedule skill. Load it before proposing a schedule.

Do NOT use this to create a schedule (use well_create_schedule), to cancel one (use well_cancel_schedule) or to snooze one (use well_snooze_schedule). A scheduled run never changes a schedule, its own included.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.