What is the difference between a specific time and a random window?

timing_mode 'specific' fires at one exact scheduled_at time. timing_mode 'random' fires somewhere inside random_window_start to random_window_end, which looks more human and spreads load. Use random windows with a max_runs_per_day cap for anything recurring.

Can a schedule post content as well as run engagement?

Yes. run_type 'agentic_group' schedules engagement from a prompt, task, or device profile. run_type 'content_upload' schedules a multi-platform media post using platform_groups and files. Both support the same timing options.

How do I run a schedule immediately without deleting it?

Call run_schedule_now with the schedule id. It fires the same run the schedule would build at its next fire time, without changing the schedule. To pause or stop the active session, use stop_schedule.

Scheduling Runs

Create, edit, fire, and stop Conbersa schedules: one-off or recurring, fixed time or randomized window, with per-day caps and per-platform content.

A schedule is a run with a clock attached. You build it once, and it builds the same run at each fire time. It can run engagement or post content, at a fixed time or inside a window.

Anatomy of a schedule

Field	Values	Meaning
`name`	text	Label shown in the app
`run_type`	`agentic_group`, `content_upload`	Engagement or a media post
`schedule_type`	`once`, recurring	Fires once or repeats
`timing_mode`	`specific`, `random`	Exact time or a window
`timezone`	IANA, e.g. `America/New_York`	Timezone for the timing fields
`scheduled_at`	ISO timestamp	Used with `specific`
`random_window_start` / `_end`	times	Used with `random`
`max_runs_per_day`	integer	Cap on runs per day
`pad_ids`	list	Devices the run targets
`max_steps`	integer	Agent step cap for the run

Engagement schedules

For run_type="agentic_group", give one driving mode — exactly as start_run:

prompt_id — a saved template,
engagement — device-profile auto-apply per device (with optional platform),
task — free-form (with optional persona).

In plain language to an MCP agent:

Create a schedule called "Morning warmup" that runs my "Warmup — TikTok" prompt on these five devices every day at 9am America/New_York, capped at one run per day.

Content schedules

For run_type="content_upload", give platform_groups, files, content_type, and optionally caption and sound_url. The schedule stores the same structure an immediate content run uses. See Posting to multiple accounts.

If you omit a caption, it's backfilled from the first platform group, so single-platform schedules don't post blank captions. Set it anyway.

Timing that looks human

For anything recurring, prefer timing_mode="random" with a window and a per-day cap:

random_window_start / random_window_end — spread fire times across a range.
max_runs_per_day — stop runaway frequency.

Fixed times are fine for coordinated moments: a launch, a live event. Random windows are better for daily distribution, where regularity itself is a signal.

Managing schedules

list_schedules(status?, run_type?) — see what exists and when it next fires.
get_schedule(schedule_id) — inspect the full config.
edit_schedule(schedule_id, ...) — change only the fields you pass.
run_schedule_now(schedule_id) — fire it immediately, the same path as the app's Run now.
stop_schedule(schedule_id) — stop the active session and re-arm or finish the schedule.
delete_schedule(schedule_id) — remove it.

Best practices

Cap steps. Set max_steps per the engagement band (100–150 for recovery, 180–240 for lurk/full).
Start sparse. One run a day, then add more as you watch health.
Use saved prompts. Free-form tasks in a recurring schedule drift.
Check next_run_at after creating one, to confirm the timezone landed where you meant.

MCP workflows — scheduling as an agent prompt.
Tool reference — full arguments.