OpenAI Agents SDK v0.9: Managed MCP, Agent-as-Tool, and What It Means for Your Stack

Three major SDK releases in ten days. OpenAI pushed its Agents SDK from v0.7.0 to v0.9.0 between January 23 and February 13, 2026, shipping managed MCP server lifecycle, human-in-the-loop approval flows, and a refined agent-as-tool pattern. That release cadence is not maintenance. It is a framework trying to catch LangGraph and CrewAI before enterprise teams lock in their 2026 stacks.

The v0.9.0 release itself adds function tool timeouts, a ToolOutputTrimmer for context management, and drops Python 3.9 support. But the real story spans the entire v0.7 to v0.9 arc: MCP server orchestration, composable multi-agent patterns, and the infrastructure glue that turns a “lightweight SDK” into something you can actually run in production.

Here is what changed, what it means for your architecture, and whether the OpenAI Agents SDK is ready for your next project.

MCPServerManager: Why Server Lifecycle Management Matters

Before v0.7, connecting an OpenAI agent to multiple MCP servers meant writing your own startup, health-check, and teardown logic. The new MCPServerManager changes that by providing centralized lifecycle control for any combination of MCP transports.

Here is what it does in practice:

from agents.mcp import MCPServerManager, MCPServerStdio, MCPServerStreamableHttp

manager = MCPServerManager(
    servers=[
        MCPServerStdio(command="npx", args=["-y", "@mcp/filesystem"]),
        MCPServerStreamableHttp(url="https://your-internal-api.com/mcp"),
    ],
    connect_in_parallel=True,
    drop_failed_servers=True,
    connect_timeout_seconds=30,
)

async with manager:
    # manager.active_servers includes only successfully connected servers
    agent = Agent(
        name="orchestrator",
        mcp_servers=manager.active_servers,
    )

Three capabilities stand out:

Graceful degradation. When drop_failed_servers=True (the default), a failed MCP server does not kill your entire agent pipeline. The manager tracks failures in its failed_servers and errors properties, and you can call reconnect(failed_only=True) to retry just the broken connections. For production systems where one flaky tool server should not take down the whole agent, this is the behavior you want.

Parallel initialization. Setting connect_in_parallel=True starts all server connections simultaneously. If your agent connects to five MCP servers and each takes 2-3 seconds to handshake, sequential startup means 10-15 seconds before your agent is ready. Parallel cuts that to the slowest single server.

Strict mode for CI/CD. Set strict=True and the manager raises an exception on the first server failure. This is what you want in automated testing: fail fast if a required tool server is missing, rather than discovering the gap midway through an agent run.

Five Transport Options, One Interface

The SDK now supports five MCP transports through a unified API:

The HostedMCPTool option is interesting because it offloads tool execution entirely to OpenAI’s Responses API. You point it at a public MCP server URL, configure approval policies, and let OpenAI handle the connection. The tradeoff: your MCP server must be publicly reachable, which rules out internal tools behind a VPN.

Agent-as-Tool: Composable Multi-Agent Systems Without Handoff Chaos

The agent-as-tool pattern existed before v0.9, but two changes make it significantly more usable. First, Agent.as_tool() now returns a FunctionTool instead of the broader Tool union type, which means type checkers actually work. Second, the is_enabled parameter lets you conditionally activate or deactivate sub-agents at runtime.

Here is the pattern:

research_agent = Agent(
    name="researcher",
    instructions="Find relevant data and return structured summaries.",
    model="gpt-5.1",
)

analysis_agent = Agent(
    name="analyst",
    instructions="Analyze data and produce actionable recommendations.",
    model="gpt-5.1",
)

orchestrator = Agent(
    name="orchestrator",
    instructions="Coordinate research and analysis to answer the user's question.",
    tools=[
        research_agent.as_tool(
            tool_name="research_expert",
            tool_description="Finds and summarizes relevant data on any topic.",
        ),
        analysis_agent.as_tool(
            tool_name="analysis_expert",
            tool_description="Analyzes data and produces recommendations.",
        ),
    ],
)

Agent-as-Tool vs. Handoffs: When to Use Which

The SDK supports two multi-agent patterns. Choosing the wrong one creates problems that are hard to fix later.

Agent-as-tool keeps the orchestrator in control. The sub-agent runs, returns a result, and the orchestrator decides what to do next. The user only sees the orchestrator’s responses. Use this when you need a central coordinator that synthesizes outputs from specialists.

Handoffs transfer control entirely. The original agent exits and the new agent takes over the conversation. Use this for customer support routing where each specialist needs full conversation context and autonomy.

The v0.9 type narrowing matters because agent-as-tool calls now integrate cleanly with function tool pipelines. If you are building a system where some tools are plain functions and others are full agents, they all live in the same tools list with consistent typing.

Function Tool Timeouts and Context Trimming

Two smaller v0.9 additions solve real production pain points.

Configurable Timeouts

Before v0.9, a slow tool call could hang your agent indefinitely. Now you can set per-tool timeouts:

@function_tool(timeout_seconds=30, timeout_behavior="raise")
def slow_api_call(query: str) -> str:
    return requests.get(f"https://slow-api.com/search?q={query}").text

Three timeout behaviors are available:

• raise: Throws an exception, halting the agent run
• error: Returns a model-visible error so the agent can retry or work around the failure
• custom: Use timeout_error_function for bespoke handling

For agents calling external APIs, the error behavior is usually the right choice. It lets the LLM know the tool failed and decide whether to retry, use cached data, or ask the user.

ToolOutputTrimmer

Long tool outputs eat your context window. The new ToolOutputTrimmer provides intelligent truncation that preserves the most relevant parts of tool responses. This is particularly useful when agents query databases or search APIs that return large result sets.

The v0.7 to v0.9 Release Arc: What OpenAI Is Building

Looking at the three releases together reveals OpenAI’s strategy:

v0.7 (Jan 23): MCPServerManager introduced. Nested handoffs made opt-in. Default reasoning effort for GPT-5.1/5.2 set to “none.” This release was about infrastructure and giving developers more control over agent behavior.

v0.8 (Feb 5): Human-in-the-loop approval flows. Synchronous tools moved to worker threads via asyncio.to_thread(). MCP failure handling became configurable. Hosted container tools with shell runtime. This release was about production safety, letting agents pause for human approval before executing sensitive actions.

v0.9 (Feb 13): Function tool timeouts. ToolOutputTrimmer. Python 3.9 dropped. Type narrowing on as_tool(). This release was about developer experience and reliability.

The pattern: infrastructure first (v0.7), safety rails second (v0.8), polish and DX third (v0.9). That is the sequence of a framework preparing for enterprise adoption, not one exploring what is possible.

How the SDK Compares to LangGraph, CrewAI, and AutoGen

The framework landscape in February 2026 has clear lanes:

OpenAI Agents SDK is the lightest-weight option. You can get a working agent in under 20 lines of code. MCP support is first-class. The tradeoff: it is tightly coupled to OpenAI models (GPT-5.1, GPT-5.2, o3). If you need to swap in Claude or Gemini, you will need adapter code or a different framework.

LangGraph (24,000+ GitHub stars, 4.2M monthly PyPI downloads) offers the most control. Its graph-based state machine lets you define exact execution paths with conditional routing. Benchmarks show it achieves the lowest latency and token usage across standardized tests. The cost: a steep learning curve. You need to understand nodes, edges, and state management before you write your first agent.

CrewAI remains the fastest path from idea to prototype. Its role-based agent design maps naturally to business workflows: one agent researches, another analyzes, a third writes the report. But that simplicity becomes a constraint when you need fine-grained control over execution order.

AutoGen treats everything as a conversation between agents. Microsoft’s 2025 rewrite made it event-driven, but the programming model still feels different from the others. It excels at scenarios where agents genuinely need to debate and negotiate, like code review workflows.

When to Choose the OpenAI Agents SDK

Pick it when:

• Your team already uses OpenAI models and wants the simplest integration path
• You need MCP server orchestration without building it yourself
• Your multi-agent system fits the orchestrator-with-tools pattern
• You value fast iteration over architectural flexibility

Skip it when:

• You need model portability across providers
• Your workflow requires graph-based state machines with conditional branching
• You want a framework with a larger ecosystem of community tools and integrations

Breaking Changes: What You Need to Migrate

If you are upgrading from v0.7 or v0.8, watch for these:

1. Python 3.9 is gone. The SDK requires Python 3.10+ as of v0.9. Python 3.9 hit end-of-life, and OpenAI dropped it. If your CI/CD pipeline still runs 3.9, update before upgrading.

2. as_tool() returns FunctionTool, not Tool. If your code assigns as_tool() results to a variable typed as Tool, your type checker will flag it. The fix is straightforward: narrow your type annotation.

3. Nested handoffs are opt-in (since v0.7). If you relied on automatic nested handoff history, set RunConfig(nest_handoff_history=True) explicitly.

4. Sync tools run on worker threads (since v0.8). Synchronous function tools now execute via asyncio.to_thread(). If your tools depend on thread-local state, migrate to async or make thread affinity explicit.

5. openai v2.x required (since v0.8). The SDK no longer supports openai package v1.x. This is the biggest migration hurdle for teams with large codebases built on the v1 API.

Frequently Asked Questions

What is new in OpenAI Agents SDK v0.9.0?

Version 0.9.0 adds configurable function tool timeouts (with timeout_seconds, timeout_behavior, and timeout_error_function parameters), a ToolOutputTrimmer for intelligent context management, and type narrowing on Agent.as_tool() to return FunctionTool instead of the broader Tool union. It also drops Python 3.9 support. The release builds on v0.8’s human-in-the-loop flows and v0.7’s MCPServerManager.

What is MCPServerManager in the OpenAI Agents SDK?

MCPServerManager provides centralized lifecycle management for multiple MCP server connections. It supports parallel initialization, graceful degradation when servers fail (via drop_failed_servers), selective reconnection of failed servers, and strict mode for CI/CD. Introduced in v0.7.0, it works with all five MCP transport types the SDK supports.

What is the agent-as-tool pattern in multi-agent systems?

The agent-as-tool pattern lets an orchestrator agent invoke specialized sub-agents as callable tools using agent.as_tool(). Unlike handoffs (which transfer control), the orchestrator retains conversation ownership and synthesizes sub-agent outputs before responding to the user. It works best for systems where a central coordinator needs to combine results from multiple specialists.

How does OpenAI Agents SDK compare to LangGraph and CrewAI?

OpenAI Agents SDK is the lightest-weight option with first-class MCP support, best for teams committed to OpenAI models. LangGraph provides graph-based state machines with the lowest benchmark latency and token usage. CrewAI is fastest for prototyping with its role-based agent design. The SDK trades model portability for simplicity and tight OpenAI integration.

Should I upgrade to OpenAI Agents SDK v0.9?

If you are on v0.8.x, the upgrade is low-risk. The main breaking change is dropping Python 3.9. If upgrading from v0.7 or earlier, plan for: sync tools running on worker threads (asyncio.to_thread()), nested handoffs being opt-in (set RunConfig(nest_handoff_history=True)), and the requirement for openai package v2.x.