So bauen Sie einen AI Agent mit OpenAI Assistants (jetzt die Responses API)
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Mit der Assistants API von OpenAI konnten Entwickler agentenähnliche Anwendungen mit persistenten Gesprächs-Threads, Dateiabruf, Code-Ausführung und Function Calling bauen, ohne all diesen Zustand von Hand zu verwalten. Sie war wichtig, und für bestehende Integrationen läuft sie heute noch. Doch OpenAI kündigte die Abkündigung am 26. August 2025 an, mit vollständiger Abschaltung am 26. August 2026, und lenkt seither alle Neuentwicklung auf die Responses API und das Agents SDK. Wenn Sie ein neues Projekt starten, bauen Sie dort. Dieser Leitfaden behandelt, was die Assistants API leistete, was sie ersetzt und wie Sie heute tatsächlich einen Agent mit den aktuellen OpenAI-Tools bauen.
Was die Assistants API war und warum sie verschwindet
Die 2023 auf der Entwicklerkonferenz von OpenAI vorgestellte Assistants API gab Entwicklern vier Kernbausteine an die Hand: einen Assistant (der konfigurierte Agent mit Anweisungen und Tools), einen Thread (ein persistentes Gespräch), einen Run (eine Ausführung des Assistants auf einem Thread) und Run Steps (die einzelnen Aktionen während eines Runs). Dazu kamen Retrieval über hochgeladene Dateien, ein Code Interpreter und Function Calling. Eine Zeit lang war das der schnellste Weg, einen zustandsbehafteten Agent mit Tools aufzusetzen, ohne diese Infrastruktur selbst zu bauen.
Das Problem war, in den Worten von OpenAI selbst, die Komplexität. Als das Unternehmen im März 2025 die Responses API auslieferte, erklärte es klar, jede Funktion der Assistants in die einfachere API zu übernehmen und das Original abzuschalten. Es hat Wort gehalten: Die Abkündigung ging am 26. August 2025 an die Entwickler, die Entfernung aus der API folgt genau ein Jahr später. Der Migrationsleitfaden von OpenAI bestätigt, dass beim Umstieg keine Funktionalität verloren geht: Funktionen werden neu geordnet, nicht gestrichen.
Was sie ersetzt: die Responses API und das Agents SDK
Die Responses API ist keine Umbenennung, sondern ein wirklich einfacheres Modell: Sie senden Input Items und erhalten Output Items direkt zurück, ohne ein Run-Objekt zu pollen, bis sich sein Status ändert. Vier Konzepte der Assistants entsprechen vier Konzepten der Responses.
| Assistants API | Entsprechung in der Responses API | Was sich geändert hat |
|---|---|---|
| Assistants | Prompts | Die Konfiguration liegt jetzt im Dashboard mit integrierter Versionierung, statt vollständig über API-Aufrufe verwaltet zu werden |
| Threads | Conversations | Erweitert: speichern mehr als Nachrichten, nämlich Tool-Aufrufe, Ausgaben und weitere Item-Typen |
| Runs | Responses | Sie senden Input und erhalten Output direkt, keine Polling-Schleife nötig |
| Run Steps | Items | Verallgemeinerte Objekte, die die ganze Bandbreite der Daten abdecken, die eine Response enthalten kann |
Die Responses API liefert außerdem fünf integrierte Tools, die Sie nicht selbst bauen müssen: Websuche, Dateisuche, Code Interpreter, Computer Use und Verbindungen zu Remote-MCP-Servern. Die Dateisuche ist der direkte Nachfolger der Retrieval-Funktion der Assistants API, also desselben Musters der Dokumentenverankerung, das in RAG für AI Agents und auf Musterebene im RAG-Assistant-Muster behandelt wird.
Für alles jenseits eines einzelnen Agents bietet OpenAI außerdem das Agents SDK, den produktionsreifen Nachfolger des früheren experimentellen Frameworks „Swarm“. Die Responses API liefert den Baustein, ein Aufruf hinein, eine Antwort heraus. Das Agents SDK liefert die Orchestrierung drumherum: Agents (ein Modell plus Anweisungen und Tools), Handoffs (ein Agent delegiert eine Aufgabe an einen anderen) und Guardrails (Prüfung dessen, was hineingeht und was herauskommt). OpenAI selbst formuliert es direkt: Nutzen Sie die Responses API, wenn Sie den Agent-Loop selbst besitzen wollen, und das Agents SDK, wenn das SDK diesen Loop für Sie ausführen soll. Zu den Ergänzungen des SDK im Jahr 2026 zählen die native Integration der Realtime API für Voice Agents und erstklassige Unterstützung für Model Context Protocol-Server, sodass jedes Tool, das MCP spricht, ohne eigenen Verbindungscode anbindbar wird.
Der Bauablauf
- Entscheiden Sie, wem der Loop gehört. Für einen einzelnen, recht einfachen Agent rufen Sie die Responses API direkt auf und steuern den Zyklus aus Input, Output und Function Call in Ihrem eigenen Code. Für mehrere zusammenarbeitende Agents, oder wenn Sie diesen Loop nicht selbst schreiben möchten, beginnen Sie mit dem Agents SDK.
- Schreiben Sie die Anweisungen des Agents. Das sind die Bausteine Rolle und Regeln aus wie man einen AI Agent baut, als System-Prompt formuliert: wofür der Agent zuständig ist und was er niemals tun darf.
- Hängen Sie integrierte Tools nach Bedarf an. Dateisuche, wenn er aus Ihren eigenen Dokumenten antworten soll, Websuche für aktuelle Informationen, Code Interpreter für Berechnungen, Computer Use nur, wenn er wirklich eine Oberfläche bedienen muss.
- Binden Sie eigene Function-Calling-Tools für Ihre Systeme an. Definieren Sie für jede Funktion ein JSON-Schema (Name, Parameter, Beschreibung). Das Modell fordert einen Aufruf mit bestimmten Argumenten an, Ihr Anwendungscode führt ihn tatsächlich gegen Ihr CRM, Ihre Datenbank oder Ihre API aus und gibt das Ergebnis zurück, damit das Modell darauf aufbauend weiter schlussfolgert. Das ist dieselbe Tool-Calling-Mechanik, die in wie AI Agents Tools nutzen ausführlich behandelt wird.
- Nutzen Sie Conversations für alles, was über Sessions hinweg bestehen bleiben muss, den direkten Nachfolger der Threads der Assistants.
- Ergänzen Sie Handoffs, wenn sich die Aufgabe sauber auf spezialisierte Agents aufteilen lässt, dasselbe Orchestrierungsmuster wie in Multi-Agent-Systeme.
- Ergänzen Sie Guardrails, um Inputs und Outputs zu prüfen, und fügen Sie Tracing hinzu (die Sentry-native Integration des SDK oder Ihr eigenes Logging), damit Sie genau sehen, welche Tools liefen und warum, bevor Sie dem Agent echtes Volumen anvertrauen.
- Deployen Sie ihn hinter Ihrem eigenen Backend. Es gibt hier keinen visuellen Host; Server, Authentifizierung und Retry-Logik liegen bei Ihnen.
Die Umsetzung führt von Loop-Verantwortung und Anweisungen über Tools, persistenten Zustand, Handoffs und Guardrails bis zum Tracing.
Ein Praxisbeispiel: ein AI Knowledge-Base-Agent
Ein Knowledge-Base-Agent passt natürlich zur Responses API, denn er stützt sich direkt auf das integrierte Dateisuche-Tool statt auf eigenen Retrieval-Code.
Ein Nutzer stellt eine Frage. Die Anweisungen des Agents beschränken ihn darauf, ausschließlich aus einem hochgeladenen, indexierten Satz von Unternehmensdokumenten zu antworten, angebunden über das Dateisuche-Tool. Er sucht, findet die relevanten Passagen und antwortet mit einem Zitat zurück auf das Quelldokument statt mit einer bloßen Behauptung. Liefert die Dateisuche keinen sicheren Treffer, weisen die Anweisungen ihn an, das ausdrücklich zu sagen, statt zu raten. Und ein eigenes Function-Calling-Tool lässt ihn die Frage an eine menschliche Warteschlange eskalieren, wenn er nicht antworten kann.
Das ist dieselbe Struktur aus Regeln und Leitplanken, die der Blueprint zum AI Knowledge Base Agent vollständig spezifiziert: auf freigegebene Quellen beschränken, angeben, woher die Antwort stammt, eskalieren statt raten. Ihn auf der Responses API zu bauen heißt vor allem, das Dateisuche-Tool und die Eskalationsfunktion anzubinden und dann dem Schlussfolgern des Modells zu überlassen, wann was greift.
Kosten und Grenzen
Die API von OpenAI rechnet nach Tokens ab (Input und Output getrennt bepreist, je nach Modell unterschiedlich), und die integrierten Tools haben jeweils eigene Messgrößen: Websuche und Dateisuche berechnen pro Aufruf oder nach gespeichertem Dokumentvolumen, Code Interpreter und Computer Use berechnen die Rechenzeit, die sie laufen. Die Preise ändern sich oft genug, dass Sie direkt auf der Preisseite von OpenAI nachsehen sollten, statt irgendeine Zahl hier als aktuell zu behandeln. Für die Planung zählt die Form der Kosten: nutzungsbasiert über mehrere getrennte Messgrößen statt eines einzigen Pauschalpreises. Lesen Sie daher Gesamtbetriebskosten von AI, bevor Sie einen aufwendigen Dauerbetrieb-Agent anhand der Rechnung eines kleinen Pilotprojekts hochrechnen.
Die größere Grenze ist für die meisten Teams nicht der Preis, sondern dass dieser Weg gar keinen visuellen Builder bietet. Alles, was n8n, Make oder Lindy für Sie übernehmen (Hosting, Retries, eine Oberfläche, über die Nicht-Entwickler den Agent anpassen), ist hier Aufgabe Ihres Teams. Diesen Kompromiss sollte man klar benennen: Sie erhalten direkten Zugriff auf die Modelle und Tools von OpenAI mit der geringsten Abstraktion zwischen Ihnen und der API, und dafür verantworten Sie die gesamte Laufzeit selbst. Und wenn Sie eine bestehende Integration der Assistants API haben, ist die Migration nicht optional. Sie muss vor dem 26. August 2026 erfolgen, anhand der obigen Zuordnung, sonst funktioniert die Integration schlicht nicht mehr.
Wann dies, wann Alternativen
| Wenn Sie ... wollen | Wählen Sie |
|---|---|
| Volle Code-Kontrolle direkt auf den Modellen von OpenAI, minimale Abstraktion, Ihr Team schreibt ohnehin Software | Responses API und Agents SDK von OpenAI |
| Den schnellsten Weg zu einem funktionierenden Agent ganz ohne Code | Lindy |
| Den breitesten vorgefertigten App-Katalog mit visuellem Builder | Make |
| Self-Hosting mit visueller Arbeitsfläche plus Ausweg in Code | n8n |
Diese Optionen schließen sich nicht strikt aus. n8n, Make und Lindy können alle die Modelle von OpenAI als Schlussfolgerungs-Engine hinter einem auf ihrer Plattform gebauten Agent aufrufen; Sie wählen eine Orchestrierungsschicht, nicht zwingend gegen die Modelle von OpenAI selbst. Bauen Sie direkt auf der Responses API und dem Agents SDK, wenn Ihr Team ohnehin Code ausliefert und möglichst wenige Schichten zwischen Anwendung und Modell möchte. Greifen Sie zu einer visuellen Plattform, wenn Sie etwas Low-Level-Kontrolle gegen schnellere Iteration und einen Builder tauschen wollen, den auch Nicht-Entwickler anfassen können. Die Dringlichkeit hinter dieser Wahl ist real: Gartner prognostiziert, dass bis Ende 2026 40 % der Unternehmensanwendungen aufgabenspezifische AI Agents enthalten werden, nach unter 5 % im Jahr 2025. Genau so eine Adoptionskurve macht es heute zur falschen Wette, auf einer Plattform zu bauen, die OpenAI aktiv abschaltet.
Key Facts
- OpenAI kündigte die Abkündigung der Assistants API am 26. August 2025 an, mit vollständiger Abschaltung am 26. August 2026. Neue Projekte sollten stattdessen auf der Responses API aufbauen.
- Die Responses API ersetzt vier Konzepte der Assistants: Assistants werden zu Prompts, Threads zu Conversations, Runs zu Responses und Run Steps zu Items.
- Die Responses API liefert fünf integrierte Tools: Websuche, Dateisuche, Code Interpreter, Computer Use und Verbindungen zu Remote-MCP-Servern.
- Das Agents SDK, ein produktionsreifer Nachfolger des experimentellen Swarm-Frameworks von OpenAI, ergänzt Agents, Handoffs und Guardrails zur Koordination mehrerer Agents.
- Gartner prognostiziert, dass bis Ende 2026 40 % der Unternehmensanwendungen aufgabenspezifische AI Agents enthalten werden, nach weniger als 5 % im Jahr 2025.
Häufig gestellte Fragen zum Bau eines AI Agents mit OpenAI Assistants
Ist die OpenAI Assistants API 2026 noch nutzbar?
Ja, bis zum Abschaltdatum 26. August 2026, danach wird sie vollständig aus der API entfernt. Bestehende Integrationen laufen bis dahin weiter, doch OpenAI lenkt seit der Ankündigung der Abkündigung am 26. August 2025 alle Neuentwicklung auf die Responses API und das Agents SDK.
Was ersetzt die Assistants API?
Die Responses API, die dieselben Fähigkeiten (persistenter Zustand, Retrieval, Code-Ausführung, Function Calling) in einem Modell vereint und vereinfacht, in dem Sie Input Items senden und Output Items direkt zurückerhalten, ohne ein Run-Objekt zu pollen. Zur Koordination mehrerer Agents setzt das Agents SDK von OpenAI auf der Responses API auf und ergänzt Handoffs und Guardrails.
Muss ich meine bestehende Integration der Assistants API migrieren?
Ja, vor dem 26. August 2026. Der Migrationsleitfaden von OpenAI ordnet jedes Konzept der Assistants seinem Gegenstück in der Responses API zu (Assistants zu Prompts, Threads zu Conversations, Runs zu Responses, Run Steps zu Items) und bestätigt, dass keine Funktionalität verloren geht, sondern nur neu geordnet wird.
Worin unterscheiden sich die Responses API und das Agents SDK?
Die Responses API ist der zugrunde liegende Baustein: Sie senden eine Anfrage und erhalten eine Antwort, und der Loop aus wiederholtem Aufrufen, Ausführen von Function Calls und Zurückspeisen der Ergebnisse liegt bei Ihnen. Das Agents SDK baut darauf auf und führt den Loop für Sie aus, mit Multi-Agent-Handoffs und Input/Output-Guardrails, nützlich, sobald die Logik eines einzelnen Agents komplex genug für diese Struktur wird.
Kann ich einen AI Agent auf den Modellen von OpenAI ohne Code bauen?
Nicht direkt über die eigenen APIs von OpenAI, denn es gibt keinen visuellen Builder. Plattformen wie n8n, Make und Lindy können die Modelle von OpenAI als Schlussfolgerungs-Engine hinter einem visuell gebauten Agent aufrufen, der zugänglichere Weg, wenn Ihr Team den Orchestrierungs-Code nicht selbst schreiben und hosten möchte.
Wie es weitergeht
Wenn Ihr Team ohnehin Software schreibt und möglichst wenige Schichten zwischen Ihrem Code und den Modellen von OpenAI möchte, sind die Responses API und das Agents SDK der richtige Startpunkt, nur eben dort statt auf der API, die abgeschaltet wird. Wenn Sie lieber visuell bauen, lesen Sie wie man einen AI Agent mit n8n baut, wie man einen AI Agent mit Make baut oder wie man einen AI Agent mit Lindy baut, je nachdem, wie viel Kontrolle gegenüber Tempo Sie brauchen. Die Übersicht Dev-Tools und der Leitfaden wie man eine AI-Chatbot-Plattform auswählt sind sinnvolle nächste Stationen, wenn Sie die eigenen Tools von OpenAI noch mit einer gehosteten Plattform vergleichen.
