Mehrstufige Prozesse: automatische Orchestrierung durch das Modell und Kontrolle von Schleifen

1. Was ist ein mehrstufiger Run und wie unterscheidet er sich von einer „einmaligen“ Anfrage

Wenn Sie bisher nur mit ChatGPT App und MCP-Tools gearbeitet haben, war das Bild recht linear: Es kam eine Nutzeranfrage → GPT entschied, ein oder mehrere Tools aufzurufen → Sie gaben eine Antwort zurück. Das kann man immer noch als „einen logischen Schritt“ betrachten, selbst wenn das Tool intern etwas Komplexeres tat.

Bei einem Agenten ist ein run eine Zielsetzung plus eine Abfolge von Schritten. Wir denken nicht mehr in Kategorien wie „ein Prompt – eine Antwort“, sondern sehen die Aufgabe als Mini‑Projekt, das der Agent von Anfang bis Ende führt.

Man kann den Unterschied so darstellen:

Wichtig dabei: Sie müssen die Planung nicht vollständig dem Modell überlassen. Meistens ist es ein Hybrid: Sie kodieren die großen Phasen des Szenarios strikt (z. B. „zuerst Anforderungen sammeln, dann Geschenke auswählen, dann Karten vorbereiten“), und innerhalb jeder Phase darf der Agent seine Tools relativ frei nutzen.

Mini-Analogie

Ein einmaliger Tool-Aufruf ist wie einen Kurier rufen: „Hol ein Dokument ab und bring es ins Büro.“

Ein mehrstufiger agentischer run ist wie ein persönlicher Assistent: „Bereite mir ein Geschenk für eine Kollegin zum Geburtstag vor: Finde heraus, was sie mag, wähle mehrere Optionen, prüfe die Lieferung und stelle alles in einer schönen Präsentation zusammen.“ Der Assistent entscheidet selbst, welche Schritte er auf dem Weg ausführt.

Weiter unten in der Vorlesung sehen wir uns auch an, wie sich solche mehrstufigen runs in den Ihnen bereits bekannten Stack Apps SDK → MCP → Backend einfügen, sodass die Agentenlogik für ChatGPT und das Widget wie ein gewöhnliches, sauberes MCP-Tool aussieht.

2. Wie das Modell Schritte selbst plant: Vogelperspektive

In den Begriffen des Agents SDK lässt sich jeder run bequem als ein Tripel darstellen:

1. Goal (Ziel): eine textliche Beschreibung der Aufgabe, die in die System-/User-Instruktionen des Agenten gelangt.
2. Tools: ein Satz verfügbarer Tools mit guten Beschreibungen und JSON Schema.
3. State: die Schritthistorie und ein strukturiertes Zustandsobjekt, das Sie extern halten (DB, Redis, was auch immer).

Dann greift der bekannte Run-Zyklus: Das Modell schaut auf das Ziel und die verfügbaren Tools und entscheidet in jedem Schritt:

• „Ich habe jetzt genug Informationen – ich kann das finale Ergebnis für die Nutzerin/den Nutzer ausgeben“;
• oder „Ich muss das Tool X mit diesen Argumenten aufrufen“;
• oder „Ich habe ein Tool-Ergebnis erhalten, jetzt muss ich es interpretieren, filtern und möglicherweise ein anderes Tool aufrufen“.

Als Pseudocode sieht die Idee so aus (Erinnerung: mentale Modellierung, kein echtes API):

while (!done && steps < MAX_STEPS) {
  const modelResponse = await callModel({
    system: agentPolicy,
    messages: history,
    tools,
  });

  if (modelResponse.type === "tool_call") {
    const toolResult = await callTool(modelResponse.toolName, modelResponse.args);
    history.push({ role: "tool", content: toolResult });
  } else {
    // finale Antwort
    done = true;
    return modelResponse.content;
  }

  steps++;
}

Im realen Agents SDK ist dieser Zyklus bereits implementiert und „unter der Haube“ versteckt. Sie beschreiben den Agenten deklarativ, und das SDK lässt Modell und Tools im Kreis laufen, bis eine finale Antwort vorliegt oder die Schritt-/Zeitlimits erreicht sind.

Die Aufgabe der Architektin/des Architekten besteht darin,

• Goal und Systeminstruktion so zu formulieren, dass das Modell vernünftige Schritte plant;
• ein Set von Tools ohne semantische Überschneidungen aufzubauen;
• Schritt- und Zeitlimits festzulegen;
• zu überlegen, welche Schritte parallelisierbar sind.

Wenn Ziel, Tools und ein Zustandsmodell existieren, ist die nächste Frage: Mit welchen Schritten nähert man sich dem Ziel? Nicht alle Schritte sind gleich: Einige sind strikt sequentiell, andere lassen sich parallel ausführen.

3. Sequentielle und parallele Schritte

Jetzt, da wir das grundlegende Verständnis des Run-Zyklus haben, ist wichtig zu verstehen, welche Arten von Schritten es innerhalb eines solchen Prozesses gibt. In Agent-Workflows sind es grob zwei Typen: sequentielle und parallele.

Sequentielle Schritte

Das ist der Fall, wenn das Ergebnis von Schritt A kritisch für Schritt B ist. Zum Beispiel in unserem Lernbeispiel GiftGenius:

1. Zuerst verstehen, wer die zu beschenkende Person ist: Kollegin/Kollege, Verwandte(r), Alter, Interessen.
2. Dann eine Menge Kandidaten über das Tool search_gifts suchen.
3. Anschließend nach Budget und Einschränkungen filtern.
4. Dann hübsche Karten für das Widget erstellen.
5. Und erst danach ggf. den Checkout vorschlagen.

Jeder nachfolgende Schritt hängt von den Daten des vorherigen ab, daher entsteht eine strikt sequentielle Ausführung.

Als Pseudocode eines „inneren Plans“ des Modells könnte das so aussehen:

1. Die Nutzerin/den Nutzer zu Empfängerprofil und Budget befragen
2. Tool search_gifts(profile, budget) aufrufen
3. Tool filter_by_constraints(gifts, constraints) aufrufen
4. Endliste und Beschreibung erzeugen

Das Modell schreibt so eine Liste nicht als Code, aber wir können es durch Systeminstruktionen, Beispieldialoge und Tool-Beschreibungen in diese Struktur lenken.

Parallele Schritte

Manchmal lassen sich Schritte unabhängig voneinander ausführen. Zum Beispiel wollen wir Geschenkangebote aus drei Shops gleichzeitig vergleichen:

• search_gifts_amazon
• search_gifts_etsy
• search_gifts_local_store

Aus Sicht des Agenten sind das drei unabhängige Tool-Aufrufe, die parallel gestartet werden können, um die Gesamtantwortzeit zu verkürzen.

Im Agents SDK (und generell in modernen Agentenframeworks) gibt es oft eine eingebaute Unterstützung für parallele Tool-Aufrufe, wenn das Modell in einer Antwort mehrere Aufrufe vorschlägt. Das kanonische Szenario: Das Modell beschreibt eine Liste solcher Aufrufe, das SDK ruft sie konkurrierend auf, sammelt die Ergebnisse und legt sie als Satz von tool-Nachrichten für den nächsten Modellschritt ab.

Aus Sicht der Planung sieht das so aus:

// Agentschritt: Das Modell hat entschieden, drei Tools aufzurufen
const calls = [
  { name: "search_gifts_amazon", args: {...} },
  { name: "search_gifts_etsy", args: {...} },
  { name: "search_gifts_local_store", args: {...} },
];

const results = await Promise.all(
  calls.map(c => callTool(c.name, c.args))
);

// Danach werden alle Resultate vor dem nächsten Modellschritt in den Kontext eingefügt

Wenn Sie Frontend in JS/TS geschrieben haben, kennen Sie das Konzept paralleler Requests bereits: etwa wenn Sie mit Promise.all mehrere fetch()-Aufrufe gleichzeitig starten. Nun taucht dieselbe Idee innerhalb des Run-Zyklus des Agenten auf – nur dass die Entscheidung, was genau parallel laufen kann, weitgehend das Modell trifft.

4. Beispiel-Workflow für GiftGenius: Schritte, Ziel und Tools

Im Abschnitt zu sequentiellen Schritten haben wir das Verhalten von GiftGenius bereits intuitiv in Phasen zerlegt. Jetzt formalisieren wir diesen mehrstufigen Ablauf als Agent-Workflow: Wir beschreiben Ziel, Schritte und verknüpfen sie mit Tools und Agentenkonfiguration. Wir binden uns noch nicht an ein konkretes Agents-SDK-API, sondern beschreiben die Struktur und fügen etwas hypothetischen TypeScript-Code hinzu.

Ziel (goal)

Lassen Sie das Ziel so lauten:

Der Nutzerin/dem Nutzer helfen, 3–5 Geschenkoptionen für eine konkrete Empfängerperson zu finden, dabei Budget, Anlässe und Lieferrestriktionen zu berücksichtigen und eine strukturierte Liste von Geschenk-Karten für das GiftGenius-Widget auszugeben.

Hauptschritte

Wir beschreiben eine minimale Variante aus 4 Schritten:

1. Präzisierung des Empfängerkontexts
   Ziel: Informationen darüber sammeln, wem das Geschenk gemacht wird (Alter, Geschlecht, Interessen, Beziehung zur/zum Schenkenden), außerdem Budget und Datum des Ereignisses.
   Tools: eventuell gar keine Tools, reiner Dialog Modell ↔ Nutzerin/Nutzer.
2. Suche und erste Auswahl von Geschenken
   Ziel: eine „rohe“ Auswahl von Geschenken erhalten.
   Tools: search_gifts(profile, budget) – ein Tool, das unseren Katalog/Suchdienst abfragt und eine Kandidatenliste zurückgibt.
3. Filterung und Sortierung
   Ziel: ungeeignete Varianten ausschließen (keine Lieferung in die Region, Budgetüberschreitung, unpassende Einschränkungen) und nach Relevanz sortieren.
   Tools: filter_and_score_gifts(candidates, constraints) – ein reines, idempotentes Tool.
4. Formatierung des Ergebnisses für das Widget
   Ziel: Daten in ein für das UI praktisches Format bringen: Titel, kurze Beschreibung, Bild, Preis, CTA.
   Tools: format_gift_cards(gifts) – kann ein Code-Tool (Strukturgenerierung) oder ein LLM-Tool (ästhetische Texte) sein.

Wie das in der Agentenkonfiguration aussehen könnte

Stellen wir uns einen hypothetischen Agenten-Konstruktor vor (Pseudocode):

import { createAgent } from "@acme/agents-sdk";
import { tools } from "./gift-tools";

export const giftAgent = createAgent({
  name: "gift-guru",
  system: `
    Du bist der GiftGenius-Agent und hilfst bei der Geschenkauswahl.
    Ziel: 3–5 Optionen vorschlagen, die real kaufbar sind,
    unter Berücksichtigung des Empfängerprofils, des Budgets und von Lieferbeschränkungen.
    Kläre zuerst wichtige Details, nutze dann die Tools für Suche und Filterung.
    Rufe keine Tools auf, wenn du Budget oder zentrale Interessen noch nicht kennst.
    Beende die Arbeit, wenn du eine klare Liste von Geschenk-Karten hast.
  `,
  tools, // hier stehen search_gifts, filter_and_score_gifts, format_gift_cards
  maxSteps: 12,
  timeoutMs: 15000,
});

Achten Sie auf einige Details:

• In der Systeminstruktion sagen wir ausdrücklich, dass der Agent zuerst Details klären soll und erst danach Such-Tools verwenden. Das reduziert das Risiko, dass das Modell Tools mit zu vagem Kontext anstößt.
• Wir haben maxSteps begrenzt, damit der Agent nicht in endlose Schleifen gerät.
• Der Timeout timeoutMs stellt sicher, dass der gesamte run nicht „ein halbes Leben“ der Nutzerin/des Nutzers beansprucht.

5. Automatische Orchestrierung durch das Modell: was der Modellautonomie überlassen, was strikt festlegen

Ein Agent ist ein Balanceakt zwischen der Freiheit des Modells und der strikten Struktur, die Sie vorgeben.

Gibt man dem Modell zu viel Freiheit und setzt keine Grenzen, erhält man „kreatives Chaos“: überflüssige Tool-Aufrufe, wiederholte Schritte, intransparente Schleifen. Kodiert man hingegen alles strikt im Backend als endlichen Automaten, wird das Modell zu einem Text-Dekorateur statt zu einer klugen Ausführungsinstanz.

Was man üblicherweise dem Modell überlässt

Im Kontext von GiftGenius (und ähnlichen Szenarien) ist es sinnvoll, dem Modell zu vertrauen bei:

• der Formulierung von Fragen an die Nutzerin/den Nutzer (Interessen präzisieren, Budget höflich erfragen);
• der Entscheidung, wann genug Informationen für die Suche vorhanden sind;
• der Wahl, welche Tools innerhalb einer Phase zu verwenden sind (z. B. welches Shop-Suchtool, wenn mehrere existieren);
• der Generierung von Beschreibungstexten, Erklärungen, Vergleichen.

Was besser strikt festgelegt wird

Im Voraus sollte man fixieren:

• die großen Phasen des Szenarios („Information sammeln“ → „Suche“ → „Filterung“ → „Formatierung“ → „Finale“);
• Schritt- und Zeitlimits;
• Bedingungen, unter denen der Agent „stoppen“ und ehrlich kommunizieren muss, dass die Aufgabe unlösbar ist (z. B. Budget 5 Dollar, aber es wird ein teures elektronisches Gadget mit Zustellung morgen benötigt);
• Idempotenz-Politik der Tools und Retry-Strategien.

Hybrid-Beispiel: Phasen als State, Ausgestaltung durch das Modell

Man kann im Agentenstate ein Feld phase einführen, das die Werte "collect_profile" | "search" | "filter" | "format" | "done" annimmt. Dann kontrolliert Ihr Backend (oder das Agents SDK selbst, falls es einen benutzerdefinierten Zustandsautomaten unterstützt), welche Tools in welcher Phase verfügbar sind.

Pseudocode:

type Phase = "collect_profile" | "search" | "filter" | "format" | "done";

interface GiftAgentState {
  phase: Phase;
  profile?: UserProfile;
  candidates?: GiftCandidate[];
  finalGifts?: GiftCard[];
}

Die Systeminstruktion des Agenten kann eine kurze Beschreibung der Phasen enthalten, und Sie begrenzen im Code die Liste der Tools, die dem Modell je nach aktueller Phase gezeigt werden. Das ist ein Beispiel für tool gating, das im Modul zum Workflow ausführlicher behandelt wird.

6. Kontrolle endloser Schleifen und nutzloser Wiederholungen

Wenn man dem Agenten einen unkontrollierten Run-Zyklus lässt, verhält er sich früher oder später wie eine Studentin/ein Student kurz vor der Deadline: endlos „nachfragen und umschreiben“, um nicht abzugeben. Unsere Aufgabe ist, ein Festhängen zu verhindern.

Es gibt drei typische Quellen für Endlosschleifen:

1. Das Modell ist unsicher in der Antwort und formuliert dieselbe Tool-Anfrage mit geringfügigen Änderungen immer wieder um.
2. Ein Tool liefert konstant einen Fehler oder ein leeres Ergebnis, und der Agent versucht stur, es „noch einmal“ zu probieren.
3. Der Agent steckt zwischen zwei Tools fest und ruft abwechselnd das eine und dann das andere auf, ohne dem finalen Ergebnis näher zu kommen.

Schrittlimit (maxSteps)

Der einfachste und zwingende Mechanismus ist die Begrenzung der Schrittanzahl. In den meisten Implementierungen des Agents SDK können Sie maxSteps beim Start des run oder in der Agentenkonfiguration angeben. Sobald das Limit erreicht ist, beendet das SDK den run mit einem speziellen Status (z. B. aborted_by_max_steps). Wie Sie das der Nutzerin/dem Nutzer anzeigen, entscheiden Sie.

In GiftGenius können wir annehmen, dass eine solide Geschenkauswahl in etwa 10 Schritte passt (ein paar Präzisierungen, ein paar Suchen, Filterung, Formatierung). Wir setzen z. B. 12–15 Schritte mit Puffer und behandeln die Situation, wenn das Limit erreicht wird, sauber:

const run = await giftAgent.run({
  input: userGoal,
  maxSteps: 12, // überschreibt den Default
});

if (run.status === "max_steps_exceeded") {
  // Zeigen Sie eine ehrliche Meldung für die Nutzerin/den Nutzer
}

Zeitlimit (Timeout)

Manchmal liegt das Problem nicht in der Schrittanzahl, sondern in der Gesamtdauer. Tools können langsam sein, das Netzwerk instabil. Daher ist es sinnvoll, timeoutMs sowohl auf Ebene einzelner Tool-Aufrufe als auch für den gesamten run zu setzen.

Zum Beispiel könnten Sie festlegen, dass:

• jeder Aufruf eines externen API (Geschenk-Suche bei einem Partner) nicht länger als 3–5 Sekunden dauert;
• der gesamte run zur Geschenkauswahl in 15 Sekunden abgeschlossen ist.

Wenn der Timeout greift, beenden Sie den run sauber und zeigen ggf. ein Teilergebnis und eine ehrliche Erklärung an, dass „ein Teil der Quellen nicht rechtzeitig geantwortet hat“.

Erkennen von Wiederholungen

Ein fortgeschrittener (aber nützlicher) Pattern ist, wiederholte Tool-Aufrufe mit identischen Argumenten zu erkennen. Wenn Sie sehen, dass der Agent bereits dreimal hintereinander search_gifts(profile, budget) mit denselben Parametern aufgerufen hat, ist das ein Signal, dass er feststeckt.

Sie können im State einen Zähler für Aufrufe mit dem Schlüssel (toolName, argsHash) führen und, wenn der Zähler den Schwellwert überschreitet, entweder:

• den run abbrechen und eine verständliche Fehlermeldung zurückgeben;
• oder dem Modell eine zusätzliche Instruktion unterjubeln: „Du hast dieses Tool bereits dreimal mit denselben Parametern aufzurufen versucht. Ändere die Strategie oder frage die Nutzerin/den Nutzer.“

Pseudocode:

function shouldAbortToolCall(toolName: string, args: unknown, state: GiftAgentState) {
  const key = `${toolName}:${hashArgs(args)}`;
  const count = state.toolCallCounts[key] ?? 0;

  if (count >= 3) return true;

  state.toolCallCounts[key] = count + 1;
  return false;
}

Dabei ist hashArgs eine beliebige deterministische Serialisierungsfunktion für Argumente (z. B. JSON.stringify mit Schlüsselsortierung).

7. Klare Kriterien für den Abschluss der Aufgabe

Ein wesentlicher Unterschied zwischen einem „Spielzeug“-Agenten und einem Produktionsagenten ist das Vorhandensein klarer Abschlusskriterien. Fehlen sie, kann das Modell die Aufgabe entweder zu früh beenden („hier sind ein paar Geschenke, den Rest machen Sie“) oder endlos weiter „optimieren“.

In GiftGenius lässt sich eine einfache Regel formulieren:

• Der Agent beendet sich, wenn er 3 bis 5 Geschenke mit ausgefüllten Feldern hat: id, title, shortDescription, price, imageUrl, purchaseUrl, und sie die Budget- und Lieferfilter passiert haben.
• Wenn nach maximal N Versuchen von Suche und Filterung weniger als 3 passende Geschenke gefunden werden, kommuniziert der Agent ehrlich, dass nichts Anständiges gefunden wurde, und schlägt vor, das Budget zu erhöhen oder die Einschränkungen zu lockern.

Diese Kriterien kann man direkt in der Systeminstruktion des Agenten und/oder in der Ergebnisprüfung nach dem run verankern.

Beispiel einer Ergebnisprüfung nach dem Run:

if (run.status === "completed") {
  const gifts = run.output.gifts; // nehmen wir an, unser Agent gibt einen strukturierten JSON zurück

  if (!gifts || gifts.length < 3) {
    // Der Agent hat "abgeschlossen", aber das Resultat ist schwach – man kann:
    // 1) eine ehrliche Erklärung anzeigen,
    // 2) der Nutzerin/dem Nutzer andere Bedingungen vorschlagen.
  } else {
    // Alles ok – das Widget mit den Geschenken anzeigen
  }
}

Erwarten Sie vom Modell kein magisches Verständnis von Geschäftserfolg. Sie als Entwickler(in) müssen die Bedingungen eines „zufriedenstellenden“ Ergebnisses explizit formulieren und prüfen.

8. Wo die Orchestrierung konkret umgesetzt wird: Agent, Backend, Widget

Wir haben bereits gesagt, dass Orchestrierung auf verschiedenen Ebenen leben kann: im Agenten, im Backend, im Widget.

Aus Sicht mehrstufiger Prozesse ist die Logik ungefähr so.

Agent (Agents SDK) ist zuständig für den „gedanklichen“ Workflow:

• wie das Ziel in Schritte zerlegt wird;
• welche Tools in welcher Reihenfolge aufzurufen sind;
• welche Zusatzfragen an die Nutzerin/den Nutzer zu stellen sind.

Backend stellt in der Regel bereit:

• die Implementierung der Tools (Suche, Filter, Commerce etc.);
• Speicherung von Zustand und Checkpoints;
• harte Businessrestriktionen (Budgetgrenzen, Berechtigungen, regionale Verfügbarkeit).

Widget (Apps SDK) steuert:

• die Anzeige des Fortschritts (Stepper, Fortschrittsbalken, „Schritt 2 von 4“);
• Eingabeformulare;
• UX-Details wie deaktivierte Buttons, wenn nicht alle Daten ausgefüllt sind.

Gute Praxis ist es, so zu denken: Der Agent inszeniert die Arbeit der Tools und den Dialog, und das UI‑Widget inszeniert das visuelle Nutzererlebnis. Sie verständigen sich über strukturierte Daten (ToolOutput, Agent-Run-Output).

9. Mini-Codebeispiel: Start eines mehrstufigen GiftGenius-Agenten aus einem MCP-Tool

Wie eingangs versprochen, verknüpfen wir die neue Konzeptidee mit dem bekannten Stack Apps SDK → MCP → Backend und zeigen ein kleines Beispiel, wie ein MCP-Tool einen agentischen run starten kann.

Stellen wir uns vor, in Ihrer Datei app/mcp/route.ts gibt es ein Tool run_gift_workflow, das:

• die Textanfrage der Nutzerin/des Nutzers (ihr/sein Ziel) annimmt;
• den Agenten giftAgent startet;
• ein strukturiertes Ergebnis für das Widget zurückgibt.

Der Code ist vereinfacht und hypothetisch, vermittelt aber das Zusammenspiel:

// app/mcp/route.ts
import { server } from "@modelcontextprotocol/sdk/server";
import { z } from "zod";
import { giftAgent } from "@/agents/giftAgent";

server.registerTool(
  "run_gift_workflow",
  {
    title: "Geschenke auswählen",
    description: "Startet den mehrstufigen Agenten zur Geschenkauswahl",
    inputSchema: {
      userGoal: z
        .string()
        .describe("Aufgabe der Nutzerin/des Nutzers, z. B.: Ich möchte ein Geschenk für eine Kollegin bis $50"),
    },
  },
  async ({ userGoal }) => { 		
    const run = await giftAgent.run({		// hier starten wir den Agenten mit 12 Schritten und 15 s Timeout
      input: userGoal,
      maxSteps: 12,
      timeoutMs: 15000,
    });

    return {
      status: run.status,
      gifts: run.output?.gifts ?? [],
      debug: run.debugInfo, // kann später entfernt werden
    };
  }
);

Die ChatGPT App kann dieses MCP-Tool wie jedes andere aufrufen, und Ihr GiftGenius-Widget kann das UI auf Basis von gifts aufbauen. Sie erhalten einen mehrstufigen Workflow „unter der Haube“, und nach außen wirkt es für ChatGPT wie ein einzelnes, sauberes Tool.

10. Typische Fehler beim Entwurf mehrstufiger Prozesse

Fehler Nr. 1: „Das Modell soll es schon richten, ich gebe ihm einfach alle Tools.“
Wenn einem Agenten ein Dutzend semantisch überlappender Tools ohne klare Systeminstruktion und Phasen zur Verfügung stehen, beginnt das Modell zu „taumeln“: dasselbe auf verschiedene Arten aufzurufen, Anfragen zu duplizieren, in Schleifen zu geraten. Besser Zeit in das Design investieren: das Szenario in Phasen teilen, die Liste der Tools in jeder Phase begrenzen und die Strategie im System-Prompt explizit festhalten.

Fehler Nr. 2: Keine Schritt- und Zeitlimits.
Ohne maxSteps und timeout bekommen Sie in der Produktion schnell „umherirrende“ runs, die Ressourcen fressen, während Nutzerinnen/Nutzer nichts sehen. Limits sind keine „Option“, sondern Basis-Hygiene. Wichtig ist auch, das Überschreiten sinnvoll zu behandeln statt stumm mit 500 zu scheitern.

Fehler Nr. 3: Keine expliziten Abschlusskriterien.
Das Modell beendet den run, wenn es meint, „es reicht“, doch dieses Verständnis weicht oft von den Business-Anforderungen ab. Wenn man Erfolgskriterien (wie viele Geschenke, welche Felder, welche Filter bestanden) nicht formalisiert und prüft, leidet der UX: heute fünf tolle Optionen, morgen eine mittelmäßige und drei Duplikate.

Fehler Nr. 4: Wiederholte Tool-Aufrufe werden nicht verfolgt.
Der Agent kann im Muster „Fehler erhalten → Anfrage um zwei Wörter umformulieren → dasselbe Tool erneut aufrufen“ feststecken. Wenn Sie wiederholte Aufrufe nach (toolName, args) nicht nachhalten, bleiben diese Schleifen unsichtbar, bis Sie die Logs prüfen und sich wundern. Einfache Zähler und Hashes der Argumente helfen enorm.

Fehler Nr. 5: Orchestrierung und Business-Logik in einem Tool vermischen.
Manchmal versucht man, einen ganzen Workflow in ein einziges MCP-Tool oder eine Agentenfunktion zu packen: Suche, Filter, Formatierung, Entscheidung. Am Ende verliert der Agent seinen Sinn – das Modell kann den Prozess nicht schrittweise steuern, Sie verlieren Transparenz und die Möglichkeit, Teile wiederzuverwenden. Besser ist es, die einzelnen Etappen als eigenständige Tools herauszulösen und dem Agenten deren Komposition zu geben.

Fehler Nr. 6: Kein Bezug zu Zustand und Checkpoints.
Ein mehrstufiger Prozess ohne Speicherung von Zwischenzustand und Checkpoints wird fragil: Fällt in der Mitte etwas aus, muss die Nutzerin/der Nutzer von vorne beginnen. Das ist besonders kritisch in Szenarien, in denen zwischen Schritten hin‑ und hergesprungen oder später zurückgekehrt wird. Nutzen Sie einen State Store, speichern Sie Phase, Profil, Kandidaten und erlauben Sie dem Agenten, an der richtigen Stelle fortzusetzen.

Fehler Nr. 7: Die UX-Schicht wird ignoriert.
Entwickelnde sind manchmal so sehr mit dem internen Agent-Workflow beschäftigt, dass sie vergessen, dass die Nutzerin/der Nutzer nur das Widget und Chat-Nachrichten sieht. Wenn das UI keinen verständlichen Fortschritt zeigt („Wir suchen Geschenke …“, „Wir filtern Optionen …“), wirkt die App „eingefroren“ oder „tut nichts“, selbst wenn der Agent gerade einen komplexen Prozess orchestriert. Denken Sie beim Planen eines mehrstufigen run sofort mit, wie er sich im Interface widerspiegelt.