Agents API: Der Agent ist noch kein Workflow

Die aktuelle Nachricht — und die wichtigere Frage dahinter

OpenAI hat am 10. September 2026 die Agents API als Public Beta vorgestellt. Entwickler können damit langlebige Cloud-Agenten starten und Modell, Werkzeuge und Ausführungsumgebung in einer Anfrage festlegen. Die Plattform übernimmt Teile des technischen Unterbaus: Sitzungen, Kontextverwaltung, Tool-Nutzung und optional die Koordination mehrerer Teilagenten. Als Umgebung stehen unter anderem gehostete Sandboxes, eigene Infrastruktur und Partnerangebote zur Wahl.

Das ist relevant, weil bisher viel Projektzeit nicht in den eigentlichen Anwendungsfall floss, sondern in die Schicht drumherum: Zustand erhalten, lange Jobs fortsetzen, Werkzeuge beschreiben, Ergebnisse einsammeln und abgebrochene Läufe wieder aufnehmen.

Diese Infrastruktur wird nun leichter zugänglich. Die Produktarbeit verschwindet dadurch aber nicht. Im Gegenteil: Sobald ein Agent nicht nur antwortet, sondern Dateien liest, Systeme abfragt oder Änderungen vorbereitet, müssen Auftrag, Rechte und Verantwortung genauer beschrieben sein als bei einem Chatfenster.

Mit einem abgeschlossenen Auftrag beginnen

„Hilf unserem Vertrieb“ ist kein Agenten-Workflow. Es ist eine Richtung. Ein belastbarer erster Auftrag hat einen klaren Auslöser und ein überprüfbares Ende.

Ein Beispiel: Nach einer qualifizierten Anfrage sammelt der Agent öffentlich verfügbare Informationen zur Firma, ordnet die Anfrage einer Leistung zu, erstellt einen Gesprächsbrief und legt ihn zur Prüfung im CRM ab. Er versendet keine Nachricht und ändert keine Preise.

Damit sind fünf Dinge geklärt:

• Auslöser: Eine Anfrage wurde von einem Menschen als relevant markiert.
• Eingaben: Formularinhalt, freigegebene CRM-Felder und öffentliche Website.
• Ergebnis: Ein Briefing in einem festen Format mit Quellen und offenen Fragen.
• Grenze: Kein Versand, kein Angebot, keine Veränderung kaufmännischer Daten.
• Verantwortung: Ein benannter Mitarbeiter prüft und entscheidet über den nächsten Schritt.

Diese Grenzen machen den Auftrag nicht weniger intelligent. Sie machen ihn produktionsfähig.

Ein Agent ist kein Berechtigungssystem

Ein gutes Modell kann begründen, welches Werkzeug es einsetzen möchte. Es sollte dennoch nicht selbst bestimmen, welche Daten es sehen und welche Aktionen es ausführen darf.

Werkzeuge brauchen deshalb Rechte wie andere Software-Schnittstellen auch. Ein Recherche-Agent benötigt vielleicht Lesezugriff auf bestimmte CRM-Felder, aber keinen Export des gesamten Kundenbestands. Ein Agent zur Release-Vorbereitung darf Tests starten und einen Entwurf für Release Notes erstellen, aber nicht ohne Freigabe Produktion umschalten.

Praktisch teilen wir Werkzeuge in drei Gruppen:

1. Lesen: suchen, abrufen, vergleichen und zusammenfassen.
2. Vorbereiten: Entwürfe, Dateien oder Änderungsvorschläge erstellen, die noch keine Außenwirkung haben.
3. Ausführen: senden, veröffentlichen, bezahlen, löschen oder Berechtigungen ändern.

Die dritte Gruppe erhält eigene Prüfungen und meist eine menschliche Bestätigung. Diese Trennung gehört in die technische Schnittstelle. Ein Satz im Prompt ist keine Zugriffskontrolle.

Lange Sitzungen müssen fortsetzbar sein

Die neue API ist ausdrücklich für Arbeiten gedacht, die länger als eine einzelne Modellantwort dauern können. Kontextkomprimierung hilft dabei, relevante Informationen über lange Sitzungen zu tragen. Für ein Produkt reicht das allein jedoch nicht.

Ein mehrstufiger Auftrag braucht auch außerhalb des Modells einen nachvollziehbaren Zustand:

• eine eindeutige Auftragsnummer;
• bekannte Phasen und gespeicherte Zwischenergebnisse;
• ein Zeit- und Kostenbudget;
• einen klaren Status für wartet, läuft, braucht Freigabe, fehlgeschlagen und abgeschlossen;
• sichere Wiederholungen, die keine doppelten E-Mails oder Datensätze erzeugen;
• eine Möglichkeit, den Lauf zu stoppen und später kontrolliert fortzusetzen.

Wenn ein Prozess nach zwei Stunden an einer abgelaufenen Anmeldung scheitert, darf die Lösung nicht „alles noch einmal“ heißen. Der letzte bestätigte Meilenstein muss erkennbar sein. Langlebigkeit ist weniger eine Frage der Geduld des Modells als der guten Buchführung des Systems.

Werkzeuge als kleine, ehrliche Verträge bauen

Agents API unterstützt unter anderem MCP, eigene Funktionen und integrierte Werkzeuge. Entscheidend ist nicht die Anzahl, sondern die Qualität ihrer Verträge.

Ein Werkzeug namens „Kundenproblem lösen“ versteckt zu viele Entscheidungen. Besser sind schmale Fähigkeiten wie „Bestellung anhand einer ID lesen“, „Lieferstatus abrufen“ oder „Antwortentwurf speichern“. Jede Fähigkeit beschreibt erlaubte Eingaben, ein kompaktes Ergebnis und verständliche Fehlerfälle.

Gute Werkzeuge:

• validieren Eingaben, bevor sie etwas verändern;
• liefern nur die Daten zurück, die für den nächsten Schritt nötig sind;
• unterscheiden nicht gefunden, nicht erlaubt und vorübergehend nicht erreichbar;
• besitzen eine stabile Kennung für schreibende Vorgänge;
• protokollieren die Aktion, ohne unnötige sensible Inhalte zu kopieren.

So kann der Agent sinnvoll planen, während das System die harten Regeln durchsetzt.

Die Umgebung ist Teil des Produktdesigns

OpenAI trennt Agentenlogik und Ausführungsumgebung: Teams können eine gehostete Sandbox, eigene Infrastruktur oder eine Partnerumgebung wählen. Diese Entscheidung ist keine reine DevOps-Frage.

Für einen Agenten, der öffentliche Websites untersucht und ein Markdown-Dokument erzeugt, kann eine kurzlebige gehostete Umgebung passen. Für interne Dateien, regulierte Daten oder bestehende private Netze kann eine Umgebung mit engeren Netzwerk- und Speichergrenzen sinnvoller sein.

Vor der Wahl klären wir:

• Welche Daten betreten die Umgebung?
• Welche Ziele darf sie im Netzwerk erreichen?
• Wo liegen Dateien und Geheimnisse während des Laufs?
• Was bleibt nach dem Ende erhalten?
• Welche Protokolle braucht Support, Datenschutz und Abrechnung?

Die beste Umgebung ist nicht die mit den meisten Möglichkeiten, sondern die kleinste, in der der konkrete Auftrag zuverlässig erledigt werden kann.

Teilagenten nur für wirklich unabhängige Arbeit

Mehrere Agenten parallel einzusetzen klingt automatisch schneller. Es lohnt sich aber nur, wenn sich ein Auftrag sauber teilen lässt.

Bei einer Wettbewerbsanalyse können drei Teilagenten unabhängige Websites untersuchen und ihre Ergebnisse in dasselbe Schema schreiben. Bei einer Preisentscheidung, in der jeder Schritt vom vorherigen Ergebnis abhängt, erzeugt Parallelität eher Abstimmungskosten und Widersprüche.

Vor dem Aufteilen helfen drei Fragen:

1. Können die Teilaufgaben ohne gegenseitige Zwischenstände arbeiten?
2. Gibt es ein gemeinsames Ausgabeformat?
3. Wer löst Widersprüche und prüft das Gesamtergebnis?

Ein koordinierender Agent sollte nicht nur Texte zusammenkleben. Er braucht Regeln für fehlende Belege, unterschiedliche Einschätzungen und einen unvollständigen Teilauftrag.

Beobachtbarkeit vor Autonomie

Ein Agentenlauf ist kein einzelner API-Aufruf mehr. Um Fehler zu verstehen, muss das Team den Weg sehen: Auftrag, verwendete Werkzeuge, Freigaben, Zwischenergebnisse, Laufzeit, Kosten und Abbruchgrund.

Dabei geht es nicht um das Speichern jedes Gedankens. Wichtig sind überprüfbare Ereignisse und Entscheidungen. Für den Vertriebs-Workflow könnte das Dashboard zeigen, welche Quellen gelesen wurden, welche CRM-Felder verwendet wurden, ob Angaben unsicher sind und wer den fertigen Brief freigegeben hat.

Vor einer breiten Einführung läuft der Agent gegen ein festes Testset. Dazu gehören normale Fälle, fehlende Daten, nicht erreichbare Werkzeuge, manipulierte Webseiten, doppelte Auslöser und Aufgaben, die bewusst abgelehnt werden müssen. Die Public Beta ist ein guter Zeitpunkt für kontrollierte Piloten, nicht für unsichtbare Vollautonomie in kritischen Prozessen.

Beispiel: Vorbereitung eines Erstgesprächs

Eine neue Anfrage trifft über die Website ein. Ein Mensch markiert sie als passend. Danach startet der Auftrag.

Der Agent liest nur die freigegebenen Felder, untersucht die angegebene Unternehmenswebsite und sammelt Belege für Branche, Produkt und mögliche technische Baustellen. Ein zweiter, unabhängiger Schritt prüft Quellen und markiert Vermutungen. Anschließend entsteht ein Briefing mit Zusammenfassung, fünf konkreten Fragen und einer Liste offener Punkte.

Das System speichert den Entwurf im CRM und wartet. Erst ein Mitarbeiter entscheidet, welche Informationen stimmen, ob ein Gespräch angeboten wird und welche Nachricht das Unternehmen verlässt. Wird die Recherche unterbrochen, setzt der Lauf beim letzten vollständigen Schritt fort. Wird das Budget erreicht, stoppt er mit einem sichtbaren Grund.

Der Nutzen entsteht nicht aus maximaler Autonomie. Er entsteht, weil wiederkehrende Vorbereitung schneller wird, während die geschäftliche Entscheidung bei der richtigen Person bleibt.

Ein vernünftiger Pilot in acht Schritten

1. Einen häufigen, klar abgrenzbaren Auftrag mit niedrigem Außenrisiko auswählen.
2. Auslöser, Eingaben, Ergebnis und verantwortliche Person festhalten.
3. Lese-, Vorbereitungs- und Ausführungsrechte technisch trennen.
4. Kleine Werkzeuge mit eindeutigen Fehlern bauen.
5. Meilensteine, Budgets, Stopps und sichere Wiederholungen definieren.
6. Mit realistischen und absichtlich schwierigen Fällen testen.
7. Jeden Lauf für Support und fachliche Prüfung sichtbar machen.
8. Erst nach messbarer Zuverlässigkeit weitere Rechte oder Teilagenten ergänzen.

Der Unterbau wird einfacher, Verantwortung nicht

Die Agents API verschiebt einen wichtigen Teil der Agenten-Infrastruktur in eine verwaltete Plattform. Das kann Teams viel eigene Orchestrierungsarbeit abnehmen. Es ersetzt aber weder Prozessdesign noch Zugriffskontrolle, Tests und einen klaren Verantwortlichen.

Der gute Start ist deshalb kein universeller digitaler Mitarbeiter. Es ist ein eng umrissener Auftrag, der Quellen zeigt, Grenzen respektiert, unterbrochen werden kann und am Ende ein überprüfbares Arbeitsergebnis liefert. Genau dort wird aus einer beeindruckenden Agenten-Demo ein nützliches Produkt.

Quellen

• OpenAI: Introducing the Agents API, 10. September 2026
• OpenAI Developers: Agents API Overview