Schedules & Triggers API

The same field is available on the create_agent_schedule and update_agent_schedule MCP tools; passing null on an update stops delivering. Leave it unset and nothing changes. The schedule form in the UI has no field for it.

• Where it lands. In that person's Main chat with the agent — the one constant conversation per person per agent. It reads like any other message from the agent, and it can be rated like one.
• Who you can name. Someone the agent is already shared with, or its owner. If the address cannot reach the agent — never shared, share revoked, blocked, or simply unknown — the run fails and says so on the execution row rather than running and quietly delivering nowhere. A malformed address is rejected when you save the schedule, not hours later on the first fire.
• Who can set it.You can always name yourself. Naming anyone else takes the agent's owner or an admin — on create and on update alike. Clearing the address is never restricted.
• When it shows up. The message is saved as soon as the run finishes, but the Workspace does not poll a conversation you already have open, so it appears the next time that person loads the Workspace or switches to the chat. It also avoids cutting into a turn already in progress in that chat: it waits up to two minutes for that reply to finish, then writes regardless.
• Delivered once. Each fire delivers at most one message, even if the platform has to retry internally.
• Rateable. The delivered message is an ordinary reply from the agent, so the person can rate it like any other — see Workspace.

• Execution flow. The scheduler fires and sends a POST to /api/internal/execute-task with async_mode=True; the backend spawns a background task and returns immediately; the scheduler polls the database every 10 seconds until the execution completes and the record is updated with response, cost, and duration.
• Misfire handling. If the scheduler restarts, missed jobs within a 1-hour grace window are caught up and fired immediately (misfire_grace_time=3600, coalesce=True, max_instances=1). Missed jobs outside that window are not caught up.
• Autonomy gate.Nothing fires while the agent's autonomy is off. It is a gate, not a bulk edit — each schedule keeps its own enabled/disabled state across the toggle.
• Capacity. Parallel execution is controlled by per-agent capacity slots (default 3); retries count against those slots. Execution timeout is per-agent configurable (default 60 minutes, max 2 hours).
• Per-schedule timeout. Creating or updating a schedule with timeout_secondsabove the agent's cap returns 400 error=schedule_timeout_exceeds_agent_cap; lowering the agent cap below an active schedule's timeout returns 400 error=agent_timeout_below_active_schedules. Raise the agent cap first, then the schedule timeout.
• Retries. A failed execution (error or timeout) retries after retry_delay_seconds while attempts remain; rate-limit errors (429) use 2x delay, capped at 300 seconds. Each retry is a new execution record linked to the original via retry_of_execution_id with an attempt_number; a failed run waiting to retry has status pending_retry.
• Template limits. A template may declare at most 20 schedules; beyond that the list is truncated, with the reason reported. If the agent has freeze schedules if sync failing enabled and its git sync has failed three times in a row, the scheduler skips firing until sync recovers.