All Managed Agents API requests require the
managed-agents-2026-04-01 beta header. The SDK sets the beta header automatically.Create a scheduled deployment
When creating a deployment, you pass the session configurations required for execution, in addition to aschedule.
- Deployments require agent configuration and environment configuration, and optionally accept files, GitHub, memory stores, and vaults.
- Deployments also require at least one initial event, a
user.messageoruser.define_outcome, that starts each session’s work. - In the
schedule, you define a cronexpressionand atimezone. Maximum granularity supported is at the minute level.
schedule.upcoming_runs_at with the next upcoming fire times, to confirm your schedule was set correctly.
Cron and timezone semantics
- Expression: Standard POSIX cron (
minute hour day-of-month month day-of-week). You can generate and validate these cron expressions in the OMA Console. - Timezone: IANA timezone identifier (for example,
"America/Los_Angeles"). - DST: Cron schedules use literal wall-clock matching, so
"0 20 * * *"inAmerica/New_Yorkfires at 8PM local time regardless of whether EST or EDT is in effect.
Wall-clock times that do not exist on a spring-forward day (such as 2 AM) are not triggered. Wall-clock times that occur twice on a fall-back day fire twice. Schedule outside the 1–3 AM local window, or use UTC, when missed or duplicate executions are unacceptable.
Set a budget on each run
Pass the optionalbudget object when you create or update the deployment. It takes the same shape as a session budget. The deployment copies the cap onto each session it starts, so the budget bounds every run separately rather than acting as a cumulative ceiling across runs: a deployment with a "2000" cap can spend up to about $20 on every run.
A session started by the deployment behaves exactly like any other budgeted session: it pauses with budget_reached when its own list cost reaches the cap. Changing the deployment’s budget applies to runs started afterward; a session already running keeps the cap it started with, which you can change through the session itself. Unlike a session budget, a deployment’s budget can be removed with "budget": null and set again later.
The following example sets a budget on an existing deployment:
cURL
Deployment runs
Deployments can fail to trigger for a variety of reasons: for example, if theenvironment resource has been archived, or if session creation is rate-limited. Each attempt at executing a deployment generates a deployment run record, allowing you to track successes and failures independent of the session lifecycle.
Successful deployments generate active sessions, and a successful deployment run contains the associated session_id. To follow a session’s lifecycle, track the session events through the event stream or webhooks. Deployment lifecycle changes and the outcome of each scheduled run are also delivered as webhook events, listed in the Deployment events and Deployment run events tabs of Supported event types.
List all deployment runs for a deployment as follows:
error with a type describing why session creation was rejected (for example, environment_archived_error, agent_archived_error, or session_rate_limited_error). See the List Deployment Runs reference for all filter parameters and the response schema.
GET /v1/deployment_runs/{deployment_run_id}. A deployment_run webhook event carries the run ID as its data.id.
Managing deployment lifecycle
Each lifecycle change emits a webhook event, so you can react to a paused, unpaused, or archived deployment without polling; see the Deployment events tab. Pause suppresses scheduled triggers on a go-forward basis; running sessions from a prior deployment run continue to execute. Manual runs through therun endpoint are still allowed while paused. Pausing sets paused_reason to {"type": "manual"}; unpausing clears it.
Failure behavior
Session creation rate-limit responses are recorded immediately as asession_rate_limited_error run without retry; the schedule attempts again at the next scheduled occurrence. Rate limits on underlying API calls within a session are handled by the session itself.
If a deployment’s agent has been archived, the deployment is automatically archived in the same operation. If the agent has been deleted, the next scheduled trigger detects the missing agent and automatically archives the deployment. In both cases no deployment run is recorded. If a subagent referenced by the agent has been archived, the next trigger records a failed run with error.type: "agent_archived_error" and the deployment is automatically paused so you can update the agent and resume. Other unrecoverable session-creation errors, such as an archived environment or vault, behave the same way: the trigger records a failed run and the deployment is automatically paused. The deployment’s paused_reason.error.type mirrors the failed run’s error.type.
Trigger a manual run
To run a deployment outside its schedule, call therun endpoint. This creates a session immediately and writes a deployment run with trigger_context.type: "manual". This allows you to test a deployment before committing to the schedule.