Skip to main content
Open Managed Agents replaces your hand-written agent loop with managed infrastructure. This page covers what changes when you migrate from a custom loop built on the Messages API or from a local Agent SDK.
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.

From a Messages API agent loop

If you built an agent by calling messages.create in a while loop, running tool calls yourself, and appending results to the conversation history, most of that code goes away.

What you stop managing

Code comparison

Before (Messages API loop, simplified):
After (Open Managed Agents):

What you still control

  • System prompt and model: Same fields, now on the agent definition.
  • Custom tools: Still declared with JSON Schema. Execution moves from inline handling to responding to agent.custom_tool_use events. See Session event stream.
  • Context: You can still inject context through the system prompt, file resources, or skills.

From a local Agent SDK

If you built with a local Agent SDK, you’re already working with agents, tools, and sessions as concepts. The difference is where they run: the SDK runs in a process you operate, while Managed Agents runs in OMA’s infrastructure. Most of the migration is mapping SDK configuration objects to their API-side equivalents.

What changes

Code comparison

Before (Agent SDK):
After (Managed Agents):
The Agent and Environment are created once and reused across sessions. The tool function still runs in your process; the difference is that you read the agent.custom_tool_use event and send the result explicitly instead of the SDK dispatching it for you.

Features that move to your client

The tradeoff for OMA running the agent loop is that a few things the SDK handled automatically become your client’s responsibility.

Migration checklist

  1. Create an environment with the networking and runtimes your agent needs.
  2. Port your system prompt and tool selection to an agent definition.
  3. Replace your loop with sessions.create and sessions.events.stream.
  4. For any local files the agent reads, upload them through the Files API and mount them as resources.
  5. For any custom tool handlers, move execution into your event loop as responses to agent.custom_tool_use events.
  6. Verify with a test session before pointing production traffic at the new flow.

Migrating between model versions

When your deployment adds a new model, updating an Open Managed Agents integration is typically a one-field change: update model on your agent definition and the change takes effect on the next session you create.
Most model-level behavior changes documented in the Messages API migration guide do not require action on your side:
  • Request parameter changes (max_tokens defaults, thinking configuration) are handled by the Open Managed Agents runtime. These fields are not exposed on the agent definition.
  • Assistant message prefilling does not exist in the event-based session model, so its removal on newer models is a no-op.
  • Tool argument JSON escaping is parsed by the runtime before you receive agent.custom_tool_use events. You see structured data, not raw strings.
The behavior descriptions in the Messages API guide (what the model does differently) still apply. The migration steps (how to change your request code) do not.