OpenAI startet die Agents API – der Ausführungsort bleibt wählbar
OpenAI hat die Agents API am 10. September 2026 als öffentliche Beta für Entwickler gestartet. Der Dienst stellt den Agenten-Harness hinter Codex verwaltet bereit, lässt die eigentliche Ausführung aber in einer OpenAI-Sandbox, auf eigener Infrastruktur oder in einer Partnerumgebung zu; The File bestätigte den Start und diese drei Betriebswege.
Die entscheidende Trennlinie verläuft damit zwischen Orchestrierung und Laufzeit. OpenAI kümmert sich um den Harness, der Sitzungen, Kontext, Werkzeugaufrufe und Subagenten koordiniert; Betreiber wählen weiterhin die Rechenumgebung, die erreichbaren Werkzeuge und deren Berechtigungen. Die Produktankündigung von OpenAI nennt den öffentlichen Betastatus, den verwalteten Codex-Harness und die freie Wahl zwischen OpenAI-gehosteter, eigener und partnerbetriebener Umgebung.
Was der verwaltete Harness tatsächlich übernimmt
Die Agents API liegt oberhalb des verwendeten Modells und der Rechenumgebung. Sie hält länger laufende Sitzungen zusammen, verdichtet früheren Kontext bei Annäherung an das Kontextlimit und lädt Werkzeugdefinitionen bei Bedarf. Programmatische Werkzeugaufrufe lassen sich parallel ausführen, verketten und filtern, bevor ausgewählte Ergebnisse wieder in den Modellkontext gelangen.
Optional kann ein Hauptagent unabhängige Teilaufgaben an Subagenten delegieren. Jeder Subagent arbeitet mit einem eigenen Kontext; der Hauptagent koordiniert die Arbeit und führt die Resultate zusammen. Als Werkzeuge unterstützt der Dienst unter anderem MCP-Server, eigene Funktionen und integrierte Angebote wie die Websuche.
Verwaltet ist der Harness, nicht automatisch die gesamte Anwendung. Die API kann aus dem freigegebenen Werkzeugangebot auswählen und Aufrufe koordinieren. Welche Systeme ein Werkzeug lesen oder verändern darf, welche Daten es erhält und welche Ergebnisse dauerhaft gespeichert werden, legt weiterhin der Betreiber fest.
Agent und Sitzung sind getrennte Ebenen
Ein wiederverwendbarer Agent wird über POST /agents angelegt. Ein Modell ist erforderlich; Anweisungen, Metadaten, Werkzeuge, Service-Tier und eine ausdrückliche Multi-Agent-Konfiguration sind optional. Die API-Referenz für das Anlegen eines Agenten hält zudem fest, dass dieses wiederverwendbare Objekt keine Zugangsdaten speichert.
Die konkrete Arbeit findet anschließend in einer Sitzung statt. Dort treffen Agentenkonfiguration, Eingabe und gewählte Umgebung aufeinander. Der Ablauf lässt sich auf fünf Verantwortungsstationen verdichten:
- Der Betreiber definiert Modell, Anweisungen und erlaubte Werkzeuge.
- Er wählt die Ausführungsumgebung und stellt dort benötigte Dateien, Pakete und Fähigkeiten bereit.
- Die Anwendung startet eine Sitzung mit einer konkreten Aufgabe.
- Der verwaltete Harness pflegt den Kontext und koordiniert Werkzeuge sowie gegebenenfalls Subagenten.
- Die Anwendung verarbeitet Ereignisse und Ergebnisse, speichert den erforderlichen Geschäftszustand und genehmigt mögliche Folgeaktionen.
Diese Trennung erlaubt es, dieselbe Agentenkonfiguration für mehrere Sitzungen einzusetzen. Sie ersetzt jedoch keine Zugriffskontrolle: Berechtigungen für Datenbanken, interne Dienste oder externe Systeme müssen an der Werkzeug- und Umgebungsgrenze beschränkt werden.
Die Laufzeitwahl bestimmt die Betriebsverantwortung
In der OpenAI-gehosteten Sandbox werden Umgebung und Isolation von OpenAI bereitgestellt. Der Agent kann dort Code ausführen, Dateien bearbeiten und Artefakte erzeugen. Betreiber entscheiden dennoch, welche Dateien, Pakete, Fähigkeiten und Geheimnisse für eine Sitzung verfügbar sind.
- OpenAI-gehostete Sandbox: OpenAI stellt die Laufzeit bereit; der Betreiber begrenzt Eingaben, Fähigkeiten, Geheimnisse und erreichbare Dienste.
- Eigene Infrastruktur: OpenAI betreibt den Harness, während Isolation, Netzwerkregeln, Speicher, Kapazität und Verfügbarkeit der Rechenumgebung beim Betreiber liegen.
- Partnerumgebung: Die Laufzeit kommt von einem integrierten Anbieter. Je nach Angebot können sich Bereitstellungsort, Ressourcen, Secret- und Dateispeicherung, Kaltstart, Leistung und Kosten unterscheiden.
Der Ausführungsort ist deshalb mehr als eine Hosting-Option. Er legt fest, wer die Laufzeit absichert, wo Zwischenartefakte entstehen, wie Geheimnisse in einen Auftrag gelangen und wer Störungen oder Kapazitätsengpässe beheben muss. Harness und Sandbox bleiben zwei getrennte Architekturschichten.
Sitzungszustand und Geschäftszustand bleiben verschieden
Die Kontextverwaltung des Harness hält Informationen über längere Sitzungen hinweg nutzbar und kann früheren Kontext automatisch verdichten. Das ist nicht mit der dauerhaften Datenhaltung einer Anwendung gleichzusetzen. Freigaben, Kundendaten, revisionspflichtige Ereignisse und endgültige Ergebnisse müssen nach den fachlichen und regulatorischen Anforderungen des Betreibers gespeichert werden.
Auch die Werkzeugauswahl hat zwei Ebenen. Die API kann innerhalb des bereitgestellten Angebots passende Werkzeuge finden und koordinieren. Der Betreiber kontrolliert davor, welche Funktionen überhaupt angeboten werden, mit welchen Identitäten sie laufen und welche Rückgaben in den Sitzungskontext gelangen dürfen.
Für die Agents API erhebt OpenAI nach der Ankündigung keine zusätzliche API-Grundgebühr; berechnet werden die verwendeten Tokens und kostenpflichtigen Werkzeuge. Das ist jedoch nicht mit den Gesamtkosten eines Agentenlaufs gleichzusetzen. Eigene Rechenkapazität, Partner-Sandboxes, Speicher, Observability und lange Sitzungen können weitere Kosten verursachen, die von der gewählten Architektur abhängen.
Die öffentliche Beta lässt Zusagen für den Produktivbetrieb offen
Der bestätigte Stand ist eine öffentliche Beta, keine allgemein verfügbare Endfassung. OpenAI will den Dienst auf Grundlage von Rückmeldungen weiterentwickeln. Belastbare allgemeine Aussagen zu künftiger Schnittstellenstabilität, verbindlichen Verfügbarkeitszusagen oder Änderungen bis zur allgemeinen Verfügbarkeit liegen damit noch nicht vor.
Für Architekturentscheidungen ist die Grenze dennoch klar: OpenAI übernimmt den Codex-basierten Harness und dessen Orchestrierungsarbeit. Die Verantwortung für Laufzeitwahl, Werkzeugrechte, Geheimnisse, dauerhaften Geschäftszustand und die Kontrolle der Gesamtkosten verbleibt je nach gewähltem Betriebsmodell ganz oder teilweise beim Betreiber.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.