Drei große SDK-Releases in zehn Tagen. OpenAI hat sein Agents SDK zwischen dem 23. Januar und dem 13. Februar 2026 von v0.7.0 auf v0.9.0 gebracht. Verwaltetes MCP-Server-Lifecycle, Human-in-the-Loop-Freigaben und ein verfeinertes Agent-as-Tool-Muster sind die Kernänderungen. Diese Taktung ist keine reine Wartung. Hier versucht ein Framework, LangGraph und CrewAI einzuholen, bevor Unternehmen ihren 2026er-Stack festlegen.

Release v0.9.0 selbst bringt Function-Tool-Timeouts, einen ToolOutputTrimmer für Kontextmanagement und streicht Python-3.9-Support. Die eigentliche Geschichte spannt sich aber über den gesamten v0.7-bis-v0.9-Bogen: MCP-Server-Orchestrierung, komponierbare Multi-Agent-Muster und die Infrastruktur, die aus einem “leichtgewichtigen SDK” etwas macht, das tatsächlich in Produktion laufen kann.

Was sich geändert hat, was es für Ihre Architektur bedeutet und ob das OpenAI Agents SDK für Ihr nächstes Projekt bereit ist.

MCPServerManager: Warum Server-Lifecycle-Management zählt

Vor v0.7 bedeutete die Anbindung eines OpenAI-Agents an mehrere MCP-Server: eigene Startup-, Health-Check- und Teardown-Logik schreiben. Der neue MCPServerManager ändert das mit zentralisierter Lifecycle-Steuerung für beliebige Kombinationen von MCP-Transporten.

So sieht das in der Praxis aus:

from agents.mcp import MCPServerManager, MCPServerStdio, MCPServerStreamableHttp

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

async with manager:
    # manager.active_servers enthält nur erfolgreich verbundene Server
    agent = Agent(
        name="orchestrator",
        mcp_servers=manager.active_servers,
    )

Drei Fähigkeiten stechen hervor:

Graceful Degradation. Bei drop_failed_servers=True (Standard) bringt ein ausgefallener MCP-Server nicht die gesamte Agent-Pipeline zum Absturz. Der Manager erfasst Fehler in failed_servers und errors, und Sie können reconnect(failed_only=True) aufrufen, um nur die defekten Verbindungen erneut zu versuchen. Für Produktionssysteme, in denen ein wackeliger Tool-Server nicht den gesamten Agenten lahmlegen soll, genau das richtige Verhalten.

Parallele Initialisierung. Mit connect_in_parallel=True starten alle Server-Verbindungen gleichzeitig. Wenn Ihr Agent fünf MCP-Server anbindet und jeder 2-3 Sekunden für den Handshake braucht, heißt sequentieller Start 10-15 Sekunden Wartezeit. Parallel reduziert das auf den langsamsten einzelnen Server.

Strict Mode für CI/CD. Setzen Sie strict=True und der Manager wirft beim ersten Server-Fehler eine Exception. Genau das wollen Sie in automatisierten Tests: sofort scheitern, wenn ein benötigter Tool-Server fehlt, statt die Lücke mitten im Agent-Run zu entdecken.

Weiterlesen: MCP und A2A Protokolle: Wie KI-Agenten mit Tools und untereinander kommunizieren

Fünf Transportoptionen, ein Interface

Das SDK unterstützt jetzt fünf MCP-Transporte über eine einheitliche API:

TransportEinsatzzweckLäuft wo
MCPServerStdioLokale CLI-Tools, DateisystemzugriffLokal
MCPServerStreamableHttpRemote-APIs, Cloud-DiensteHTTP-Endpunkte
MCPServerSseLegacy-SSE-Verbindungen (deprecated)HTTP-Endpunkte
HostedMCPToolVon OpenAI verwaltete AusführungOpenAI-Infrastruktur
MCPServerManagerOrchestriert beliebige KombinationÜberall

Die HostedMCPTool-Option ist besonders interessant: Sie lagert die Tool-Ausführung komplett an OpenAIs Responses API aus. Sie verweisen auf eine öffentliche MCP-Server-URL, konfigurieren Freigaberichtlinien und überlassen OpenAI die Verbindung. Der Haken: Ihr MCP-Server muss öffentlich erreichbar sein, was interne Tools hinter einem VPN ausschließt. Für deutsche Unternehmen mit strengen Netzwerkanforderungen ist das oft ein Ausschlusskriterium.

Agent-as-Tool: Komponierbare Multi-Agent-Systeme ohne Handoff-Chaos

Das Agent-as-Tool-Muster gab es schon vor v0.9, aber zwei Änderungen machen es deutlich praxistauglicher. Erstens gibt Agent.as_tool() jetzt einen FunctionTool statt dem breiteren Tool-Union-Typ zurück, was bedeutet, dass Type-Checker tatsächlich funktionieren. Zweitens ermöglicht der is_enabled-Parameter das bedingte Aktivieren oder Deaktivieren von Sub-Agenten zur Laufzeit.

So sieht das Muster aus:

research_agent = Agent(
    name="researcher",
    instructions="Finde relevante Daten und liefere strukturierte Zusammenfassungen.",
    model="gpt-5.1",
)

analysis_agent = Agent(
    name="analyst",
    instructions="Analysiere Daten und erstelle handlungsfähige Empfehlungen.",
    model="gpt-5.1",
)

orchestrator = Agent(
    name="orchestrator",
    instructions="Koordiniere Recherche und Analyse zur Beantwortung der Nutzerfrage.",
    tools=[
        research_agent.as_tool(
            tool_name="research_expert",
            tool_description="Findet und fasst relevante Daten zu jedem Thema zusammen.",
        ),
        analysis_agent.as_tool(
            tool_name="analysis_expert",
            tool_description="Analysiert Daten und erstellt Empfehlungen.",
        ),
    ],
)

Agent-as-Tool vs. Handoffs: Wann was passt

Das SDK unterstützt zwei Multi-Agent-Muster. Die falsche Wahl erzeugt Probleme, die sich später schwer beheben lassen.

Agent-as-Tool behält den Orchestrator in der Kontrolle. Der Sub-Agent läuft, liefert ein Ergebnis, und der Orchestrator entscheidet, was als Nächstes passiert. Der Nutzer sieht nur die Antworten des Orchestrators. Ideal, wenn Sie einen zentralen Koordinator brauchen, der Outputs von Spezialisten zusammenführt.

Handoffs übertragen die Kontrolle vollständig. Der ursprüngliche Agent tritt ab und der neue übernimmt das Gespräch. Passend für Kundenservice-Routing, wo jeder Spezialist den vollständigen Gesprächskontext und Autonomie braucht.

Die v0.9-Typverengung ist deshalb relevant, weil Agent-as-Tool-Aufrufe jetzt nahtlos mit Function-Tool-Pipelines zusammenarbeiten. Wenn Sie ein System bauen, in dem manche Tools einfache Funktionen und andere vollwertige Agenten sind, leben alle in der gleichen tools-Liste mit konsistenter Typisierung.

Weiterlesen: Multi-Agent-Orchestrierung: Wie KI-Agent-Teams tatsächlich funktionieren

Function-Tool-Timeouts und Context-Trimming

Zwei kleinere v0.9-Ergänzungen lösen echte Produktionsprobleme.

Konfigurierbare Timeouts

Vor v0.9 konnte ein langsamer Tool-Aufruf Ihren Agenten auf unbestimmte Zeit blockieren. Jetzt setzen Sie Timeouts pro Tool:

@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

Drei Timeout-Verhalten stehen zur Verfügung:

  • raise: Wirft eine Exception, stoppt den Agent-Run
  • error: Gibt einen modell-sichtbaren Fehler zurück, damit der Agent erneut versuchen oder umgehen kann
  • custom: Nutzen Sie timeout_error_function für maßgeschneiderte Behandlung

Für Agenten, die externe APIs aufrufen, ist error meistens die richtige Wahl. Das LLM erfährt, dass der Tool-Aufruf fehlgeschlagen ist, und kann selbst entscheiden: nochmal versuchen, gecachte Daten nutzen oder den Nutzer fragen.

ToolOutputTrimmer

Lange Tool-Ausgaben fressen das Kontextfenster. Der neue ToolOutputTrimmer bietet intelligente Kürzung, die die relevantesten Teile der Tool-Antworten bewahrt. Besonders nützlich, wenn Agenten Datenbanken oder Such-APIs abfragen, die große Ergebnismengen liefern.

Der v0.7-bis-v0.9-Release-Bogen: Was OpenAI aufbaut

Die drei Releases zusammen betrachtet zeigen OpenAIs Strategie:

v0.7 (23. Jan.): MCPServerManager eingeführt. Nested Handoffs auf Opt-in umgestellt. Standard-Reasoning-Effort für GPT-5.1/5.2 auf “none” gesetzt. Dieses Release war Infrastruktur und mehr Kontrolle für Entwickler.

v0.8 (5. Feb.): Human-in-the-Loop-Freigaben. Synchrone Tools auf Worker-Threads via asyncio.to_thread() verschoben. MCP-Fehlerbehandlung konfigurierbar gemacht. Hosted Container-Tools mit Shell-Runtime. Dieses Release war Produktionssicherheit: Agenten können für menschliche Freigabe pausieren, bevor sie sensible Aktionen ausführen.

v0.9 (13. Feb.): Function-Tool-Timeouts. ToolOutputTrimmer. Python 3.9 gestrichen. Typverengung bei as_tool(). Dieses Release war Developer Experience und Zuverlässigkeit.

Das Muster: Infrastruktur zuerst (v0.7), Sicherheitsschienen danach (v0.8), Feinschliff und DX zum Schluss (v0.9). Das ist die Sequenz eines Frameworks, das sich auf Enterprise-Adoption vorbereitet, nicht eines, das erst erkundet, was möglich ist.

Weiterlesen: KI-Agent-Frameworks im Vergleich: LangGraph, CrewAI, AutoGen

Wie das SDK im Vergleich zu LangGraph, CrewAI und AutoGen abschneidet

Die Framework-Landschaft im Februar 2026 hat klare Bahnen:

OpenAI Agents SDK ist die leichtgewichtigste Option. Ein funktionsfähiger Agent in unter 20 Zeilen Code. MCP-Support ist erstklassig. Der Kompromiss: enge Kopplung an OpenAI-Modelle (GPT-5.1, GPT-5.2, o3). Wenn Sie Claude oder Gemini einsetzen wollen, brauchen Sie Adapter-Code oder ein anderes Framework.

LangGraph (24.000+ GitHub-Stars, 4,2 Mio. monatliche PyPI-Downloads) bietet die meiste Kontrolle. Der graphbasierte State-Machine-Ansatz erlaubt exakte Ausführungspfade mit bedingtem Routing. Benchmarks zeigen, dass es die niedrigste Latenz und den geringsten Token-Verbrauch in standardisierten Tests erreicht. Die Kosten: eine steile Lernkurve. Nodes, Edges und State-Management verstehen, bevor der erste Agent steht.

CrewAI bleibt der schnellste Weg vom Konzept zum Prototyp. Das rollenbasierte Agent-Design bildet Geschäftsprozesse natürlich ab: ein Agent recherchiert, ein anderer analysiert, ein dritter schreibt den Bericht. Aber diese Einfachheit wird zur Einschränkung, wenn Sie feinkörnige Kontrolle über die Ausführungsreihenfolge brauchen.

AutoGen behandelt alles als Gespräch zwischen Agenten. Microsofts Rewrite 2025 machte es event-gesteuert, aber das Programmiermodell fühlt sich weiterhin anders an. Es glänzt bei Szenarien, in denen Agenten tatsächlich diskutieren und verhandeln müssen, etwa bei Code-Review-Workflows.

Wann das OpenAI Agents SDK die richtige Wahl ist

Greifen Sie zu, wenn:

  • Ihr Team bereits OpenAI-Modelle nutzt und den einfachsten Integrationspfad will
  • Sie MCP-Server-Orchestrierung brauchen, ohne sie selbst zu bauen
  • Ihr Multi-Agent-System dem Orchestrator-mit-Tools-Muster folgt
  • Sie schnelle Iteration über architektonische Flexibilität stellen

Schauen Sie sich Alternativen an, wenn:

  • Sie Modellportabilität über verschiedene Anbieter brauchen
  • Ihr Workflow graphbasierte State-Machines mit bedingtem Branching erfordert
  • Sie ein Framework mit größerem Ökosystem an Community-Tools und Integrationen wollen

Für Unternehmen im DACH-Raum kommt ein weiterer Aspekt hinzu: die HostedMCPTool-Option sendet Tool-Aufrufe über OpenAIs Infrastruktur. Je nach Datenklassifizierung und DSGVO-Anforderungen kann das ein Problem sein. Die selbst gehosteten Transportoptionen (MCPServerStdio, MCPServerStreamableHttp) umgehen das, erfordern aber eigene Infrastruktur.

Weiterlesen: Open-Source Agentic AI Stack: Agent-Infrastruktur selbst hosten

Breaking Changes: Was Sie für die Migration beachten müssen

Wenn Sie von v0.7 oder v0.8 upgraden, achten Sie auf Folgendes:

  1. Python 3.9 fällt weg. Das SDK erfordert ab v0.9 Python 3.10+. Python 3.9 hat End-of-Life erreicht, und OpenAI hat es gestrichen. Wenn Ihre CI/CD-Pipeline noch 3.9 nutzt, vorher aktualisieren.

  2. as_tool() gibt FunctionTool zurück, nicht Tool. Wenn Ihr Code as_tool()-Ergebnisse einer Variable vom Typ Tool zuweist, wird der Type-Checker das bemängeln. Die Lösung: Type-Annotation anpassen.

  3. Nested Handoffs sind Opt-in (seit v0.7). Wenn Sie auf automatische verschachtelte Handoff-History angewiesen waren, setzen Sie explizit RunConfig(nest_handoff_history=True).

  4. Sync-Tools laufen auf Worker-Threads (seit v0.8). Synchrone Function-Tools werden jetzt via asyncio.to_thread() ausgeführt. Wenn Ihre Tools von Thread-lokalem State abhängen, auf async migrieren oder Thread-Affinität explizit machen.

  5. openai v2.x erforderlich (seit v0.8). Das SDK unterstützt openai-Paket v1.x nicht mehr. Das ist die größte Migrationshürde für Teams mit umfangreichen Codebasen auf der v1-API.

Häufig gestellte Fragen

Was ist neu im OpenAI Agents SDK v0.9.0?

Version 0.9.0 fügt konfigurierbare Function-Tool-Timeouts (mit timeout_seconds, timeout_behavior und timeout_error_function), einen ToolOutputTrimmer für intelligentes Kontextmanagement und Typverengung bei Agent.as_tool() auf FunctionTool hinzu. Python-3.9-Support wird gestrichen. Das Release baut auf den Human-in-the-Loop-Flows von v0.8 und dem MCPServerManager von v0.7 auf.

Was ist der MCPServerManager im OpenAI Agents SDK?

MCPServerManager bietet zentralisiertes Lifecycle-Management für mehrere MCP-Server-Verbindungen. Er unterstützt parallele Initialisierung, Graceful Degradation bei Ausfällen (via drop_failed_servers), selektive Reconnection fehlgeschlagener Server und Strict Mode für CI/CD. In v0.7.0 eingeführt, funktioniert er mit allen fünf MCP-Transporttypen des SDK.

Was ist das Agent-as-Tool-Muster in Multi-Agent-Systemen?

Das Agent-as-Tool-Muster erlaubt einem Orchestrator-Agenten, spezialisierte Sub-Agenten als aufrufbare Tools via agent.as_tool() zu nutzen. Anders als bei Handoffs (die die Kontrolle übertragen) behält der Orchestrator die Gesprächshoheit und fasst Sub-Agent-Ergebnisse zusammen, bevor er dem Nutzer antwortet. Am besten geeignet für Systeme, in denen ein zentraler Koordinator Ergebnisse mehrerer Spezialisten zusammenführen muss.

Wie schneidet das OpenAI Agents SDK im Vergleich zu LangGraph und CrewAI ab?

Das OpenAI Agents SDK ist die leichtgewichtigste Option mit erstklassigem MCP-Support, am besten für Teams, die sich auf OpenAI-Modelle festgelegt haben. LangGraph bietet graphbasierte State-Machines mit der niedrigsten Benchmark-Latenz und dem geringsten Token-Verbrauch. CrewAI ist am schnellsten für Prototyping mit rollenbasiertem Agent-Design. Das SDK tauscht Modellportabilität gegen Einfachheit und enge OpenAI-Integration.

Ist das OpenAI Agents SDK DSGVO-konform einsetzbar?

Es kommt auf die Konfiguration an. Die HostedMCPTool-Option sendet Tool-Aufrufe über OpenAIs Infrastruktur, was bei sensiblen Daten DSGVO-Probleme aufwerfen kann. Die selbst gehosteten Transportoptionen (MCPServerStdio, MCPServerStreamableHttp) halten Daten in Ihrer eigenen Infrastruktur, erfordern aber eigenes Hosting. Für DACH-Unternehmen mit strikten Datenhaltungsvorgaben sind die Self-Hosted-Varianten die sicherere Wahl.

Titelbild von Florian Olivo auf Unsplash Source