OpenAI Agent Builder wird abgeschaltet: Was jetzt zu tun ist

OpenAI AgentKit bündelte OpenAIs Werkzeuge zum Entwickeln, Bereitstellen und Evaluieren von Agenten. Der zugehörige Dienst OpenAI Agent Builder soll am 30. November 2026 abgeschaltet werden. Das Agents SDK und ChatKit bleiben verfügbar. Wer eine ChatKit-App mit Agent Builder als Backend betreibt, braucht jedoch einen eigenen Ersatz für dieses Backend. Bestehende Evals werden am 31. Oktober schreibgeschützt; das Evals-Dashboard samt API sowie die API v1/prompts mit ihren wiederverwendbaren Prompt-Objekten sollen am 30. November abgeschaltet werden.

Am 14. Oktober 2026 anhand der aktuellen OpenAI-Dokumentation geprüft. Entscheidend ist, den Workflow, seine Prompts und die Tests zu sichern, die sein korrektes Verhalten belegen. Dafür braucht es getrennte Migrationsaufgaben mit jeweils klarer Zuständigkeit. OpenAIs Zeitplan für die Abschaltung liefert die Termine; die folgende Checkliste macht daraus konkrete Projektmeilensteine.

OpenAI Agent Builder: Was endet, was bleibt?

Der gehostete Builder wird eingestellt; OpenAIs Werkzeuge zur Agentenentwicklung bleiben bestehen. AgentKit fasste Werkzeuge zum Entwickeln, Bereitstellen und Evaluieren von Agenten zusammen. OpenAI Agent Builder stellte den visuellen Workflow-Editor bereit, ChatKit die einbettbare Chatoberfläche und Evals die Testumgebung. Bei der Migration müssen diese Komponenten einzeln betrachtet werden.

Das lässt sich mit einem eingerichteten Arbeitsraum vergleichen: Der Raum bot die Umgebung zum Bearbeiten und Ausführen, der Workflow beschreibt dagegen die eigentliche Aufgabe. Fällt der Raum weg, braucht die Arbeit einen neuen Ort. Deshalb müssen weder sämtliche Werkzeuge ersetzt noch der Modellanbieter gewechselt werden.

Die Abschalttermine stammen von OpenAIs Seite zu auslaufenden Diensten; die weiterhin verfügbaren Laufzeitoptionen sind in der Agentenübersicht dokumentiert. Die Ankündigungen wurden am 3. Juni 2026 veröffentlicht. Der Schreibschutz im Oktober und die Abschaltung im November sind zwei verschiedene Ereignisse.

Die Responses API wird mit dieser Ankündigung nicht eingestellt. Eine darauf aufbauende Anwendung kann trotzdem betroffen sein, wenn ihre Anfragen auf wiederverwendbare Prompt-Objekte verweisen. Der aufgerufene Endpunkt und die gespeicherten Ressourcen, von denen er abhängt, müssen getrennt betrachtet werden.

Wer muss jetzt handeln?

Handlungsbedarf besteht, sobald ein produktiver Workflow von Agent Builder, verwalteten Evals oder gespeicherten Prompt-Objekten abhängt. Das passende Ziel richtet sich danach, wo der Workflow laufen soll — nicht danach, welcher Produktname am ähnlichsten klingt.

Entwicklungsteams mit einer App für Kunden: Den Workflow exportieren und festlegen, wer seine Laufzeitumgebung verantwortet. Ein Support-Chatbot, der im eigenen Produkt laufen muss, braucht nach dem Ende des gehosteten Workflows einen funktionierenden Anwendungsdienst. Wer nur die sichtbare Oberfläche umzieht, lässt die entscheidende Abhängigkeit bestehen.

Verantwortliche für interne Abläufe: ChatGPT Workspace Agents kommen infrage, wenn die Aufgabe im ChatGPT-Workspace des Unternehmens ausgeführt werden kann. Ein regelmäßiges Kundenbriefing oder ein interner Rechercheassistent passt besser dazu als eine Integration in eine öffentliche Website. Die Prozessverantwortlichen sollten die Ergebnisse beurteilen, die Workspace-Administration die Zugriffsrechte prüfen.

Unternehmen vor einer Neuanschaffung: Jetzt einen Weg wählen, der bestehen bleibt. Bei einem Anbieterangebot auf Basis von Agent Builder sollten die künftige Laufzeitumgebung, der Lieferumfang der Migration und die Abnahmekriterien feststehen, bevor die Umsetzung freigegeben wird. Eine Demo, die im Übergangszeitraum funktioniert, beantwortet diese Fragen nicht.

Teams, die bereits das SDK oder direkt die Responses API nutzen: Möglicherweise gibt es keinen Builder-Workflow zu migrieren. Vor der Entwarnung sollten jedoch die Evaluierungspipeline und Verweise auf gespeicherte Prompts geprüft werden. Fehlen auch diese Abhängigkeiten, ist die Ankündigung allein kein Anlass, die App neu zu schreiben.

Agent-Builder-Workflows ins Agents SDK exportieren

OpenAI Agent Builder exportiert Workflow-Code und liefert damit die Grundlage für eine selbst betriebene Anwendung. Der aktuelle Migrationsleitfaden bietet Exporte für Python und TypeScript. Vor jeder Änderung sollte der vollständige Export gesichert werden, damit spätere Anpassungen mit dem Original vergleichbar bleiben. Anleitung zur Migration.

1. 1

   Workflow-Export kopieren

   Den Workflow öffnen, oben in der Navigation Code auswählen, dann Agents SDK und anschließend Python oder TypeScript. Den vollständigen Export ins eigene Repository kopieren und festhalten, welchen bereitgestellten Workflow er ersetzt.

2. 2

   Anwendung lauffähig machen

   Das passende SDK nach seiner aktuellen Schnellstartanleitung installieren und konfigurieren. Die vom Workflow erwarteten Tools und Zugangsdaten anbinden. Zuständigkeiten für Bereitstellung, Speicherung und Laufzeitbetrieb festlegen, bevor der Export als Ersatzdienst gilt.

3. 3

   Fachliches Verhalten nachweisen

   Repräsentative Eingaben mit dem Ersatz erneut durchspielen. Den gewählten Ausführungspfad, Tool-Argumente, das Verhalten bei Freigaben und das Endergebnis prüfen. Erst bereitstellen, wenn der Ersatz die Abnahmekriterien des Workflows erfüllt.

Das OpenAI Agents SDK führt die Agentenschleife aus; die Kontrolle über Bereitstellung, Speicherung, Tools und Freigaben liegt bei der eigenen Anwendung. Die SDK-Übersicht bleibt die maßgebliche Referenz für die Implementierung.

Die Grenze des SDK liegt bei der Betriebsverantwortung. Eine kopierte Datei liefert weder die Produktionsbereitstellung noch ein definiertes Neustartverhalten oder dauerhaft gespeicherten Zustand. Bei einem Support-Workflow muss feststehen, was nach einer Zeitüberschreitung bei der Bestellabfrage, einer verweigerten Freigabe oder einer erneut eingehenden identischen Anfrage passiert. Solche Fälle müssen umgesetzt und bei der Abnahme geprüft werden; eine Exportschaltfläche garantiert sie nicht.

Wenn auch die Verantwortung für den Laufzeitbetrieb neu bewertet wird, hilft der Vergleich von OpenAI Agents API und Agents SDK. OpenAIs aktueller Builder-Migrationsleitfaden nennt das SDK und Workspace Agents. Die separate verwaltete Agents API ist deshalb kein automatisches Importziel.

No-Code-Abläufe zu ChatGPT Workspace Agents verlagern

ChatGPT Workspace Agents ist der dokumentierte Weg für natürlichsprachlich beschriebene Workflows, die innerhalb eines Teams geteilt werden. OpenAIs Migrationsleitfaden setzt einen Business-, Enterprise- oder Edu-Workspace mit Agentenzugriff und der Berechtigung zum Erstellen von Agenten voraus. Dazu den Builder-Workflow exportieren, den Code in den Workspace-Agent-Builder einfügen und ihn auffordern, den Workflow nachzubauen. Voraussetzungen für die Workspace-Migration.

OpenAIs Praxisanleitung für Workspace Agents zeigt das zugrunde liegende Betriebsmodell: verbundene Apps, wiederverwendbare Anweisungen, zeitgesteuerte Aufgaben und die Freigabe innerhalb eines Workspaces. Das passt zu einem internen Kundenbriefing, dessen fertiges Ergebnis die verantwortliche Person prüfen kann.

Die entscheidende Grenze ist die Verhaltenstreue. OpenAI warnt, dass sich stark deterministische Workflows möglicherweise nicht originalgetreu übertragen lassen — also Abläufe, bei denen dieselben Bedingungen immer denselben vorgeschriebenen Pfad auslösen müssen. Verbindungen und Berechtigungen prüfen, mit Preview repräsentative Eingaben testen und erst nach der Validierung Create auswählen. Der Workflow wird neu erstellt; eine exakte Umwandlung jedes Knotens und jeder Verbindung ist nicht garantiert.

Ein interner Rechercheassistent kann beispielsweise unterschiedliche Recherchewege zulassen, solange das fertige Briefing die Anforderungen erfüllt. Muss ein Workflow dagegen vor jeder Änderung eines Kundendatensatzes zwingend eine Freigabe einholen, ist genau diese Grenze ausdrücklich zu prüfen. Hängt der Geschäftsprozess von exakten Verzweigungen ab, empfehle ich, diese Logik im Anwendungscode zu behalten und zuerst den Weg über das SDK zu validieren.

ChatKit behalten, das gehostete Backend ersetzen

ChatKit bleibt als Chatoberfläche nutzbar; die eigene Anwendung muss jedoch den Ersatzserver dahinter bereitstellen. OpenAI verweist neue Projekte und bestehende Apps mit Builder-Backend auf eine Integration mit eigenem Server. Bereits gehostete Workflows werden nur während des Übergangszeitraums unterstützt. Hinweise zur ChatKit-Umstellung.

Damit ändert sich die Arbeit hinter dem Chatfenster. In der künftig vorgesehenen Architektur sendet der Browser Anfragen an den eigenen ChatKit-Server. Dieser führt die Agentenimplementierung und ihre Tools aus; die Ergebnisse gelangen zurück zur Oberfläche. Ein unverändertes Erscheinungsbild erhält den bisherigen gehosteten Ausführungspfad nicht.

Der Leitfaden zur erweiterten Integration benennt die Bausteine: einen ChatKitServer, einen HTTP-Endpunkt, dauerhaften Speicher für produktive Konversationen und Nachrichten, einen Dateispeicher bei Upload-Unterstützung sowie Serverkontext für Identität und Berechtigungen. Er beschreibt außerdem die Anbindung an das Agents SDK.

Bei einer Kundensupport-App reicht es für die Abnahme nicht, dass irgendeine Antwort zurückkommt. Geprüft werden muss, ob angemeldete Kunden nur die vorgesehene Konversation sehen, Anhänge bei Bedarf weiter nutzbar sind, erlaubte Tools ausgeführt werden und Eskalationen weiterhin an der richtigen Stelle ankommen. Auch der Umgang mit bisherigen Gesprächsverläufen braucht einen Plan; sie werden nicht zwangsläufig mit dem Workflow-Export übertragen.

Der Leitfaden zum Erstellen eines Chatbots mit ChatKit behandelt die weitergehenden Produktaufgaben. Für diese Migration zählt vor allem, ob eine echte Konversation über das Ersatzbackend vollständig abläuft und dabei die erwarteten Zugriffs- und Aktionsregeln einhält.

Die Migrationscheckliste mit Terminen

Zuerst die Evaluierungsbasis sichern, dann Ausführung und Prompts vor der Abschaltung umziehen. Diese Basis besteht aus den Beispielen und akzeptablen Ergebnissen, anhand derer sich feststellen lässt, ob der Ersatz funktioniert. Ohne sie kann der Code erfolgreich umziehen, während das Verhalten verloren geht, auf das sich die Nutzer verlassen.

Vor dem 31. Oktober 2026: Evals exportieren und sichern

Jetzt die Verantwortung für die Evaluierung festlegen. Zu sichern sind Testeingaben, erwartete Ergebnisse, Definitionen der Bewertungsverfahren, Prompt-Versionen, Modelleinstellungen und wichtige bisherige Ergebnisse, die zum Verständnis des aktuellen Verhaltens nötig sind. Exportieren, was der vorhandene Workflow zugänglich macht. Wo kein Export möglich ist, die Konfiguration kopieren und außerhalb der Plattform nachbilden.

Der 31. Oktober markiert den Wechsel zum Schreibschutz, keinen dokumentierten letzten Exporttermin. Die Sicherung vorher abzuschließen, ist die hier empfohlene Projektfrist. So steht während der Migration eine nutzbare Vergleichsbasis bereit.

OpenAIs Leitfaden zur Evals-Migration empfiehlt Promptfoo und beschreibt, wie Prompts, Anbieter, Testfälle und Prüfaussagen manuell neu angelegt werden. Eine Exportfunktion von OpenAI Evals setzt er nicht voraus. Neu erstellte Bewertungsverfahren müssen erneut ausgeführt und validiert werden, bevor ihre Ergebnisse als verlässlich gelten. OpenAI weist darauf hin, dass Bewertungen zwischen Systemen abweichen können.

Eine brauchbare Übergabe umfasst eine ausführbare Evaluierungssuite und eine Erklärung, was als Fehler gilt. Ein Screenshot eines früheren Ergebnisses dokumentiert lediglich die Vergangenheit und ersetzt diese Testsuite nicht.

Vor dem 30. November 2026: Workflows und Prompt-Objekte umziehen

Vor der geplanten Abschaltung müssen diese Aufgaben erledigt sein:

• Den exportierten SDK-Workflow bereitstellen oder seinen Ersatz als Workspace Agent validieren und erstellen.
• Jede ChatKit-App mit Agent-Builder-Backend auf den Ersatzserver umstellen.
• Wiederverwendbare Prompt-Inhalte aus den verwalteten Prompt-Objekten herauslösen.
• Den neuen Evaluierungsprozess ausführen und Verhaltensänderungen untersuchen.
• Abhängigkeiten von auslaufenden Diensten aus dem Produktivbetrieb entfernen und die Verantwortung für den neuen Betriebsweg festlegen.

Nach Prompt-Objekten sollte die Anwendung gesondert durchsucht werden. Ein Workflow kann erfolgreich laufen, während ein anderes Feature noch von einer gespeicherten Prompt-ID abhängt. OpenAIs Leitfaden zur Prompt-Migration verlagert den Prompt-Text in den Quellcode, ersetzt Variablen durch Funktionsargumente und übergibt die erzeugten Nachrichten über input an die Responses API, statt das verwaltete prompt-Objekt zu nutzen. Der Prompt sollte zusammen mit der Anwendung versioniert werden. Wo praktikabel, bleibt vor den dynamischen Werten ein stabiles gemeinsames Präfix erhalten.

Bei einem Abrechnungsassistenten umfasst das Ergebnis den vollständigen Anweisungssatz, seine Variablenersetzungen und die erwarteten Antworten auf repräsentative Fälle. Nur den sichtbaren Absatz zu kopieren, dabei aber eine Variable zu verlieren oder die falsche gespeicherte Version zu wählen, ergibt keine vollständige Migration.

Der eigene Umstellungstermin sollte vor der Frist des Anbieters liegen und genug Zeit lassen, um fehlgeschlagene Tests zu untersuchen. Für den verbleibenden Übergangszeitraum braucht es eine dokumentierte Rückfalllösung. Hängt sie selbst noch von einem eingestellten Dienst ab, bietet sie nach dessen Abschaltung keinen Schutz mehr.

Welche Aussagen führen in die Irre?

„AgentKit wird abgeschaltet“ ist als Grundlage für eine technische Entscheidung zu pauschal. Die Ankündigungen benennen konkrete Produkte und gespeicherte Ressourcen. Für SDK, ChatKit, Responses API und die separate Agents API bleibt die Dokumentation bestehen; migriert werden müssen die betroffenen gehosteten Dienste.

Ein Export beweist keine Funktionsgleichheit. Ein erzeugter Ersatz kann eine überzeugende Antwort liefern und dabei den Pfad überspringen, der eine Freigabe verlangt hätte. Maßgeblich ist das beobachtbare Verhalten im Vergleich zu den ursprünglichen Anforderungen — nicht, ob das neue Diagramm oder der Code vertraut aussieht.

Dass ChatKit bestehen bleibt, erhält das Builder-Hosting nicht. Die Oberfläche kann gleich bleiben, während der ausführende Dienst wechselt. Dafür muss Entwicklungs- und Betriebsverantwortung eingeplant werden, ohne pauschal ein neues Frontend vorauszusetzen.

Mit der Abschaltung von Evals entfällt der Bedarf an Evaluierungen nicht. Die Verantwortung für die Pflege der Tests verlagert sich. Ebenso stellt ein in den Code verschobener Prompt die Responses API nicht infrage; er ändert, wie die Anwendung ihr Anweisungen übergibt.

Häufige Fragen zur weiteren Nutzung von AgentKit

Ist OpenAI AgentKit kostenlos?

Eine Migration sollte nicht auf der Annahme beruhen, AgentKit sei ein einzelnes kostenloses Produkt. Zuerst eine weiterhin verfügbare Laufzeitumgebung wählen und anschließend deren aktuelle Modell-, Tool- und Infrastrukturkosten prüfen. Aus den Abschaltungsankündigungen lässt sich kein allgemeingültiger Preis für die Migration ableiten.

Wie lassen sich OpenAI-Agenten nutzen?

Einen bestehenden Agent-Builder-Workflow ins Agents SDK exportieren oder als Workspace Agent neu erstellen. Für eine neue App eine aktuelle Laufzeitumgebung wählen und die Tools und Berechtigungen testen, die die Aufgabe erfordert. Eine ChatKit-Oberfläche benötigt eine serverseitige Implementierung.

Was können OpenAI-Agenten übernehmen?

Agenten können Tools nutzen und mehrstufige Aufgaben bearbeiten. Eine sinnvolle Migration beginnt mit der konkreten Aufgabe, auf die der Betrieb bereits angewiesen ist — etwa einem internen Briefing oder der Bearbeitung einer authentifizierten Supportanfrage. Deren erforderliches Verhalten muss auf der neuen Laufzeitumgebung erhalten bleiben.

Der erste Schritt für die nächste Arbeitswoche

Eine verantwortliche Person für die Migration benennen und einen repräsentativen produktiven Workflow auswählen. Dessen Export, Prompt-Inhalte und Evaluierungsbasis sichern und anschließend einen Ersatz vollständig durchlaufen lassen. Das Ergebnis dient dazu, den Aufwand für die übrigen Workflows abzuschätzen. Das erste Arbeitsergebnis sollte belegen, dass eine benötigte Aufgabe mit den richtigen Berechtigungen und Ergebnissen abgeschlossen wird. Darauf folgt der Terminplan für den restlichen Umzug.

Praktische Updates zum Entwickeln und Betreiben von KI-Workflows gibt es im Newsletter.