OpenAI hat am 10. September 2026 eine verwaltete Agents API angekündigt. Entwickler sollen damit Cloud-Agenten bauen und starten können. Laut offizieller Meldung nutzt der Dienst den Codex-Harness für Orchestrierung, langlebige Sitzungen und Werkzeugnutzung. Für Unternehmen verschiebt sich damit ein Teil der technischen Basis zum Anbieter – die Verantwortung für Prozessgrenzen, Rechte und Ergebnisse bleibt jedoch im eigenen Betrieb.
Der relevante Business Case ist nicht einfach ein Agent, der länger arbeitet. Wert entsteht erst, wenn eine Aufgabe über mehrere Schritte zuverlässig fortgesetzt, kontrolliert unterbrochen und nachvollziehbar abgeschlossen werden kann. Die Quelle bestätigt den Kernumfang, nennt in der vorliegenden Fassung aber keine Preise, Laufzeitlimits, Regionen, Servicezusagen oder Details zur Sitzungs- und Protokollverwaltung. Diese Punkte gehören deshalb als offene Prüfaufträge in jeden Pilot.
Was die Agents API bestätigt
Bestätigt sind zwei zentrale Aussagen: Die Agents API ist ein verwalteter Dienst zum Bauen und Starten von Cloud-Agenten. Zudem basiert sie auf dem Codex-Harness und unterstützt Orchestrierung, langlebige Sitzungen sowie Werkzeugnutzung. Daraus lässt sich ableiten, dass Teams weniger eigene Grundinfrastruktur für diese Funktionen entwickeln könnten. Wie groß diese Entlastung tatsächlich ist, muss aber gegen die vorhandene Plattform und den konkreten Prozess gemessen werden.
Build versus Managed: die eigentliche Architekturentscheidung
Ein eigener Agenten-Runner bietet maximale Kontrolle über Laufzeit, Zustände, Modelle, Speicher und Deployment, verlangt aber Entwicklung und laufenden Betrieb der Orchestrierung. Ein verwalteter Dienst kann diese Basis vereinfachen, schafft dafür Abhängigkeiten von Produktgrenzen, Preisgestaltung und unterstützten Integrationen. Die richtige Wahl hängt daher nicht nur von Entwicklungsgeschwindigkeit ab, sondern auch von Portabilität, Compliance, Fehlerkosten und notwendiger Kontrolle.
- Managed Service bevorzugen, wenn ein schneller Pilot und geringe eigene Orchestrierungsarbeit wichtiger sind als maximale Plattformkontrolle.
- Eigenen Runner bevorzugen, wenn spezielle Laufzeitregeln, Infrastrukturvorgaben oder Anbieterunabhängigkeit den Prozess bestimmen.
- Eine Mischform prüfen, wenn der Agent verwaltet laufen darf, sensible Daten oder folgenreiche Werkzeuge aber in einer eigenen Kontrollschicht bleiben müssen.
- Die Entscheidung mit identischen Aufgaben, Fehlerfällen und Kostenkategorien vergleichen statt nur mit einer erfolgreichen Demo.
Langlebige Sitzungen brauchen ein explizites Zustandsmodell
Eine lange Sitzung ist kein einzelner API-Aufruf. Sie kann warten, wiederaufgenommen werden, an einer Freigabe hängen oder nach einem Werkzeugfehler erneut starten. Unternehmen sollten deshalb Zustände wie geplant, laufend, wartend, freigabepflichtig, fehlgeschlagen, abgebrochen und abgeschlossen eindeutig definieren. Jeder Übergang benötigt einen Besitzer und eine erlaubte nächste Aktion.
Besonders wichtig ist die Behandlung von Wiederholungen. Wenn ein Agent nach einem Timeout nicht weiß, ob ein Werkzeug erfolgreich war, darf er eine Zahlung, Bestellung oder Nachricht nicht blind erneut auslösen. Werkzeugaufrufe sollten eindeutige Vorgangskennungen nutzen und möglichst idempotent gestaltet sein. Vor irreversiblen Aktionen gehört eine aktuelle menschliche oder regelbasierte Freigabe in den Ablauf.
Ein kontrollierter Pilot in sechs Schritten
- Einen eng begrenzten Prozess wählen, der mehrere Schritte benötigt, aber bei Fehlern nur geringe und rückgängig zu machende Folgen hat.
- Ein Zustandsdiagramm erstellen und für Pause, Wiederaufnahme, Abbruch, Zeitüberschreitung und Freigabe eindeutige Regeln festlegen.
- Werkzeuge nach Lesen, Schreiben und irreversibler Aktion trennen; der Pilot startet mit minimalen Rechten und kurzlebigen Zugangsdaten.
- Testfälle für Netzwerkausfall, doppelte Zustellung, abgelaufene Sitzung, fehlerhafte Werkzeugantwort und verweigerte Freigabe ausführen.
- Beobachtbarkeit prüfen: Aufgaben-ID, Eingabestand, Werkzeugaufrufe, Statuswechsel, Kosten und Endergebnis müssen einem Lauf zugeordnet werden können.
- Erst nach bestandenen Sicherheits-, Qualitäts- und Wiederanlaufgates einen kleinen Nutzerkreis freigeben und den Umfang schrittweise erhöhen.
Der Pilot sollte zunächst mit synthetischen oder minimierten Daten arbeiten. Externe Inhalte, Dokumente und Werkzeugantworten sind als nicht vertrauenswürdige Daten zu behandeln, nicht als neue Systemanweisungen. Damit wird verhindert, dass eine Anweisung in einem Ticket oder Dokument die vorgesehenen Rechte und Prozessregeln des Agenten überschreibt.
Qualität, Kosten und Betrieb gemeinsam bewerten
Für die Qualität zählen korrekt abgeschlossene Aufgaben, notwendige menschliche Korrekturen, Werkzeugfehler und Regelverstöße. Für den Betrieb sind Zeit bis zum Abschluss, Wiederanlaufrate, hängende Sitzungen, doppelte Aktionen und erfolgreiche Abbrüche relevant. Kosten sollten pro gelöstem Vorgang erfasst werden und Modellnutzung, Werkzeugdienste, Speicher, Infrastruktur sowie menschliche Prüfung enthalten.
Zusätzlich braucht das Team einen Portabilitätstest. Mindestens die Aufgabenbeschreibung, Werkzeugverträge, Zustandsdefinitionen und Evaluationsfälle sollten unabhängig vom Dienst dokumentiert bleiben. Das reduziert nicht jede Anbieterabhängigkeit, erleichtert aber eine spätere Architekturänderung und verhindert, dass kritisches Prozesswissen nur in einer Plattformkonfiguration steckt.
Abbruchkriterien vor dem Live-Betrieb festlegen
Ein Pilot sollte gestoppt oder zurückgesetzt werden, wenn Sitzungen nicht zuverlässig fortgesetzt oder beendet werden können, Werkzeugrechte überschritten werden, Aktionen doppelt ausgeführt werden oder ein Lauf nicht vollständig nachvollziehbar ist. Gleiches gilt, wenn offene Preis- oder Limitfragen keine belastbare Kostenobergrenze zulassen oder notwendige Datenschutz- und Aufbewahrungsvorgaben nicht verifiziert werden können.
Die OpenAI Agents API macht verwaltete Orchestrierung, langlebige Sitzungen und Werkzeugnutzung für Cloud-Agenten konkret evaluierbar. Der sinnvolle Einstieg ist dennoch kein breit berechtigter autonomer Agent. Ein enger Pilot muss zuerst beweisen, dass Zustände, Freigaben, Wiederanlauf und Kosten im eigenen Prozess beherrscht werden. Erst dann lässt sich entscheiden, ob der Managed Service eigene Infrastruktur sinnvoll ersetzt oder lediglich an eine andere Stelle verschiebt.