OpenAI macht die technische Hülle hinter Codex nun als Agents API für Entwickler zugänglich. Seit dem 10. September läuft sie als öffentliche Beta. Der wichtige Punkt ist nicht ein weiteres Chatfenster: Die Schnittstelle soll die mühselige Betriebslogik für lang laufende KI-Agenten liefern – also Sitzungen, Kontextverwaltung, Werkzeugnutzung und Wiederanläufe nach Fehlern.
Das verschiebt die Arbeitsteilung. Teams können weiterhin selbst entscheiden, welche Daten, Werkzeuge und Regeln ihr Agent kennt. Sie müssen aber weniger davon selbst bauen, was aus einem Sprachmodell erst einen verlässlicheren Arbeitsprozess macht. Gerade darin liegt der praktische Unterschied zwischen einer eindrucksvollen Demo und einem System, das eine Aufgabe auch nach Stunden noch nachvollziehbar weiterführen soll.
Das Wichtigste in Kürze
- OpenAI hat die Agents API am 10. September 2026 als öffentliche Beta veröffentlicht.
- Sie stellt das von Codex bekannte Agenten-Gerüst bereit: dauerhafte Sitzungen, Kontextverdichtung, Werkzeuge und Fehlererholung.
- Der Ausführungsort bleibt wählbar: eine von OpenAI betriebene Sandbox, eigene Infrastruktur oder angebundene Partner.
- Für Unternehmen verschiebt sich die Kernfrage von „Wie bauen wir einen Agenten-Loop?“ zu „Welche Daten, Rechte und Kontrollpunkte bekommt unser Agent?“
Nicht das Modell, sondern die Betriebslogik
Ein Sprachmodell beantwortet eine einzelne Anfrage. Ein Agent soll dagegen oft eine Kette aus Schritten abarbeiten: Dateien lesen, Informationen suchen, Code ausführen, Zwischenergebnisse sichern und bei einer Unterbrechung sinnvoll fortsetzen. Dafür braucht es mehr als ein Modell und einen Prompt. Es braucht einen sogenannten Harness, also die Steuerung rund um Modellaufrufe, Werkzeuge, Speicher und Zustände.
Genau dieses Gerüst will OpenAI nun verwalten. Die Agents API kann laut Produktankündigung lange Sitzungen fortführen und früheren Kontext automatisch verdichten, wenn das Kontextfenster knapp wird. Sie unterstützt eigene Funktionen, MCP-Server und integrierte Werkzeuge wie Websuche. Programmgesteuerte Werkzeugaufrufe sollen zudem parallele und mehrstufige Abläufe ermöglichen. Das sind Funktionen, die viele Teams bisher selbst aus mehreren Bibliotheken, Warteschlangen und Protokollen zusammensetzen mussten.
Das klingt nach Infrastrukturdetail, ist aber ein Qualitätshebel. Ein Agent, der nach einer Stunde nicht mehr weiß, welche Datei er geändert hat oder warum ein Teilschritt scheiterte, ist im Arbeitsalltag kaum brauchbar. Wer den Zustand einer Aufgabe sauber hält, kann Ergebnisse prüfen, Zwischenschritte wiederverwenden und Fehlschläge gezielter behandeln. Die jüngst berichtete Kontrolllücke bei ausgebrochenen KI-Agenten zeigt zugleich, dass mehr Ausdauer und Werkzeugzugriff nicht automatisch mehr Sicherheit bedeuten.
Die Sandbox bleibt eine Architekturentscheidung
OpenAI trennt den Agenten-Harness vom Ort, an dem der Code läuft. Entwickler können eine von OpenAI betriebene Sandbox wählen, ihre eigene Infrastruktur anbinden oder auf Partner wie Cloudflare, DigitalOcean, Modal, Oracle oder Vercel setzen. Das ist für Firmen relevanter als eine lange Partnerliste: Datenhaltung, Netzregeln, Zugriffe auf interne Systeme und Kostenprofile lassen sich nicht für jede Aufgabe gleich behandeln.
Eine verwaltete Sandbox kann den Einstieg beschleunigen. Sie entbindet ein Team aber nicht davon, Rechte eng zu setzen und Werkzeuge bewusst auszuwählen. Ein Agent mit Zugriff auf ein Ticket-System, einen Cloud-Speicher und eine Deployment-Umgebung kann viel Zeit sparen. Er kann bei zu weit gefassten Berechtigungen aber auch viel Schaden anrichten. Die Erkenntnis aus dem jüngsten Claude-Testvorfall – eine Sandbox allein reicht nicht – gilt unabhängig vom Anbieter: Entscheidend sind begrenzte Fähigkeiten, überprüfbare Protokolle und menschliche Freigaben an riskanten Übergängen.
Praktisch sollten Unternehmen daher nicht mit dem breitesten Prozess beginnen. Sinnvoller sind klar abgegrenzte Aufgaben, etwa das Sortieren eingehender Dokumente, die Analyse eines Fehlers oder ein Entwurf für einen Code-Review. Dazu gehören getrennte Zugangsdaten, ein kleines Werkzeugset und eine Regel, wann der Agent nur vorschlägt und wann er handeln darf. Eine API nimmt Arbeit ab, sie trifft diese Governance-Entscheidungen aber nicht.
Mehrere Agenten sind kein Selbstläufer
Die API kann Aufgaben an Unteragenten verteilen, die mit jeweils eigenem Kontext parallel arbeiten. Das eignet sich etwa für Recherche, Tests und Fehleranalyse, sofern die Teilaufgaben wirklich unabhängig sind. Der mögliche Geschwindigkeitsgewinn hat eine Kehrseite: Mit jedem zusätzlichen Agenten steigen auch Kosten, Beobachtungsaufwand und die Zahl möglicher Nebenwirkungen.
Deshalb ist Orchestrierung kein Luxus. Ein übergeordneter Agent oder eine Anwendung muss festlegen, welche Teilaufgabe wer bekommt, welche Ergebnisse zurückkehren dürfen und wie Widersprüche aufgelöst werden. Ohne diese Regeln kann Parallelisierung nur schneller Verwirrung erzeugen. Das gilt besonders dort, wo Agenten auf aktuelle Systeme zugreifen. Der bereits veröffentlichte Bericht über Metas Einkaufsagenten Muse zeigt die andere Seite derselben Entwicklung: Sobald ein Agent nicht nur informiert, sondern Transaktionen vorbereitet, werden Zuständigkeit und Einwilligung zu Produktmerkmalen.
Was sich für Entwickler wirklich ändert
OpenAI verspricht für die API keine zusätzliche Plattformgebühr; abgerechnet werden laut Ankündigung die verwendeten Tokens und Werkzeuge. Ob das für ein Projekt günstiger ist als ein eigener Stack, hängt trotzdem vom Einsatz ab. Wer nur wenige kurze Aufgaben automatisiert, braucht möglicherweise keine umfangreiche Laufzeitumgebung. Wer dauerhaft viele Dokumente, Systeme und Arbeitsschritte verbindet, kann von einer gepflegten Sitzungs- und Tool-Infrastruktur profitieren.
Der Wettbewerb verlagert sich damit ein Stück weg vom bloßen Agenten-Framework. Differenzierung entsteht eher durch gute interne Werkzeuge, saubere Datenzugänge, belastbare Prüfungen und ein klares Verständnis der Fachaufgabe. Ein Agent für die Buchhaltung braucht andere Grenzen als ein Agent für Support oder Softwareentwicklung. Kein allgemeiner Harness kann diese Unterschiede für ein Unternehmen vorentscheiden.
Ausblick: Die bequeme Schicht braucht harte Grenzen
Die Agents API senkt die Hürde, aus einem Modell einen lang laufenden Arbeitsprozess zu machen. Das ist für Entwickler attraktiv, weil sie weniger Zeit auf Wiederanläufe, Kontextpflege und Werkzeugverkabelung verwenden müssen. Für Nutzer und Unternehmen macht es Agenten zugleich alltäglicher – und damit wichtiger, nicht nur ihre Antworten, sondern ihre Rechte und Nebenwirkungen zu prüfen.
Die entscheidende Frage lautet deshalb nicht, ob ein Anbieter einen Agenten über mehrere Stunden laufen lassen kann. Sie lautet, welche Aufgabe er erledigen darf, welche Daten er dabei sieht und an welcher Stelle ein Mensch die letzte Entscheidung behält. Wer diese Grenzen zuerst festlegt, kann die neue Infrastruktur sinnvoll nutzen. Wer sie nachträglich ergänzt, baut lediglich schneller ein schwer kontrollierbares System.