Delayed Actions
The agent proposes deferred actions; the runtime owns timing, persistence, and safety re-evaluation at fire time.
Mental model
Delayed actions let the agent request that something happen later — a reminder, a deferred instruction, a job completion notification. The runtime owns delivery: the model proposes the schedule, but the runtime enforces timing, re-evaluates safety at fire time, and guarantees persistence across restarts.
The reader should picture delayed actions as a capability loaned to the agent by the runtime, not as a self-scheduling feature of the model. The model cannot time anything on its own; it can only ask the runtime to hold a call and release it later.
Why the runtime owns timing
If the model could schedule work on its own, you could never audit when a call would fire or revoke it without racing the clock. Putting the runtime in charge means (a) every scheduled action lives in persistent state you can inspect, (b) safety checks run at fire time against the current state of the world, not the state at schedule time, and (c) the operator can cancel, reschedule, or force-run from the dashboard.
The three kinds
REMIND_LATER
Deliver a pre-written reminder message to the user at a scheduled time. The model does not run; the runtime just sends the text.
Notification
RUN_LATER
Run the agent autonomously at a scheduled time with a pre-written instruction. A full tool loop executes.
Execution
NOTIFY_JOB_READY
Notify the user that a background job completed. Fired by the runtime when the job reports ready.
Follow-up
Scheduling and safety
The agent calls schedule_session_action with either a relative (delay_seconds) or absolute (ISO-8601 run_at) time. The runtime returns an action ID; the operator can cancel it later from the dashboard.
{
"action_kind": "remind_later",
"message": "Check the build status",
"delay_seconds": 3600
}{
"action_kind": "remind_later",
"message": "Daily standup reminder",
"run_at": "2026-04-11T09:00:00Z",
"cancel_on_user_activity": true
}Safety re-evaluation
- Every action is re-checked at fire time, not at schedule time. An action that was safe to schedule may become unsafe by the time it runs.
cancel_on_user_activitycancels the action if the user sends a message before the fire time.- Actions survive runtime restarts — persistent state lives in the workspace.