Mehrstufige Workflows als Mittel zur Reduzierung der kognitiven Belastung

1. Was ist ein Workflow im Kontext der ChatGPT App

Nun, wenn Sie sich mit der Autorisierung vertraut gemacht haben, haben Sie sich eine Belohnung verdient. Wechseln wir zu einer sehr interessanten Thematik — workflow in der ChatGPT App. Das Wort „Workflow“ triggert bei vielen Flashbacks an BPMN‑Diagramme und tristen Enterprise‑Software. Beruhigend vorweg: Im Kontext der ChatGPT App interessiert uns eine deutlich leichtere Variante.

In diesem Kurs verstehen wir unter einem Workflow ein mehrstufiges Szenario, in dem:

• es ein klares Ziel gibt (z. B. ein Geschenk auswählen und bis zum Kauf führen),
• es aufeinanderfolgende Schritte gibt (Befragung → Generierung von Varianten → Präzisierung → Finale),
• in jedem Schritt eigene Rollen für GPT, Widget und Tools bestehen.

Wichtig: Ein Workflow ist nicht „eine einzige Methode auf dem MCP‑Server“. Es ist eine Komposition:

• der Überlegungen des Modells (welche Fragen gestellt, welches Tool aufgerufen wird),
• der Aufrufe von Tools (MCP/Agents),
• der UI‑Schritte im Widget,
• des Zustands im Backend.

Das heißt, Sie haben nicht ein „Super‑Tool“ solve_everything, sondern mehrere einfache, die in verschiedenen Phasen aktiviert werden. Und nicht ein „Mega‑Widget“, sondern eine kleine Sammlung von Screens/Zuständen, jeweils für eine Teilaufgabe.

„Verantwortungs‑Dreieck“ im Workflow

Es ist hilfreich, über den Workflow als Tanz von drei Beteiligten nachzudenken:

Diese drei Rollen setzen dasselbe Szenario gemeinsam um, aber auf unterschiedlichen Ebenen: GPT entscheidet „was als Nächstes“, das Widget zeigt „was jetzt“, MCP ist dafür verantwortlich, was tatsächlich mit den Daten passiert.

2. Beispiel‑Workflow auf Basis von GiftGenius

Nehmen wir das bereits bekannte GiftGenius‑Szenario — einen Assistenten für die Geschenkeauswahl. Man kann es als einfachen linearen Assistenten beschreiben.

Die Schrittfolge könnte so aussehen:

1. Grundinformationen über den Empfänger sammeln.
2. Budget und Einschränkungen festlegen.
3. Geschenkideen generieren und filtern.
4. Kandidaten anzeigen, Likes/Verbergen erlauben.
5. Zum Checkout gehen oder die Auswahl speichern.

Dasselbe Szenario lässt sich als kleine „Zustandsmaschine“ darstellen:

stateDiagram-v2
    [*] --> Profiling
    Profiling --> ProfilingDone: Profil ausgefüllt
    ProfilingDone --> Browsing: Ideen generiert
    Browsing --> Refining: Nutzer hat Filter präzisiert
    Refining --> Browsing: aktualisierte Liste
    Browsing --> Checkout: Geschenk ausgewählt
    Checkout --> Success: Bestellung abgeschlossen
    Success --> [*]

Hier:

• Profiling — Schritt zum Sammeln der Antworten über den Empfänger,
• Browsing/Refining — Arbeit mit der Kandidatenliste,
• Checkout — Abwicklung,
• Success — finale Bestätigung.

Beachten Sie: Im Diagramm gibt es weder eine einzige Schaltfläche noch einen fetch. Es sind logische Schritte, und konkrete UI‑Screens, Tools und API‑Aufrufe hängen Sie darüber.

3. Warum die Aufgabe überhaupt in Schritte zerlegen

Wenn Sie jemals „einen Fragebogen mit 25 Fragen auf einem Bildschirm“ gebaut haben, wissen Sie schon, warum. Aber lassen Sie uns alles der Reihe nach aufdröseln.

Kognitive Belastung des Nutzers

Der Mensch hat begrenzte Aufmerksamkeitsressourcen. Psychologen verweisen gern auf das Millersche Gesetz von 7±2 Objekten im Kurzzeitgedächtnis. Im UX‑Design übersetzt sich das in eine sehr praktische Regel: Je mehr Felder und Optionen Sie gleichzeitig zeigen, desto größer die Chance, dass der Nutzer hängen bleibt, ermüdet oder den Tab schließt.

Eine 12‑Felder‑Form auf einem einzigen Bildschirm innerhalb eines kleinen Inline‑Widgets der ChatGPT App ist nahezu ein garantierter Rage‑Quit: Der Nutzer bricht ab und schließt einfach den Tab. Er ist gekommen, um „zu sprechen“, nicht um eine Prüfung abzulegen.

Wenn Sie die Aufgabe jedoch in Schritte teilen:

• „Schritt 1 von 4: Erzählen Sie etwas über die Person“
• „Schritt 2 von 4: Wählen Sie das Budget“
• „Schritt 3 von 4: Schauen Sie sich die Vorschläge an“
• „Schritt 4 von 4: Bestätigen Sie die Auswahl“

wirkt jeder Moment machbar. Ein Fortschrittsbalken oder Schrittbeschriftungen vermitteln Kontrolle: Es ist klar, was passiert und wie viel noch bleibt.

Kognitive Belastung des Modells

Überraschung: Das Problem ist beim Modell ähnlich. Eine LLM ist zwar kein Mensch, hat aber ebenfalls begrenzte „Aufmerksamkeit“ und ein Kontextfenster. Wenn Sie GPT in einem einzigen Durchgang bitten:

• alles über den Empfänger zu ermitteln,
• das Budget zu klären,
• Lieferdetails zu berücksichtigen,
• 10 Varianten auszuwählen,
• zu erklären, warum genau diese Varianten,

dann verbraucht das Modell bei jedem dieser Unterpunkte einen Teil der Aufmerksamkeit und Tokens. Je mehr unabhängige Aufgaben in einer Anfrage stecken, desto höher das Risiko, dass Teile oberflächlich oder fehlerhaft erledigt werden.

Wenn Sie hingegen eine Kette von Schritten aufbauen — im Grunde dasselbe chain-of-thought, nur explizit im Interface ausgelegt —, löst das Modell zuerst die eng gefasste Aufgabe „Profil extrahieren“, dann „Budget anpassen“, danach „Kandidaten auswählen“. Die Qualität der Überlegungen (Reasoning) ist auf jedem Schritt deutlich höher.

Wartbarkeit und Debugging

Wenn alles in ein Tool und einen Screen gepresst ist, wird das Debugging zur Schnitzeljagd: „An welcher Stelle genau wurde es schlecht?“

In einem mehrstufigen Workflow erhalten Sie quasi automatisch:

• Logging‑Punkte: step_started, step_completed, step_failed,
• klare Stellen zur Konversionsmessung (wie viele Nutzer den Schritt 3 erreicht haben),
• lokalisierte Probleme: „es bricht nur beim Schritt Ideen‑Generierung ab“.

All das werden wir im Modul zur Workflow‑Analytik brauchen, aber es ist schon jetzt hilfreich, in Schritten zu denken.

4. Schritttypen im Workflow und wie sie im UI aussehen

Wir haben bereits besprochen, warum man eine Aufgabe in Schritte zerlegt. Jetzt ordnen wir die Schritte und betrachten, welche typischen „Bausteine“ in der ChatGPT App am häufigsten vorkommen. Um nicht in ein chaotisches Sammelsurium von Screens zu kippen, ist eine „Bibliothek“ von Schritttypen nützlich. In Ihrer App werden einige Muster fast immer wiederkehren.

Hier eine Basistabelle:

Wichtig ist: Ein und derselbe logische Schritt kann sich sowohl im UI als auch in einem rein textlichen Dialog manifestieren. Beispielsweise kann der Schritt „Interessen sammeln“ sein:

• entweder ein Formular mit Tags „Sport“, „Brettspiele“, „Kochen“,
• oder ein Gespräch, in dem GPT behutsam nachfragt: „Wofür interessiert er sich?“

Oft ist die optimale Variante ein Hybrid: GPT stellt die Frage, der Nutzer antwortet etwas per Text und kann gleichzeitig im Widget Chips anklicken.

5. Wer „führt“ den Workflow: GPT, Widget oder Server?

Intuitiv möchte man sagen: „Natürlich das Widget — wir sind ja Frontend‑Entwickler, wir kontrollieren alles über State.“ Im Kontext der ChatGPT App funktioniert das so nicht. Der Workflow ist die gemeinsame Arbeit aller drei Beteiligten.

GPT als Orchestrator

GPT:

• führt den Dialog und stellt Fragen,
• entscheidet, wann ein Schritt als abgeschlossen gelten kann,
• wählt, wann ein Tool aufgerufen wird (z. B. „Zeit, Geschenke zu generieren“).

Für GPT sieht Ihr Workflow wie eine Menge von Teilaufgaben aus. Im System‑Prompt können Sie beschreiben, welche Teilaufgaben es gibt und in welcher Reihenfolge sie üblicherweise ausgeführt werden, lassen dem Modell aber die Freiheit, die Sequenz leicht anzupassen.

Beispiel einer Mini‑Anleitung im System‑Prompt für GiftGenius (Pseudocode, ohne exakte Syntax):

1. Zuerst das Profil des Empfängers präzisieren (Alter, Beziehung, Interessen).
2. Danach das Budget klären.
3. Wenn genügend Daten vorliegen — das Tool suggest_gifts aufrufen.
4. Nach Erhalt der Kandidaten — dem Nutzer bei der Auswahl helfen.

Das Wichtigste: GPT kennt (und soll auch nicht kennen) die Details Ihrer React‑Komponenten. Es operiert mit Schritten in Ziel‑Begriffen: „Profil sammeln“, „Ideen auswählen“.

Das Widget als „Gesicht“ des Schritts

Das Widget:

• zeigt genau den Schritt an, der jetzt relevant ist,
• hält den UI‑Zustand (markierte Karte, geöffneter Tab, lokale Formularfelder),
• kann einen Fortschrittsindikator über die Schritte anzeigen.

Die einfachste Darstellung des UI‑Workflows im Code:

type GiftWorkflowStep =
  | "profiling"
  | "budget"
  | "candidates"
  | "checkout";

type GiftWidgetState = {
  step: GiftWorkflowStep;
  selectedGiftId?: string;
};

Innerhalb des React‑Widgets können Sie diesen Zustand entweder in einem normalen useState halten oder, wenn Sie ihn an den Lebenszyklus des Widgets in ChatGPT binden möchten, useWidgetState aus dem Apps SDK verwenden.

const [widgetState, setWidgetState] = useState<GiftWidgetState>({
  step: "profiling",
});

Handler‑Funktionen im Widget werden nicht direkt „ein Geschenk kaufen“, sondern den Schritt ändern und die nötigen Daten zurück an Modell/Backend übergeben.

MCP‑Tools als „Hände“ des Workflows

MCP‑Server:

• speichert den Geschäfts‑Zustand (Profil, Auswahlhistorie),
• validiert Schritte („Man kann nicht zum Checkout gehen, wenn kein Geschenk ausgewählt wurde“),
• führt schwere Arbeiten aus: Katalogsuche, Preisberechnung, Integration mit ACP.

Es ist z. B. logischer, dass die Entscheidung „welche Geschenke angezeigt werden“ nicht im Widget, sondern im MCP‑Tool suggest_gifts getroffen wird, damit das Modell es bei Präzisierungen mehrfach aufrufen kann.

So ergibt sich eine klare Trennung:

• GPT — Text und Reihenfolge,
• Widget — visuelle Darstellung des aktuellen Schritts,
• MCP — Daten und Invarianten.

6. Wie man den Workflow im Code beschreibt: Mini‑State‑Machine

Erinnern Sie sich an das Zustandsdiagramm für GiftGenius vom Anfang der Vorlesung? Jetzt schreiben wir dieselbe Logik als einfache Typen und Funktionen — eine Mini‑State‑Machine im Code. Dabei machen wir aus Ihrer App keinen theoretischen Kurs über endliche Automaten; aber ein paar einfache Typen und Funktionen vereinfachen das Leben erheblich.

Schritttypen und Konfiguration

Beginnen wir mit einer deklarativen Beschreibung der Schritte. Nehmen wir den bereits bekannten Typ GiftWorkflowStep (wir wiederholen ihn hier zur Veranschaulichung) und beschreiben dafür eine Konfiguration:

type GiftWorkflowStep =
  | "profiling"
  | "budget"
  | "candidates"
  | "checkout";

type StepConfig = {
  label: string;
  isFinal?: boolean;
};

export const GIFT_WORKFLOW_STEPS: Record<GiftWorkflowStep, StepConfig> = {
  profiling: { label: "Empfänger" },
  budget: { label: "Budget" },
  candidates: { label: "Kandidaten" },
  checkout: { label: "Checkout", isFinal: true },
};

Jetzt können wir eine einfache Übergangsfunktion hinzufügen:

export function getNextStep(
  current: GiftWorkflowStep
): GiftWorkflowStep | null {
  switch (current) {
    case "profiling":
      return "budget";
    case "budget":
      return "candidates";
    case "candidates":
      return "checkout";
    default:
      return null; // Ende
  }
}

Das gibt Ihnen bereits:

• eine zentralisierte Liste der Schritte,
• explizite Übergangsregeln,
• die Möglichkeit, Reihenfolge und Logik schnell zu ändern.

Im Widget verwenden

Die einfachste Version eines „Assistenten“ in Ihrem Widget kann so aussehen:

function GiftWizard() {
  const [step, setStep] = useState<GiftWorkflowStep>("profiling");

  const handleStepComplete = () => {
    const next = getNextStep(step);
    if (next) setStep(next);
  };

  return (
    <div>
      <ProgressBar step={step} />
      <StepContent step={step} onComplete={handleStepComplete} />
    </div>
  );
}

Die Komponente StepContent kann je nach Schritt unterschiedliche Unterformulare rendern:

function StepContent(props: {
  step: GiftWorkflowStep;
  onComplete: () => void;
}) {
  const { step, onComplete } = props;

  if (step === "profiling") {
    return <ProfilingStep onNext={onComplete} />;
  }
  if (step === "budget") {
    return <BudgetStep onNext={onComplete} />;
  }
  if (step === "candidates") {
    return <CandidatesStep onNext={onComplete} />;
  }
  return <CheckoutStep />;
}

Beachten Sie: Hier berühren wir noch nicht, wie GPT den Schritt wählt — das ist lokale UI‑Logik. Später können Sie diesen step mit dem Serverzustand oder mit Nachrichten von Tools synchronisieren, aber fürs Verständnis der Mehrstufigkeit reicht das aus.

7. Die Lern‑App weiterentwickeln: von der „Mega‑Form“ zum Assistenten

Stellen wir uns vor, dass Ihr GiftGenius‑Widget vor dieser Vorlesung wie eine „große Form“ aussah:

• Name des Empfängers,
• Alter,
• Interessen,
• Budget,
• Art des Ereignisses,
• Checkboxes „Lieferung benötigt“ und noch fünf weitere Felder,
• und unten ein großer Button „Geschenk finden“.

Für einen Prototyp ist das oft okay, aber sobald Sie ein Produkt‑Szenario wollen — ist es Zeit, in Schritte zu schneiden.

Wie es „vorher“ aussah

Karikaturhaftes Beispiel:

// Antipattern: ein einziges riesiges Formular
function GiftFormAllInOne() {
  return (
    <form>
      {/* 10+ Felder wild gemischt */}
      {/* ... */}
      <button type="submit">Geschenk finden</button>
    </form>
  );
}

Typische Probleme:

• Der Nutzer versteht nicht, welche Felder obligatorisch sind,
• unklar, wie lange das dauern wird,
• es ist für GPT schwieriger, dem Nutzer zu erklären, was passiert ist, und Follow‑ups zu machen.

Wie man es „nachher“ macht: ein Assistent mit drei Screens

Schritt 1 — Profil vom Budget trennen:

function ProfilingStep(props: { onNext: () => void }) {
  const [recipientType, setRecipientType] = useState("");
  const [interests, setInterests] = useState<string[]>([]);

  const handleSubmit = () => {
    // Hier kann ein Tool zum Speichern des Profils aufgerufen werden
    props.onNext();
  };

  return (
    <div>
      <h3>Für wen suchen wir ein Geschenk?</h3>
      {/* Paare von Radio-Buttons/Chips für Typ und Interessen */}
      <button onClick={handleSubmit}>Weiter</button>
    </div>
  );
}

Schritt 2 — Budget:

function BudgetStep(props: { onNext: () => void }) {
  const [budget, setBudget] = useState<number | null>(null);

  const handleSubmit = () => {
    // Man kann ein Tool zur Budgetvalidierung aufrufen
    props.onNext();
  };

  return (
    <div>
      <h3>Wie hoch ist Ihr Budget?</h3>
      {/* Slider oder Input */}
      <button onClick={handleSubmit} disabled={!budget}>
        Vorschläge anzeigen
      </button>
    </div>
  );
}

Schritt 3 — Kandidatenliste:

function CandidatesStep(props: { onNext: () => void }) {
  const [selectedId, setSelectedId] = useState<string | null>(null);

  // Hier zeigen Sie bereits Geschenk-Karten
  // und erlauben die Auswahl eines Elements

  return (
    <div>
      <h3>Wählen Sie eine passende Option</h3>
      {/* Karten mit onClick = setSelectedId */}
      <button onClick={props.onNext} disabled={!selectedId}>
        Zum Checkout gehen
      </button>
    </div>
  );
}

Ja, der Code ist etwas umfangreicher geworden, aber die Logik wurde einfacher:

• jeder Schritt löst eine kleine Aufgabe,
• das Modell kann Übergänge zwischen den Schritten separat kommentieren,
• Sie können jeden Schritt getrennt loggen/messen.

8. Antipatterns: Wie man den Workflow nicht zum Monster macht

Praxis und Beobachtungen bei ähnlichen Apps zeigen mehrere typische Fehler, die man unbedingt vermeiden sollte.

Erstens: Versuchen Sie nicht, „alles auszumalen“ mit einem komplexen BPMN‑Diagramm mit 30 Zuständen, 40 Pfeilen und einem A0‑Poster. Im Kontext der ChatGPT App ist eine intuitiv verständliche Schritttreppe wichtiger als eine formale Notation. Es genügen Diagramme wie dasjenige, das wir für GiftGenius gezeichnet haben.

Zweitens: Machen Sie Ihre App nicht zu einem einzigen großen Formular, besonders nicht in einem Inline‑Widget. Der Nutzer ist bereits im Chat; ein dichter UI‑Block sollte die Belastung senken, nicht erhöhen. Wenn Sie sich denken „nun, das sind 12 Felder, aber sie sind alle wichtig“ — ist das fast immer ein Zeichen, dass Sie die Aufgabe zerschneiden müssen.

Drittens: Machen Sie keine Schritte „der Schönheit wegen“. Jeder Schritt braucht ein klares Ziel: entweder Daten sammeln, die Auswahl eingrenzen oder dem Menschen etwas zur Bestätigung geben. Ein leerer Screen à la „gleich geschafft“ mit einem „Weiter“-Button hilft selten.

Schließlich: Versuchen Sie nicht, alle Möglichkeiten der App in den ersten Schritten offenzulegen. Detailliertes wie „erweiterte Filter“, „besondere Lieferbedingungen“ kann als zusätzliche Schritte nur für diejenigen hinzugefügt werden, die es wirklich brauchen.

9. Eine einfache Übung zur Workflow‑Gestaltung

Um das Material besser zu festigen, versuchen Sie Folgendes auf Papier (oder in der IDE, aber ohne Code).

Nehmen Sie eine Aufgabe. Das könnte sein:

• Geschenkauswahl (GiftGenius),
• Reisebuchung,
• Erstellung eines Lernplans für etwas.

Zerlegen Sie sie in 3–5 Schritte. Beschreiben Sie für jeden Schritt:

• das Ziel: Was soll nach diesem Schritt bekannt/erledigt sein,
• das Format: Was ist hier passender — reiner Text von GPT, Widget oder eine Kombination.

Beispielsweise für einen einfachen „Lernplan TypeScript“:

1. Schritt „Niveau einschätzen“ — Dialog (GPT stellt ein paar Fragen) + kurzes Formular mit Selbsteinschätzung.
2. Schritt „Ziele“ — Textdiskussion + Checkboxen für Ziele im Widget.
3. Schritt „Plan“ — Generierung des Plans (Liste) + Buttons „schwieriger/leichter“.
4. Schritt „Bestätigung“ — kurzes Resümee und Button „Plan speichern“.

Versuchen Sie danach abzuschätzen, welche Tools in jedem Schritt eingesetzt werden könnten, ohne in Details abzutauchen: Tools, deren Ein-/Ausschalten und die Zustandsverwaltung sind Themen der nächsten Vorlesungen dieses Moduls.

10. Typische Fehler bei der Arbeit mit mehrstufigen Workflows

Fehler Nr. 1: Der Versuch, alles mit einem Schritt und einem Tool zu lösen.
Es ist sehr verlockend, ein „großes schlaues Tool“ zu bauen, das sowohl fragt, analysiert, selbst auswählt als auch die Bestellung selbst abwickelt. In der Praxis verschlechtert das sowohl die UX (ein schwerer Screen) als auch die Qualität der Überlegungen des Modells (reasoning) — zu viele Verantwortlichkeiten in einem Aufruf. Es ist einfacher, zuverlässiger und günstiger in der Wartung, die Aufgabe in eine Kette von 3–5 einfachen Schritten zu zerlegen.

Fehler Nr. 2: Implizite Schritte, die im Kopf des Entwicklers versteckt sind.
Manchmal gibt es im Code scheinbar eine Abfolge von Aktionen, sie ist jedoch nirgends explizit beschrieben: keine Schritttypen, keine Konfiguration, kein Diagramm. Am Ende kann niemand im Team klar beantworten, „was in dieser App von Anfang bis Ende passiert“. Eine minimale deklarative Beschreibung von Schritten und Übergängen spart Stunden beim Debuggen.

Fehler Nr. 3: Vermischung von UI‑Schritten und Geschäftslogik.
Wenn die Logik der Übergänge zwischen Schritten tief in React‑Komponenten vergraben ist (à la if (isValid && hasBudget && !needsShipping) am onClick-Handler eines Buttons), wird sie schwer wiederverwendbar und testbar. Besser ist eine relativ explizite „State‑Machine“ oder wenigstens eine Funktion getNextStep, und das UI ruft sie nur auf und zeigt das Ergebnis an.

Fehler Nr. 4: Die Rolle von GPT als Orchestrator ignorieren.
Mitunter versucht ein Entwickler, das Szenario vollständig aus dem Widget zu kontrollieren: „Ich frage selbst alles Nötige, das Modell soll nur auswählen.“ Dadurch hört sich ChatGPT auf, wie ein lebendiger Assistent zu wirken, und wird zu einem Rechenkern unter einem Formular. Deutlich angenehmer ist es, wenn GPT aktiv kommuniziert, zum nächsten Schritt anstößt und selbst Tool‑Aufrufe initiiert — und Sie helfen ihm mit dem Design der Schritte und den Anweisungen.

Fehler Nr. 5: Schritte ohne klares Ziel.
Manchmal tauchen in einem Assistenten „zusätzliche“ Schritte auf — ehrlich gesagt nur, weil es der Designer schöner fand. Der Nutzer sieht „Schritt 2 von 5“, aber in diesem Schritt wird von ihm kaum etwas verlangt und es passiert nichts. Solche leeren Screens erhöhen nur das Gefühl von Komplexität. Wenn ein Schritt nicht formuliert werden kann als „danach wissen wir sicher X“ oder „danach hat der Nutzer Y gemacht“ — ist er höchstwahrscheinlich überflüssig.

Fehler Nr. 6: Vergessener Fortschritt und fehlendes Gefühl eines Weges.
Mehrstufigkeit ohne visuelle Unterstützung wird zur Blackbox: Der Nutzer versteht nicht, wo er steht und wie viel noch bleibt. Selbst ein einfacher Textindikator „Schritt 2 von 4“ oder eine horizontale Aufzählung der Schritte im Header des Widgets senkt die Unsicherheit spürbar. Die Ignorierung dieses Effekts ist einer der Gründe, warum Menschen „auf halbem Weg abspringen“, obwohl dort real vielleicht gar keine große Schwierigkeit liegt.