+220 XP

Capstone: ein echter End-to-End-Workflow mit ChatGPT

In dieser Lektion bauen Sie ein realistisches System von Anfang bis Ende. Es ist ein Kundensupport-Assistent für ein kleines SaaS-Unternehmen. Er beantwortet Fragen aus einer Wissensdatenbank, ruft aktuelle Bestell- und Kontodaten ab, eskaliert schwierige Tickets an einen Menschen und schickt dem Gründer jeden Montag per E-Mail einen wöchentlichen Health-Report. Die einzelnen Bausteine kennen Sie bereits. In dieser Lektion geht es darum, sie zu verbinden und, noch wichtiger, **zu entscheiden, *welchen* Baustein Sie wo einsetzen**.

Szenario und Rahmenbedingungen

„SupportBot“ muss vier Dinge leisten:

  1. Produktfragen aus internen Dokumenten beantworten.
  2. Das aktuelle Abo und die letzten Tickets eines Kunden nachschlagen.
  3. An einen Menschen übergeben, wenn die Sicherheit gering oder der Kunde verärgert ist.
  4. Einen wöchentlichen Report zu Ticketvolumen, Lösungszeit und Top-Themen erstellen.

Die Rahmenbedingungen, die jede Entscheidung bestimmen: Das Team besteht aus zwei Personen, die Dokumente ändern sich wöchentlich, und die Kundendaten liegen in einer Postgres-Datenbank und in Zendesk. Sie führen uns für unterschiedliche Aufgaben zu unterschiedlichen Oberflächen.

Entscheidung 1: Custom GPT oder API?

Das ist die zentrale Weggabelung der Architektur, also klären Sie sie zuerst.

Ein Custom GPT (konfiguriert auf chatgpt.com, geteilt über den GPT Store, einen privaten Link oder Ihren Workspace) ist der richtige Ort für den *intern genutzten* Assistenten. Ihre beiden Support-Mitarbeiter öffnen ihn in ChatGPT, fügen eine Kunden-E-Mail ein und erhalten einen Antwortentwurf, der auf Ihren Dokumenten basiert. Kein Hosting, kein Auth-Code. Ihre API ist über Actions erreichbar.

Die API (die Responses API) ist der richtige Ort für alles, was kundenseitig oder automatisiert läuft: das Widget auf Ihrer Website, den nächtlichen Report-Job. Sie brauchen programmatische Kontrolle, eigene Authentifizierung, Logging und die Möglichkeit, ohne einen Menschen in der Schleife zu laufen.

Die Antwort lautet also: beides, aufgeteilt nach Zielgruppe:

  • Entwurfstool für die Mitarbeiter: Custom GPT.
  • Website-Widget und geplanter Report: API.

Zwingen Sie nicht eine einzige Oberfläche, alles zu erledigen. Der Custom GPT ist Ihr schneller Weg, die API Ihr belastbarer Weg.

Entscheidung 2: Wie die Dokumente in die Antwort kommen

Die Dokumente ändern sich wöchentlich, deshalb kommt es auf die Grounding-Strategie an.

Auf der ChatGPT-Seite verknüpfen Sie über die Google-Drive-App (ChatGPT hat „Connectors“ Ende 2025 in „Apps“ umbenannt) den Live-Ordner, in dem das Team die Dokumente pflegt. ChatGPT durchsucht diese Quelle zum Zeitpunkt der Anfrage, eine Änderung am Montag ist also am Montag sichtbar. Statische Dateien im Wissen des GPT würden veralten und müssten neu hochgeladen werden. Prüfen Sie auf help.openai.com, welche Apps Ihr Plan unterstützt und wie Admins sie steuern, denn die Verfügbarkeit in Custom GPTs hängt vom Plan ab.

Beim API-basierten Widget sind Sie für das Retrieval selbst zuständig. Entweder betreiben Sie eine eigene Vektorsuche und übergeben die Ergebnisse im Prompt, oder Sie nutzen file search als gehostetes Tool der Responses API. Für ein Zwei-Personen-Team ist gehostetes file search die pragmatische Wahl, weil weniger Infrastruktur zu betreuen ist. Ein wöchentlicher Cron-Job synchronisiert die Dokumente neu in den Vector Store.

Entscheidung 3: Live-Daten über Actions oder function calling

Der Assistent braucht getCustomer(email) und getRecentTickets(customerId). Dieselbe Fähigkeit, zwei Implementierungen, je nach Oberfläche.

Im Custom GPT stellen Sie diese als GPT Actions bereit: eine OpenAPI-Spezifikation, die auf Ihre interne API zeigt, mit Authentifizierung, die im GPT-Builder konfiguriert wird. Das Modell entscheidet, wann es sie aufruft.

Im API-Widget werden dieselben Operationen zu function calling mit strikten Schemas, sodass die Argumente jedes Mal als schemakonformes JSON ankommen. Hier die Tool-Definition für die Responses API:

python
from openai import OpenAI

client = OpenAI()

tools = [{
    "type": "function",
    "name": "get_customer",
    "description": "Look up a customer's subscription and account status by email.",
    "parameters": {
        "type": "object",
        "properties": {
            "email": {"type": "string", "description": "Customer email address"}
        },
        "required": ["email"],
        "additionalProperties": False
    },
    "strict": True
}]

response = client.responses.create(
    model="gpt-5",
    input="What plan is taylor@acme.com on, and is their account in good standing?",
    tools=tools
)

print(response.output)

strict: True ist der Teil, den Sie verinnerlichen sollten. Er garantiert, dass die Argumente des Modells Ihrem Schema entsprechen, Ihr Backend muss also nie defensiv ein fehlerhaftes E-Mail-Feld parsen. Wählen Sie das Modell auf der Models-Seite. Eine kleinere Variante wie gpt-5-mini reicht für Lookups oft aus und senkt die Kosten bei einem stark genutzten Widget. Der Guide zu function calling beschreibt die komplette Schleife, einschließlich der Frage, wie Sie das Tool-Ergebnis für die finale Antwort des Modells zurückschicken.

Dieselben OpenAPI-Operationen stehen hinter Ihren GPT Actions und Ihren function-calling-Tools. Die API einmal schreiben, zweimal bereitstellen.

Entscheidung 4: Eskalation und die Grenze zum Menschen in der Schleife

Lassen Sie einen Support-Bot nie selbstständig eine Erstattung zusagen oder ein Ticket schließen. Bauen Sie ein explizites Eskalations-Tool, escalate_to_human(reason, urgency), und weisen Sie das Modell an, es aufzurufen, wenn der Kunde verärgert ist, nach Geld fragt oder die Dokumente die Frage nicht abdecken.

Machen Sie Eskalation zu einem vollwertigen Tool mit eigenem strikten Schema. Wird es aufgerufen, legt Ihr Code die Konversation in eine Zendesk-Queue und teilt dem Kunden mit, dass sich ein Mensch darum kümmert. Aus „Der Bot lag falsch“ wird „Der Bot kannte seine Grenzen“, und genau das unterscheidet einen nützlichen Assistenten von einem Haftungsrisiko.

Entscheidung 5: Wo das Modell orchestriert und wo Ihr Code

Bei mehreren Tools und mehrstufiger Logik (Kunde nachschlagen, Tickets prüfen, zwischen Antwort und Eskalation entscheiden) haben Sie mehrere Optionen:

  • Das Modell über die Tool-Schleife der Responses API orchestrieren lassen. Einfach, gut für lineare Abläufe.
  • Das Agents SDK nutzen, wenn Sie typisierte Agents, Handoffs zwischen spezialisierten Agents (ein „Billing-Agent“ und ein „Technik-Agent“), Guardrails und Tracing wollen. Für das Eskalations- und Handoff-Muster von SupportBot lohnt sich das Agents SDK, weil Handoffs als Primitiv eingebaut sind.
  • AgentKit nutzen, das im Oktober 2025 gestartet ist. Mit Agent Builder legen Sie denselben Workflow visuell an. ChatKit liefert eine einbettbare Chat-UI, sodass Sie das Frontend des Website-Widgets womöglich nicht selbst bauen müssen.

Der ChatGPT agent (der Agent in ChatGPT, der browst, klickt und mehrstufig arbeitet) eignet sich hervorragend für einmalige Untersuchungen wie „Finde alle offenen Tickets, die den neuen Billing-Bug erwähnen.“ Produktiven Traffic lassen Sie dort nicht laufen. Nutzen Sie ChatGPT agent zur Exploration und das Agents SDK oder AgentKit für das produktive System.

Entscheidung 6: Der Wochenreport

Hier spielt Code Interpreter (Datenanalyse) seine Stärken aus. Der Report braucht echte Berechnungen: den Median der Lösungszeit, die Veränderung der Tickets gegenüber der Vorwoche, ein Diagramm der häufigsten Problemkategorien.

Sie haben zwei saubere Optionen.

Option A: ein geplanter Task in ChatGPT. ChatGPT-Tasks führen einen Prompt nach einem wiederkehrenden Zeitplan aus und benachrichtigen Sie mit dem Ergebnis. Tasks laufen aus einer normalen ChatGPT-Konversation heraus, nicht innerhalb eines Custom GPT. Schreiben Sie die Anweisungen in den Task selbst, zum Beispiel: „Fasse jeden Montag um 8 Uhr die Tickets der Vorwoche aus dem Zendesk-Export in meinem Project zusammen, berechne die Lösungsstatistiken und markiere die drei wichtigsten Themen.“ Das ist die Option mit dem geringsten Aufwand, es gibt keinen Code zu hosten, aber prüfen Sie, welche Tools ein Task in Ihrem Plan nutzen kann.

Option B: ein API-Job auf Ihrem eigenen Cron. Ein kleines Skript fragt Postgres ab, übergibt die Zeilen an das Modell mit dem Code-Interpreter-Tool, das die Zahlen auswertet und ein Diagramm erzeugt, und verschickt das Ergebnis per E-Mail. Sie haben mehr Kontrolle, und das Ganze ist versioniert und testbar. Wählen Sie diese Option, wenn der Report in nachgelagerte Prozesse einfließt oder der Gründer jedes Mal dasselbe Format braucht.

Für ein Zwei-Personen-Team starten Sie mit Option A. Wechseln Sie zu Option B, wenn der Report geschäftskritisch wird oder unbeaufsichtigt Live-Daten abrufen soll.

Building a Customer Support Agent with the OpenAI Agents SDK

Watch on YouTube

Wissenscheck

1. Warum wird im SupportBot-Design für das Entwurfstool der Mitarbeiter ein Custom GPT statt der API gewählt?

2. Die Lektion kommt zu dem Schluss, dass die Antwort auf „Custom GPT oder API?“ „beides“ lautet. Welches Prinzip steht hinter dieser Aufteilung?

3. Die Dokumente ändern sich wöchentlich. Warum zieht die Lektion es vor, einen Live-Ordner in Google Drive über Connectors zu verknüpfen, statt statische Dateien in das Wissen des GPT hochzuladen?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aufgaben im SupportBot-Szenario aus, die besser über die API als über den Custom GPT abgedeckt werden.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Rahmenbedingungen aus, die laut der Lektion die Architekturentscheidungen für SupportBot bestimmen sollten.

Wählen Sie alle richtigen Antworten aus.

Die Oberflächen zusammenführen

Hier das Gesamtbild, Oberfläche für Oberfläche:

AufgabeOberflächeWarum
Mitarbeiter entwerfen AntwortenCustom GPT + Apps + ActionsSchnell, kein Hosting, Live-Dokumente
Chat-Widget auf der WebsiteResponses API + file search + function calling (ChatKit für die UI)Programmatisch, eigene Auth und eigenes Logging
Multi-Agent-Routing und EskalationAgents SDK oder Agent BuilderHandoffs und Guardrails sind eingebaut
WochenreportChatGPT-Task (Einstieg), dann API + Code Interpreter (Skalierung)Echte Berechnungen nach Zeitplan

Eine Backend-API bedient die Lookups, bereitgestellt als Actions für den GPT und als Function-Tools für die API. Eine Dokumentquelle (der Drive-Ordner) speist sowohl die ChatGPT-App als auch den file-search-Sync. Sie bauen keine vier Systeme. Sie bauen zwei Integrationspunkte, Ihre API und Ihre Dokumente, und richten mehrere Oberflächen darauf aus.

Memory, Projects und Anweisungen

Einige ChatGPT-Funktionen verbessern das Tool für die Mitarbeiter ganz unauffällig:

  • Legen Sie die Tonalitätsregeln von SupportBot, die Eskalationsrichtlinie und die Regel „immer das Dokument zitieren“ in den Anweisungen des Custom GPT ab, nicht in jedem Prompt.
  • Bündeln Sie die Support-Arbeit des Teams in einem Project, damit Konversationen, Dateien und Anweisungen zusammenbleiben, getrennt von der übrigen ChatGPT-Nutzung.
  • Lassen Sie Memory für die Support-Arbeit ausgeschaltet. Sie wollen nicht, dass es Annahmen zwischen Kunden überträgt, die nichts miteinander zu tun haben. Memory ist ideal für einen persönlichen Assistenten und riskant für ein gemeinsam genutztes Support-Tool.

Ein Hinweis zu Canvas und Codex

Wenn Sie die Report-Vorlagen oder die E-Mail-Texte schreiben, ist Canvas die bessere Bearbeitungsoberfläche als der Chat, weil Sie direkt im Dokument iterieren. Die Implementierung (das Responses-API-Skript, die OpenAPI-Spezifikation, der Cron-Job) ist genau das, wofür Codex gedacht ist. Lassen Sie damit das Grundgerüst der function-calling-Schleife und die Postgres-Abfrage erstellen, und prüfen Sie dann jede Zeile, bevor sie mit Kundendaten in Berührung kommt.

Fehlerfälle, die Sie einplanen sollten

Legen Sie vor dem Release fest, was passiert, wenn etwas ausfällt:

  • Die Lookup-API ist nicht erreichbar. Ihre Funktion sollte ein klares Fehlerobjekt zurückgeben, und in den Anweisungen des Modells sollte stehen: „Wenn ein Lookup fehlschlägt, eskaliere, statt zu raten.“
  • Das Modell erfindet eine Richtlinie. Beschränken Sie es darauf, nur aus abgerufenen Dokumenten zu antworten. Liefert das Retrieval nichts Relevantes, soll es das sagen und eskalieren.
  • Rate Limits oder Kostenspitzen. Loggen Sie den Token-Verbrauch pro Konversation. Das Website-Widget ist Ihre Oberfläche ohne Obergrenze, also begrenzen Sie die Konversationslänge und bauen Sie einen Fallback auf die Übergabe an einen Menschen ein.

Entwerfen Sie das zuerst auf Papier. Jetzt zu entscheiden ist günstiger, als später in Produktion zu debuggen.

Das Wichtigste in Kürze

  • Nach Zielgruppe aufteilen, nicht nach Feature. Ein Custom GPT bedient Ihr internes Team (schnell, kein Hosting). Die Responses API übernimmt kundenseitige und automatisierte Abläufe (Kontrolle, Logging, Auth).
  • Bauen Sie das Backend einmal und stellen Sie es zweimal bereit. Dieselben OpenAPI-Operationen stehen hinter Ihren GPT Actions und Ihren function-calling-Tools, und ein einziger Dokumentordner speist sowohl die ChatGPT-App als auch file search.
  • Machen Sie Eskalation zu einem vollwertigen Tool mit striktem Schema. Weisen Sie das Modell an, bei Fehlern oder geringer Sicherheit zu eskalieren, statt zu raten.
  • Starten Sie auf der Oberfläche mit dem geringsten Aufwand und wechseln Sie, wenn die Aufgabe geschäftskritisch wird. Ein ChatGPT-Task kann die ersten Wochenreports übernehmen. Ein Cron-Job mit API + Code Interpreter übernimmt, wenn der Report in nachgelagerte Prozesse einfließt.
  • Greifen Sie zum Agents SDK oder zu AgentKit, wenn Sie Handoffs, Guardrails, Tracing oder eine fertige Chat-UI brauchen. ChatGPT agent bleibt für die Exploration, nicht für produktiven Traffic.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Lassen Sie das Modell nur die Generierung übernehmen; Sammeln, Validieren und Ausliefern erledigt der Code
Vollständiges Action Playbook ansehen →