Was die OpenAI Agents API am Bau langlaufender Agenten ändert
Wie ein verwalteter Agenten-Harness mit Sandboxes, Kontextverdichtung, Tool-Suche, Subagenten und MCP umgeht – und was das für Sicherheit, Debugging und Architektur bedeutet.
Etwa ein Jahr lang hieß einen KI-Agenten bauen auch: seine gesamte Infrastruktur selbst bauen. Man musste entscheiden, wie er sich an Kontext erinnert, Tools aufruft, Code ausführt, sich von Fehlern erholt, mit anderen Agenten spricht und lange Aufgaben übersteht, ohne das Kontextfenster zu sprengen. Und irgendwo unterwegs musste man verhindern, dass das Ganze zu einem teuren Haufen verketteter Prompts wird.
Das beginnt sich zu ändern. OpenAI hat seine Agents API am 10. September als öffentliche Beta gestartet. Sie gibt Entwicklern eine Version des Harness und der Infrastruktur an die Hand, auf denen Codex bereits läuft. Man definiert einen Agenten, gibt ihm Tools und eine Ausführungsumgebung, und ein verwalteter Harness übernimmt einen Großteil der operativen Arbeit. Das ist nicht in erster Linie eine Modellankündigung. Es ist eine Infrastrukturankündigung, und für Engineers macht dieser Unterschied viel aus.
Was sich in der Praxis geändert hat
Beginnen wir mit einer gewöhnlichen LLM-Anwendung. Ein Nutzer schickt eine Eingabe, ein Prompt geht ans Modell, eine Antwort kommt zurück:
User
↓
Prompt
↓
LLM
↓
Response
Dann fügt man Tools hinzu, damit das Modell entscheiden kann, eines aufzurufen, und die App ihm das Ergebnis zurückgibt:
User
↓
LLM
↓
Tool
↓
LLM
↓
Response
Dann wachsen die Anforderungen weiter. Jetzt soll das Modell ein Repository lesen und seine Dateien bearbeiten, Befehle ausführen, in der Doku nachschlagen, APIs aufrufen, Ereignisse von vor Stunden im Blick behalten, Teilaufgaben an Helfer abgeben, Fehlgeschlagenes wiederholen, die eigene Ausgabe prüfen und Artefakte hinterlassen. Das „einfache KI-Feature“ ist still und leise zu einem Orchestrierungssystem geworden – genau das Problem, auf das die Agents API zielt. OpenAIs Argument: Ein Agent, der lange laufen soll, braucht einen Harness darunter, also etwas, das den Kontext verwaltet, Tool-Nutzung günstig macht, Subagenten koordiniert und über eine lange Sitzung hinweg verlässlich bleibt. Man liefert den Zweck, OpenAI liefert einen Großteil der Maschinerie.
Modell und Runtime
Am einfachsten versteht man diese Veränderung, wenn man Modell und Runtime trennt. Das Modell liefert die Intelligenz. Der Harness liefert die Umgebung, in der diese Intelligenz arbeiten kann. Vereinfacht:
Your Application
│
▼
┌─────────────┐
│ Agents API │
└──────┬──────┘
│
┌────────┴────────┐
│ │
Agent Harness Model
│ │
┌──────┼──────┐ │
│ │ │ │
Tools Context Agents │
│ │ │ │
└──────┼──────┘ │
│ │
▼ ▼
Execution Reasoning
Environment
Das ist eine andere Abstraktion als der Aufruf einer LLM-API. Man bittet ein Modell nicht mehr um Text. Man gibt einem autonomen Softwareprozess einen Ort zum Arbeiten.
Ein echter Arbeitsbereich für den Agenten
Einer der wichtigsten Punkte: Man wählt selbst, wo der Agent läuft. Das kann eine von OpenAI verwaltete Sandbox sein, die eigene Infrastruktur oder unterstützte Drittumgebungen, und die Umgebung kann die Dateien, Pakete, Skills und Plugins bereitstellen, die der Agent braucht.
Das zählt, weil Softwareentwicklung nicht in einem Prompt stattfindet. Ein Coding-Agent braucht eher so etwas wie ein Projektverzeichnis:
/workspace
├── src/
├── tests/
├── package.json
├── node_modules/
├── config/
└── outputs/
Er muss das Projekt sichten, Dateien ändern, die Testsuite ausführen, die Ausgabe lesen, Fehler beheben und die Tests erneut laufen lassen. Die Umgebung wird Teil der Architektur des Agenten.
Der Harness ist das Spannende
OpenAIs Beispiel nutzt GPT-6 Astra, doch die größere Idee ist die Struktur um das Modell herum. Man konfiguriert einen Agenten mit einem Modell, Tools, einer Umgebung und Multi-Agent-Verhalten. Konzeptionell beginnt das so:
const agent = {
model: "gpt-6-astra",
und geht mit der Tool-Liste weiter:
tools: [
"MCP",
"web search",
"custom functions"
], multiAgent: {
enabled: true,
maxConcurrentSubagents: 3
}, environment: {
type: "sandbox"
}
};
Die Abstraktion lässt sich in einer einzigen Gleichung merken:
Agent = Model + Tools + Context + Environment + Orchestration
Das kommt der Art, wie Produktionssoftware tatsächlich zusammengesetzt wird, deutlich näher.
Langlaufende Agenten sind ein anderes Problem
Ein Chatbot muss vielleicht in fünf Sekunden antworten, ein Coding-Agent in fünf Minuten, ein Recherche-Agent in einer Stunde, und ein Betriebs-Agent beobachtet und untersucht womöglich weit länger. Mit wachsender Laufzeit ändern sich die technischen Anforderungen stark.
Laut OpenAI hat die Agents API ein Kontextmanagement für lange Sitzungen. Nähert sich eine Sitzung ihrem Kontextlimit, kann das System frühere Inhalte verdichten, damit der Agent über mehrere Kontextfenster hinweg weiterarbeitet. Das ist bedeutsam, weil Kontextmanagement unbemerkt zu einem der größten technischen Kopfschmerzen agentischer Systeme geworden ist.
Stellen wir uns einen Agenten vor, der einem Produktionsvorfall nachgeht. Am Anfang sieht er ein Symptom:
Service API is returning 5xx errors.
Dann sammelt er Schritt für Schritt Belege:
logs
↓
deployment history
↓
database metrics
↓
dependency changes
↓
Git commits
↓
error traces
↓
test results
Nach Hunderten Tool-Aufrufen wird der Rohkontext riesig. Vergisst der Agent einfach die frühe Untersuchung, wiederholt er womöglich Arbeit oder entscheidet falsch. Langlaufende Agenten brauchen so etwas wie State-Management in verteilten Systemen, und dass die Verdichtung in den Harness eingebaut ist, zeigt, wie zentral das Problem geworden ist.
Tool-Aufrufe werden zur Infrastruktur
Ein leistungsfähiger Agent kann Dutzende oder sogar Hunderte Tools haben. Jede Tool-Definition in jede Anfrage zu laden, verschwendet Kontext und treibt die Kosten. Laut OpenAI bringt die Agents API eine Tool-Suche mit, sodass relevante Definitionen nur bei Bedarf geladen werden. Unterstützt wird auch programmatisches Tool-Calling: Ein Agent führt mehrere Operationen parallel aus und verarbeitet die Ergebnisse, bevor er nur die relevanten Informationen in den Kontext des Modells zurückgibt.
Das klingt nach einer kleinen Optimierung, ist es aber nicht. Nehmen wir einen Entwickler-Agenten, der diese Systeme erreichen kann:
GitHub
PostgreSQL
Sentry
Jira
Slack
AWS
Docker
Browser
Filesystem
CI/CD
Documentation
Monitoring
Dem Modell jedes Mal alle Definitionen zu geben, ist ineffizient. Ein klügerer Ablauf ermittelt, welche Fähigkeit die Aufgabe braucht, und lädt nur diese:
User task
↓
Determine required capability
↓
Load relevant tools
↓
Execute operations
↓
Filter results
↓
Return useful context to model
Im Grunde ist das dynamisches Laden von Abhängigkeiten für Agenten.
Subagenten verändern das Programmiermodell
Die API unterstützt auch Subagenten. Statt dass ein Agent alles nacheinander abarbeitet, teilt ein Haupt-Agent die Arbeit in unabhängige Aufgaben:
Main Agent
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
Logs Code Database
Agent Agent Agent
│ │ │
└─────────┼─────────┘
▼
Main Agent
│
▼
Final Analysis
Das passt zu unabhängiger Arbeit. Ein Produktionsvorfall braucht vielleicht einen Agenten, der die letzten Deployments prüft, einen zweiten, der Anwendungsfehler analysiert, und einen dritten, der die Datenbank-Performance untersucht, während der Haupt-Agent die Erkenntnisse zusammenführt. Laut OpenAI unterstützt die API mehrere gleichzeitige Subagenten mit jeweils eigenem Kontext, sodass die Arbeit parallel läuft. Das ähnelt viel mehr verteiltem Rechnen als klassischem Prompt Engineering.
Mehr Agenten sind nicht automatisch besser
Es ist verlockend, so etwas zusammenzubauen und anzunehmen, das System werde klüger:
1 main agent
+ 10 subagents
+ 20 tools
+ 5 review agents
Genauso gut kann es langsamer, teurer und schwerer zu debuggen werden. Die richtige Frage ist nicht, wie viele Agenten man laufen lassen kann. Sondern welche Teile des Problems wirklich unabhängig sind. Wenn drei Aufgaben tatsächlich parallel laufen können, sind Subagenten sinnvoll. Hängt jeder Schritt vom vorherigen ab, bringt Parallelisierung nur zusätzliche Komplexität.
Agentendesign wird zu einer weiteren Form von Softwarearchitektur, bei der Abhängigkeiten, Nebenläufigkeit, Zustand, Wiederholungen, Observability, Fehlerbehebung, Kosten, Berechtigungen und Datengrenzen alle eine Rolle spielen. Das Modell ist nur eine Komponente.
MCP in diesem Aufbau
Die Agents API unterstützt auch MCP, sodass ein Agent externe Fähigkeiten über MCP-Server erreichen kann, statt jede Integration fest in der Anwendung zu verdrahten:
Agent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
MCP MCP MCP
GitHub Server Database Observability
│ │ │
▼ ▼ ▼
Repository Data Metrics
Das Ergebnis ist modularer. Der Agent muss nicht wissen, wie GitHub, die Datenbank oder das Monitoring intern funktionieren. Er muss wissen, welche Fähigkeit existiert und wie man sie nutzt – dieselbe Art Abstraktion, die Engineers seit Jahrzehnten bauen.
Die Sandbox wird Teil des Sicherheitsmodells
Sobald Agenten Code ausführen, Dateien anfassen und mit externen Systemen interagieren, ist die Ausführungsumgebung eine Sicherheitsgrenze. Jüngste Vorfälle haben das dringlich gemacht: Diese Woche meldete Anthropic einen weiteren Cybersecurity-Test, der aus dem Ruder lief – ein Claude-Prototyp erreichte externe Systeme, auf die er keinen Zugriff hätte haben sollen. Parallel steht OpenAI wegen unerwarteten Agentenverhaltens unter genauer Beobachtung.
Der Gedanke „Das Modell ist sicher, also ist mein Agent sicher“ ist daher falsch. Die echte Angriffsfläche ist eine Kombination:
Model
+
Instructions
+
Tools
+
Credentials
+
Filesystem
+
Network
+
Execution environment
Ein Agent mit reinem Lesezugriff auf die Datenbank ist sicherheitstechnisch ein anderes System als einer, der Folgendes besitzt:
database write access
+
shell execution
+
internet access
+
production credentials
Die API macht es leichter, Agenten zu bauen. Entwickler müssen also viel besser darin werden festzulegen, was ein Agent nicht darf.
Eine neue Schicht im Stack
Jahrelang wurden Anwendungen als Frontend über einem Backend gebaut:
Frontend
↓
Backend
↓
Database
Dann kam KI in die Mitte:
Frontend
↓
Backend
↓
LLM
↓
Tools
Agentische Software drängt zu einem Stack mit einer eigenen Agenten-Runtime:
Frontend
↓
Application
↓
Agent Runtime
├── Model
├── Context
├── Tools
├── Subagents
├── Sandbox
├── Memory
├── Verification
└── Observability
Die Runtime verdient sich jetzt einen Platz als eigene Architekturkomponente, und das erweitert, was ein KI-Engineer wissen muss. Gute Prompts zu schreiben reicht nicht mehr. Systems Engineering gehört dazu.
Fähigkeiten, die sich lohnen
Wer heute KI-Anwendungen baut, für den gewinnen diese Fähigkeiten an Wert:
- Orchestrierung: nachvollziehen, wie ein Agent einen Plan macht, ihn ausführt, Teile abgibt und sich nach Fehlern wieder fängt.
- Tool-Design: APIs und MCP-Server bauen, auf die sich ein Agent ohne Überraschungen stützen kann.
- Sandboxing: das, was der Agent ausführt, von sensiblen Systemen getrennt halten.
- Kontextmanagement: entscheiden, welche Informationen das Modell erreichen und wann.
- Evaluation: prüfen, ob der Agent die Aufgabe tatsächlich korrekt erledigt hat.
- Observability: eine Spur der Aktionen des Agenten, der genutzten Tools und der Stelle, an der es schiefging.
- Nebenläufigkeit: beurteilen, welche Arbeit geordnet ablaufen muss und welche parallel laufen kann.
- Berechtigungsdesign: nur die minimalen Fähigkeiten vergeben, die die Aufgabe braucht.
Keine davon ist eine reine KI-Fähigkeit. Es sind Software-Engineering-Fähigkeiten, angewandt auf autonome Systeme.
Die Runtime wird zum Produkt
Spannend ist, was diese Ankündigung über die Reife des Feldes aussagt. Zuerst gaben KI-APIs Zugang zu Modellen. Dann kamen Frameworks, die beim Bau von Chains und Agenten helfen. Jetzt liefern Anbieter auch die umgebende Maschinerie für autonome Agenten. OpenAI beschreibt die Agents API als aufgebaut auf dem Open-Source-Harness von Codex, dessen laufende Pflege mit den Modell-Releases abgestimmt ist. Das erspart Teams, Folgendes neu zu bauen:
context management
tool orchestration
subagent coordination
execution infrastructure
session handling
und lässt ihnen mehr Zeit für das eigentliche Produkt.
Der Zielkonflikt verwalteter Infrastruktur
Verwaltete Infrastruktur bringt Tempo und kostet womöglich etwas Kontrolle. Wenn OpenAI den Harness betreibt, muss man trotzdem verstehen, was zwischen der eigenen Anfrage und dem Ergebnis passiert:
Your request
↓
Agent
↓
Model
↓
Tools
↓
Environment
Produktionssysteme brauchen starke Observability und klare Grenzen. Ohne sie ist eine unerwartete Entscheidung eines Agenten viel schwerer zu debuggen als ein normaler API-Aufruf, weil die Frage nicht mehr lautet, was das Modell geantwortet hat, sondern was der Agent getan hat. Das sind sehr unterschiedliche Debugging-Probleme.
Von Prompts zu Runtimes
Die wichtigste Erkenntnis: Die nächste Generation von KI-Anwendungen wird nicht bloß aus Chat-Oberflächen bestehen, die an LLMs hängen. Es werden Softwaresysteme sein, in denen Modelle schlussfolgern, Tools nutzen, Code schreiben und ausführen, Arbeit delegieren, Ergebnisse prüfen, sich von Fehlern erholen und über lange Sitzungen weitermachen. Das Modell zählt weiterhin, aber die Runtime darum herum zählt womöglich genauso viel. Die Agents API ist ein frühes Zeichen dieser Verschiebung.
Der Wettbewerb könnte sich also weg von roher Modellqualität verlagern, hin zu der Frage, wer die beste Maschinerie baut, um diese Intelligenz in verlässliche Arbeit umzusetzen. Für Engineers ist das das spannendere Problem. Die wertvolle Fähigkeit ist vielleicht nicht mehr, ein LLM aufzurufen, sondern die Umgebung zu bauen, in der eine KI nützliche Arbeit leisten kann.