initial_events.
Managed Agents API requests require the
managed-agents-2026-04-01 beta header, except memory store endpoints, which use agent-memory-2026-07-22 instead. The SDK sets the correct beta header automatically. See Beta headers.Creating a session
A session requires anagent ID and an environment ID. Agents are versioned resources; passing in the agent ID as a string creates the session with the latest agent version.
Seed the session with initial events
You can create a session and start its work in one call.initial_events is an optional array of initial events to send to the session at creation, processed in order. It supports user.message and user.define_outcome events, and accepts a maximum of 50 events. A non-empty list starts the agent loop in the same call: the session is created directly in the running status, with no further request.
The following example creates a session with a single user.message in initial_events:
user.tool_confirmation, user.tool_result, and user.custom_tool_result) aren’t accepted because no agent turn exists yet, and user.interrupt isn’t accepted because there is no turn to stop. Unlike initial_events on a scheduled deployment, a session’s initial_events don’t accept system.message.
Each event in initial_events is validated and persisted before the create response returns, in list order, with a server-assigned ID, exactly as if you had posted it to the send events endpoint immediately after creation. Per-event content rules are also the same as on that endpoint. An empty list is equivalent to omitting the field. Validation is all-or-nothing: if any event fails validation, the whole request is rejected and no session is created.
The create request is rejected in the following cases:
A
user.define_outcome event in initial_events is accepted under the same conditions as sending one to an existing session; see Define outcomes.
Override agent configuration for a session
You can passagent in three forms: an agent ID string, a pinned-version object (type: "agent"), or an overrides object. The overrides form changes parts of the agent’s configuration for a single session. Use it to try a different model or grant an extra tool in one session without versioning the agent. For the overrides form, set type to agent_with_overrides and pass the agent’s id and optionally a version (omit version to use the agent’s latest version). Then include any of model, system, tools, mcp_servers, or skills with the values the session should use.
Each overridable field follows the same three rules:
- Omit the field: The session inherits the value from the agent version it references.
-
Set the field to
null, or to an empty array for list fields: The session runs with that field cleared. This rule applies in full tosystemandskills. There are three exceptions:modelis never clearable. A session always needs a model, somodel: nullreturns a 400agent_model_requirederror.- Clearing
toolsreturns a 400 error when the session’s effectiveskillsis non-empty, because skills require thereadtool. Otherwise,tools: nullandtools: []clear the field. - Clearing
mcp_serversreturns a 400 error when the session’s effectivetoolsstill contains anmcp_toolsetthat references one of the agent’s servers. Overridetoolsin the same request to remove thosemcp_toolsetentries, then clearmcp_servers.
-
Set the field to a value: The value replaces the agent’s value in full. Overrides never merge with the agent’s configuration, so a
toolsoverride must list every tool the session should have. There is one exception:- An
effortlevel inside a per-sessionmodeloverride isn’t applied, and because the override replaces the agent’smodelobject in full, the agent’s owneffortisn’t carried over either: a session created with amodeloverride runs at the model’s default effort level. To run at a specific effort level, setefforton the agent and don’t overridemodelfor that session.
- An
agent object reflects the configuration the session runs with after the overrides are applied. Its id and version still identify the agent and version the overrides are applied to. This lets you trace a session back to its base agent.
The following example starts a session that overrides the model and clears the system prompt:
Pin the inference geo for a session
Because amodel override replaces the agent’s model object in full, it also sets or clears the model’s inference_geo pin for the session: an override that includes inference_geo pins the geography that serves the session’s model requests, and one that omits it clears the agent’s pin so the session follows the workspace’s default_inference_geo. The overridden value is validated against the workspace’s allowed_inference_geos when the session is created.
The following example starts a session from an agent whose model has no geo pin, pins the session’s model requests to US inference by including inference_geo in the model override, and prints the value echoed in the response’s agent.model:
Set a session budget
To cap what a session can spend, pass the optionalbudget object when you create it. A budget is a hard ceiling on the session’s list cost: the platform prices everything the session consumes at public list rates, and the session stops issuing new model requests once that running total reaches max_list_cost. Set type to limit and give max_list_cost an amount and a currency. amount is a whole number of US cents written as a string, such as "2500" for $25.00; the API takes a string rather than a number so no floating-point rounding is ever applied. USD is the only currency currently supported. When the session reaches the cap, it pauses and goes idle with the stop reason budget_reached. The cap is enforced between model requests, so the request that crosses it finishes first and the session’s final list cost can land a fraction past the cap. A budget can only be attached at creation: you can change or remove it later, but you can’t add one to a session created without it.
The following example creates a session with a $25.00 budget; the response echoes the budget on the session resource:
cURL
MCP authentication through vaults
If your agent uses MCP tools that require authentication, passvault_ids at session creation to reference a vault containing stored OAuth credentials. OMA manages token refresh on your behalf. See Authenticate with vaults for how to create vaults and register credentials.
Starting the session
Creating a session withoutinitial_events registers the session but does not start any work; the environment’s sandbox begins provisioning as soon as the session is created, so the first tool call does not wait on it. To delegate a task, send events to the session using a user event. To supply the first event in the create request instead, see Seed the session with initial events. The session acts as a state machine that tracks progress while events drive the actual execution.
Next steps
Session operations
Retrieve, list, update, archive, and delete Open Managed Agents sessions.
Session event stream
Send events, stream responses, and interrupt or redirect your session mid-execution.
Scheduled deployments
Create and manage deployments with the OMA API: run an agent on a recurring cron schedule and inspect its run history.