Am 10. September hat OpenAI die Agents API in die öffentliche Beta überführt – und stellt Entwicklern damit „denselben Harness und dieselbe Infrastruktur, die Codex antreibt, über eine einfache, flexible API zur Verfügung“. Auf dem DevDay am 29. September kamen Computer-Use, ein AWS-natives Pendant sowie ein neuer Nachbar hinzu: Auch die neuen, permanent aktiven Dots von ChatGPT laufen auf demselben Codex-Harness.
Liest man das als Entwickler, der ein agentenbasiertes Produkt baut, sind das gute Nachrichten: Der Harness, den man andernfalls fehleranfällig selbst hätte schreiben müssen, ist nun das Problem von jemand anderem. Betrachtet man das Ganze jedoch als Engineer, dessen Team Claude Code und Codex bereits auf einer echten Codebasis einsetzt, stellt sich eine ganz andere Frage. Die API beantwortet: „Wie lasse ich einen Agenten stundenlang laufen?“ Sie beantwortet jedoch nicht: „Woher weiß mein Team, was sechs dieser Agenten getan haben und wer die Website genehmigt hat, bei der sich einer von ihnen gerade eingeloggt hat?“ Genau bei dieser zweiten Frage setzt Sharkly an.
TL;DR
Die Agents API hostet den Codex-Harness: langlebige Sessions, Context Compaction, Tool-Suche, Subagenten sowie eine Sandbox von OpenAI, aus der eigenen Infrastruktur oder von neun Partnern – ohne zusätzliche Gebühren jenseits von Tokens, Tools und Container-Laufzeit. Der DevDay brachte Computer-Use, bei dem Ihre Anwendung jede neue Website-Origin und jeden Login bestätigen muss (wobei die Origin-Freigabe keine Bestätigung einzelner Aktionen darstellt), sowie Bedrock Managed Agents, die diese Kernfunktionen direkt innerhalb von AWS ausführen. Nichts davon deckt jedoch die Teamebene ab: Wer hat die Aufgabe zugewiesen, welcher Agent bearbeitet sie, was wurde abgeschlossen, was ist fehlgeschlagen und wer nimmt das Ergebnis ab?
Was die Agents API ist – und was OpenAI übernimmt
Die Übersicht von OpenAI reduziert die API auf vier Kernkonzepte. Ein Agent ist „das Modell, die Instruktionen, Tools und MCP-Server, die dem Agenten zur Verfügung stehen“. Ein Environment ist „eine optionale Sandbox oder ein Computer, worin der Agent auf Dateien zugreift, Skills lädt und Befehle ausführt“. Eine Session ist „eine persistente Instanz eines Agenten, die Aufgaben bearbeitet und auf Eingaben reagiert“. Events and items sind die gesendeten Eingaben und die zurückgegebenen Ausgaben.
Man erstellt eine Session mit einer Agentenkonfiguration, weist ihr eine Aufgabe zu, sobald das Environment bereitsteht, verfolgt den Ablauf via Streaming oder Webhooks und kann anschließend weitere Aufgaben oder Steuerungsbefehle in dieselbe Session einsteuern. Das gekürzte Beispiel aus der Dokumentation:
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
Zwei Zeilen enthalten den Großteil der Neuerungen: multi_agent aktiviert das Aufteilen auf Subagenten (Fan-out) mit einer Obergrenze für parallele Ausführungen, und environment.type bestimmt, wo der Code ausgeführt wird: openai_hosted, self_hosted oder in einer der Partner-Sandboxen (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel).
Die Dokumentation bringt die Arbeitsteilung in einem einzigen Satz auf den Punkt: „OpenAI übernimmt Sessions, Orchestrierung, Context Compaction und Recovery, während Ihre Anwendung Tools bereitstellt und die Ausführungsumgebung wählt.“
| Was OpenAI übernimmt | Was Sie weiterhin bereitstellen |
|---|---|
| Den Agent-Loop: Modellaufrufe, Tool-Nutzung, Retries | Die Aufgabe und die Definition of Done |
| Context Compaction, sobald sich eine Session ihrem Limit nähert | Tools: MCP-Server, Functions, Built-ins |
| Tool-Suche und das Laden von Tools | Credentials über Vault-IDs |
| Aufteilung und Koordination von Subagenten | Die Wahl der Umgebung und deren Einrichtung |
| Fortsetzung und Steuerung von Sessions | Alles, was nach dem Ende der Session geschieht |
Die Modellnutzung wird zu den regulären API-Preisen des Modells abgerechnet, Tools zu Standardpreisen und von OpenAI gehostete Sandboxen nach Container-Laufzeit. Im Ankündigungsbeitrag heißt es: „Für die Nutzung der Agents API fallen keine zusätzlichen Gebühren an.“ Zwei Einschränkungen werden in der Dokumentation unmissverständlich benannt: Die API „unterstützt Data Residency derzeit ausschließlich in den USA und bietet kein Zero Data Retention (ZDR)“, und auch die Wahl einer selbst gehosteten Sandbox macht sie nicht ZDR-konform. Falls einer dieser Punkte für Ihre Compliance relevant ist, ändert auch der Betrieb der Sandbox im eigenen Haus nichts daran.
Was der DevDay Neues gebracht hat
Computer-Use. Fügt man das computer_use-Tool hinzu und aktiviert einen Desktop in einer von OpenAI gehosteten Umgebung, steuert der Agent einen gehosteten Browser. Der Leitfaden zu Computer-Use baut den Ablauf um Genehmigungs-Events (Approval Events) auf. Der Browser fordert vor jeder neuen Website-Origin die Zustimmung des Nutzers an – auch bei öffentlich zugänglichen Websites. Logins treffen als separate Anfragen ein, für die Ihre Anwendung Felder für E-Mail, Passwort und Bestätigungscode rendert. Passkeys und QR-Code-Logins werden nicht unterstützt, und Zugangsdaten dürfen ausschließlich vom Hauptagenten angefordert werden, nicht von Subagenten. Ein Satz, den man zweimal lesen sollte: „Die Origin-Genehmigung erzwingt keine Bestätigung vor einzelnen Aktionen.“ Für Kaufvorgänge oder destruktive Änderungen empfiehlt die Dokumentation, den gehosteten Browser auf Ressourcen zu beschränken, die derartige Aktionen gar nicht erst ausführen können, oder eine Browser-Laufzeitumgebung unter eigener Kontrolle zu nutzen. Der DevDay-Rückblick listet Computer-Use „über die API sowie in Codex und ChatGPT Work für Pro 500 und Enterprise“ auf.
Bedrock Managed Agents, powered by OpenAI. OpenAI und Amazon haben „die Kernfunktionen der Agents API“ übernommen und angepasst, damit sie nativ in AWS laufen. Die Produktseite von AWS führt das Angebot als Preview und betont, dass Agenten-Laufzeitumgebung und Modell-Inferenz vollständig innerhalb von AWS verbleiben, wobei jeder Agent über eine eigene AWS-Identität und entsprechende Berechtigungen verfügt.
Dots auf demselben Harness. Decrypt berichtet, dass der Codex-Harness „nun Dots antreibt und Open Source ist“. Dots sind die permanent aktiven Agenten von ChatGPT, die jeweils über einen eigenen Cloud-Computer verfügen; unser Erklärbeitrag zu Dots beleuchtet ausführlich, worin ihre Stärken liegen.
Damit treibt eine einzige Schleife nun Coding-Agenten, API-Sessions, AWS-Agenten und Always-on-Assistenten an. Die Harness-Infrastruktur wächst zusammen. Die Approval Events sind jedoch der Teil, der letztlich beim Team landet: Jedes Event ist eine Rückfrage innerhalb einer einzelnen Session, beantwortet von der Person, die den Stream gerade offen hat. Wenn fünf Sessions gleichzeitig anfragen, muss jemand festlegen, wer welche Origin freigeben darf und wo diese Entscheidung protokolliert wird. Das ist ein typisches Problem für Approval Gates – und die computerseitige Umsetzung haben wir in GPT-6 Astra computer use guardrails detailliert aufgeschlüsselt.
Was die API nicht übernimmt: die Teamebene
Eine Session weiß nur von sich selbst. Sie weiß nicht, dass drei andere Sessions dasselbe Repository bearbeiten oder dass das Ergebnis einer vierten seit Dienstag ungelesen herumliegt. Das sind Managementfragen – und sie treten genau in dem Moment auf, in dem mehr als eine Person mehr als einen Agenten startet.
Fünf Fragen, die die API ganz bewusst offenlässt:
- Wer hat die Aufgabe zugewiesen und zu welchem Ticket gehört sie? Eine Session hat eine ID und die Metadaten, die der eigene Code hineinschreibt. Eine zuständige Person, ein Sprint oder ein Link zum ursprünglichen Issue existieren nur dann, wenn man sie selbst dort hinterlegt.
- Welches Repository und welcher Branch wurden geändert? Das Diff muss dorthin gelangen, wo ein Reviewer es einsehen und prüfen kann.
- Was ist abgeschlossen, was fehlgeschlagen, was wartet noch? Events streamen, solange man zuhört, oder treffen per Webhook ein. Es entsteht daraus aber keine Queue von Ergebnissen, die auf eine menschliche Prüfung warten.
- Wer nimmt das Ergebnis ab? Ein Approval Event betrifft lediglich eine Website oder einen Login, nicht die geleistete Arbeit. „Die Session ist beendet“ und „Ein Mensch hat die Ergebnisse geprüft und freigegeben“ sind ein und dasselbe Event – es sei denn, man baut den zweiten Schritt selbst.
- Was ist mit Agenten, die nicht von OpenAI stammen? Nutzt man Claude Code für bestimmte Aufgaben und Codex für andere, bedeutet das zwei unterschiedliche Session-Modelle und zwei separate Anlaufstellen.
All diese fünf Punkte lassen sich auf Basis der Events selbst nachrüsten: ein Board, ein Webhook, ein Statusfeld, eine Review-Spalte. Doch dann fragt jemand: „Haben wir den Bugfix für den Export eigentlich jemals deployed?“, und die Antwort liegt in einem Chat-Verlauf (Scrollback), den niemand archiviert hat. Unser Leitfaden zu AI agent task management beschreibt diesen Do-it-yourself-Ansatz genauer.
Subagenten innerhalb einer Session oder Tasks auf einem Board?
Der Parameter max_concurrent_subagents ist die Antwort der API auf das Thema Parallelisierung – und für die passende Art von Workload eine ausgesprochen gute. Es handelt sich um denselben Kompromiss, den wir beschrieben haben, als Codex sein Subagenten-Limit auf 64 anhob: Subagenten teilen sich einen gemeinsamen übergeordneten Kontext (Parent), liefern ihre Rückmeldungen in einer einzigen zusammengefassten Antwort ab und werden als ein Gesamtergebnis gereviewt.
Nutzen Sie Subagenten innerhalb einer Session, wenn die Teilaufgaben leselastig und voneinander unabhängig sind und letztlich nur das Gesamtergebnis zählt: vier APIs recherchieren, eine Codebasis nach einem bestimmten Muster durchsuchen oder Belege für einen Incident zusammentragen.
Verwenden Sie separate Tasks, wenn jeder Teil Code schreibt, der individuell geprüft werden muss: eine Migration, ein Feature in einem Modul oder ein Bugfix an einer gemeinsam genutzten Datei. In Sharkly erhält jeder Durchlauf seinen eigenen isolierten Git-Worktree auf einem Computer unter Ihrer Kontrolle. Jedes Ergebnis fließt mit eigenem Diff, Ausführungsprotokoll und Reviewer in seinen jeweiligen Task zurück. Vier schreibintensive Änderungen in eine einzige Subagenten-Zusammenfassung zu quetschen, bedeutet letztlich: vier eigenständige Entscheidungen in einer einzigen zu verstecken.
Häufig gestellte Fragen (FAQ)
Auf welchem Modell läuft Computer-Use? Die Beispiele in der Dokumentation verwenden gpt-6-astra. Prüfen Sie den Leitfaden, bevor Sie davon ausgehen, dass andere Modelle mit dem computer_use-Tool kompatibel sind.
Führt Sharkly Agents-API-Sessions aus? Sharkly führt CLI-Coding-Agenten wie Codex und Claude Code aus, die als Runtimes auf Ihren eigenen Computern installiert sind. Sessions der Agents API sind ein gehosteter Dienst und keine lokal installierte Runtime – betrachten Sie diese daher als separaten Ausführungspfad.
Wo findet das Human Review statt? Bei der Agents API genau dort, wo Sie es selbst implementieren: Approval Events decken lediglich den Zugriff auf Websites und Logins ab, nicht die Freigabe des Arbeitsergebnisses. In Sharkly kann ein Agent seinen Task in den Status „Waiting for human review“ versetzen; die Anfrage landet im Posteingang der zuständigen Person, und diese ändert den Status erst, nachdem sie die Antwort, das Ausführungsprotokoll und das Diff geprüft hat.
Welcher Layer wohin gehört
Eine persistente Session in der OpenAI-Infrastruktur ist das komfortabelste Element dieses Launchs – und zugleich das mit dem stärksten Lock-in-Effekt. Für ein Engineering-Team fällt das ins Gewicht: Welcher Coding-Agent aktuell die Nase vorn hat, ändert sich laufend. Ein Team, dessen Review-Status und Zuweisungsregeln im Session-Store eines einzelnen Anbieters feststecken, muss seinen Workflow jedes Mal neu aufsetzen, wenn die Marktführerschaft wechselt.
Wenn Sie ein agentenbasiertes Produkt oder einen Backend-Dienst entwickeln, ist die Agents API genau die richtige Abstraktionsebene – und Bedrock Managed Agents bietet denselben Vorteil für Teams, die sich innerhalb des AWS-Ökosystems bewegen. Sie erhalten den Harness, ohne ihn warten zu müssen, und Sandboxen, ohne sie manuell bereitzustellen. Möglicherweise benötigen Sie überhaupt kein Task-Board; Ihre Anwendung selbst fungiert als Board.
Agieren Ihre Agenten hingegen als Teammitglieder auf der eigenen Codebasis – von Menschen gestartet, von Menschen gereviewt und über bestehende Repositories und Issue-Tracker deployed –, verschieben sich die Prioritäten. Codex und Claude Code übernehmen die Ausführung. Sharkly steuert die Zuweisungen auf Teamebene, angebundene Computer, Task-Kontexte, Fortschritte, Blocker, Ergebnisse und das Human Review über diese Tools hinweg. Es ist weder ein Ersatz für die beiden Runtimes noch für die Agents API. Dieselbe Fragestellung zur optimalen Platzierung gilt mittlerweile auch für Codex selbst, was wir in Codex Cloud vs. Ihre eigenen Computer behandeln.
Mieten Sie den Harness, wenn Sie einen Agenten bauen. Behalten Sie die Verwaltungsebene in eigener Hand und anbieterunabhängig, wenn Sie Agenten managen.
Wenn Sie bereits mehrere Agenten einsetzen, bietet Sharkly Ihnen einen zentralen Ort, um deren Tasks und Ergebnisse zu verwalten. Sharkly verkauft keine Tokens: Die Modellnutzung läuft weiterhin direkt über die Abonnements oder API-Keys, die in den von Ihnen angebundenen Tools hinterlegt sind.
