Dynamische Steuerung der Tool‑Liste (Tool Gating)

1. Was ist Tool Gating und warum ist das überhaupt ein Thema für eine eigene Vorlesung

Bisher haben wir es in vereinfachten Beispielen so gemacht: Wir beschreiben einen Satz von Tools für die App, binden einen MCP‑Server an – und all das ist für das Modell immer verfügbar. Aus Sicht von „in 5 Minuten eine Demo bauen“ funktioniert das. Aus Produktsicht – eher nicht.

Tool Gating ist ein Pattern, bei dem die Liste der dem Modell verfügbaren Tools nicht fix ist, sondern vom Kontext abhängt: vom Workflow‑Schritt, den Benutzerrechten, dem Datenzustand usw.

Das Wichtigste: Die Liste der tools ist nicht „ein zufälliger Sammelhaufen von allem, was Sie jemals geschrieben haben“, sondern Teil des Szenariodesigns. Wenn Sie den Workflow entwerfen, entwerfen Sie faktisch auch, welche Tools das Modell in jeder Phase sehen darf.

Einfache Analogie: Sie geben einem Praktikanten in der Bank nicht sofort Zugriff auf alle Systeme – zuerst nur Ansicht, dann einfache Aktionen, später ernstere. Hier gilt dieselbe Logik, nur dass der Praktikant die LLM ist.

2. Das Problem „alle Tools auf einmal“: Kontextverschmutzung und Sicherheit

Wenn man dem Modell Dutzende von Tools gibt, leidet es in mehreren Dimensionen gleichzeitig: Kontextüberladung, Verwechslungen bei der Auswahl und Sicherheitsfragen. Studien von OpenAI/Anthropic zeigen, dass je mehr Funktionen Sie im Kontext beschreiben, desto schlechter trifft das Modell die richtige.

Erstens sind Tool‑Definitionen Tokens: Name, Beschreibung, JSON Schema. Eine Liste aus 30–40 Tools frisst leicht ein paar Tausend Tokens. Das sind genau die Tokens, die Sie für den Dialogverlauf, Benutzerkontext oder Beispiele guter Antworten einsetzen könnten. Stattdessen liest das Modell einen „Roman“ über Ihre APIs.

Zweitens: Wenn Tools ähnlich sind, kommt das Modell durcheinander. Wenn Sie search_products und get_product_details haben, kann es versuchen, get_product_details direkt mit einer Textanfrage aufzurufen, weil die Beschreibung passender schien.

Dazu kommt die Sicherheitsfrage. Es gibt ein trockenes, aber wichtiges Prinzip der geringsten Privilegien (Least Privilege): Ein System sollte nur die Fähigkeiten haben, die es „hier und jetzt“ wirklich braucht. Wenn das Modell schon im Kennenlern‑Schritt von checkout weiß, reicht eine kleine Prompt‑Injektion vom Nutzer, damit es zu früh eine Zahlung auslösen möchte. Tool Gating ist ein praktischer Spezialfall dieser Rechte‑Minimierung: In jedem Schritt aktivieren wir nur das Nötige.

Und schließlich die UX. Wenn das Modell unerwartet etwas „Magisches“ tut, womit der Nutzer nicht gerechnet hat (z. B. einen Auftrag anlegt, während die Person noch ein Geschenk auswählt), sinkt das Vertrauen in Ihre App rapide.

3. GiftGenius als Illustration von Tool Gating

Nehmen wir unseren Case GiftGenius und schauen ehrlich auf die Schritte:

1. Interview: Wir erheben Alter, Geschlecht, Interessen der zu beschenkenden Person, Budget usw.
2. Auswahl: Wir suchen im Katalog und zeigen Ideen.
3. Checkout: Wenn der Nutzer das Geschenk ausgewählt hat, wechseln wir zur Abwicklung.

Wenn das Modell schon im Interview‑Schritt search_products, add_to_cart und checkout kennt, kann es:

• die Suche zu früh aufrufen, noch bevor es sinnvolle Präferenzen gesammelt hat;
• sofort „bestellen“ wollen, weil der Nutzer fallen lässt: „Oh, das ist gut, das nehme ich.“

Die richtige Variante ist, die Liste der verfügbaren Tools im Verlauf der Schritte zu ändern. Unten betrachten wir genau so ein Szenario: Im Interview‑Schritt sind nur Tools zum Speichern von Präferenzen sichtbar, im Auswahl‑Schritt Suche und In-den‑Warenkorb‑Legen, im Checkout‑Schritt dann das eigentliche checkout.

Fassen wir das in einer kleinen Tabelle zusammen:

INTERVIEW

save_preference, finish_interview

search_products, add_to_cart, checkout

BROWSING

search_products, get_product_details, add_to_cart

save_preference

checkout

CHECKOUT

search_products, get_product_details, add_to_cart, checkout

Beachten Sie: Das Tool checkout erscheint nur, wenn es tatsächlich etwas abzuschließen gibt, und nur im passenden Schritt. Das ist das klassische Beispiel für Tool Gating in einem Commerce‑Szenario.

4. Strategien für Tool Gating: nach Zustand, Rollen, Ressourcen

Am weitesten verbreitet ist state‑based Gating (Gating nach Workflow‑Schritten): Die Liste der Tools hängt vom Zustand des Szenarios ab. Das heißt, Sie halten irgendwo eine Variable step vor, und anhand dieser wird bestimmt, welche Tools aktiv sind und welche nicht.

Aber nicht nur die Schritte können die Tools beeinflussen.

Manchmal verwenden Sie role‑based Gating (nach Benutzerrollen): Admins haben Zugang zu Service‑Tools (z. B. den Katalog neu indizieren), normale Nutzer nur zu Endnutzer‑Tools. Manchmal resource‑based Gating (nach Ressourcenstatus): Das Tool „Tür öffnen“ erscheint nur, wenn der Ressourcenstatus „Tür geschlossen“ ist.

Um es greifbar zu machen, beschreiben wir das als kleine Funktion in TypeScript. Stellen wir uns vor, wir haben einen Kontext mit Schritt, Rolle, aktuellem Warenkorb und dem Zustand einer Ressource:

type WorkflowStep = 'interview' | 'browsing' | 'checkout';
type UserRole = 'user' | 'admin';

interface WorkflowContext {
  step: WorkflowStep;
  role: UserRole;
  cartItems: number; // wie viele Artikel im Warenkorb
  doorIsClosed: boolean; // Beispiel für Resource-based Gating: Zustand einer konkreten Ressource
}

Jetzt beschreiben wir, welche Tools es im System überhaupt gibt und wie man sie filtert:

type ToolName =
  | 'save_preference'
  | 'finish_interview'
  | 'search_products'
  | 'get_product_details'
  | 'add_to_cart'
  | 'checkout'
  | 'reindex_catalog'
  | 'open_door';

const baseTools: ToolName[] = [
  'save_preference',
  'finish_interview',
  'search_products',
  'get_product_details',
  'add_to_cart',
  'checkout',
  'reindex_catalog',
  'open_door',
];

Hier ist open_door ein Beispiel für ein Tool, das vom Zustand einer konkreten Ressource abhängt (ob die Tür geschlossen ist oder nicht).

Und die eigentliche Gating‑Funktion:

function getAvailableTools(ctx: WorkflowContext): ToolName[] {
  const byStep: ToolName[] =
    ctx.step === 'interview'
      ? ['save_preference', 'finish_interview']
      : ctx.step === 'browsing'
      ? ['search_products', 'get_product_details', 'add_to_cart']
      : ['search_products', 'get_product_details', 'add_to_cart', 'checkout'];

  const checkoutAllowed =
    ctx.step === 'checkout' && ctx.cartItems > 0
      ? byStep
      : byStep.filter((t) => t !== 'checkout');

  const withAdmin =
    ctx.role === 'admin'
      ? [...checkoutAllowed, 'reindex_catalog']
      : checkoutAllowed;

  const withResources =
    ctx.doorIsClosed
      ? [...withAdmin, 'open_door']
      : withAdmin.filter((t) => t !== 'open_door');

  return withResources;
}

Hier sieht man gut drei „Schichten“ des Gatings:

• nach Schritt (byStep);
• nach Benutzerrolle (withAdmin);
• nach Ressourcenstatus (withResources und Flag doorIsClosed).

Das ist kein SDK‑Code, sondern nur eine architektonische Skizze. Genau so denkt man typischerweise über Tool Gating: Es gibt einen vollständigen Katalog von Tools und eine Funktion, die basierend auf dem Kontext eine Teilmenge zurückgibt.

5. Wo Tool Gating in der App‑Architektur lebt

Verknüpfen wir das kurz mit dem, was Sie schon über den ChatGPT‑App‑Stack wissen.

Theoretisch funktioniert das MCP‑Protokoll so

Im MCP müssen Tools nicht fest in statisches JSON verdrahtet sein: Ein Server kann die Liste dynamisch je Sitzung zurückgeben. Außerdem gibt es in der Spezifikation den Mechanismus „capabilities“, mit dem der Server signalisiert, dass sich seine Tool‑Liste ändern kann, und die Benachrichtigung tools/list_changed, damit der Client (ChatGPT/Agent) die Tool‑Liste neu abfragt, wenn sich etwas geändert hat.

Formal können Sie das so umsetzen, und manche MCP‑Clients funktionieren mit einer dynamischen MCP‑Tool‑Liste. Stand heute unterstützen ChatGPT‑Apps jedoch kein tools/list_changed. Vielleicht ändert sich das in Zukunft, aber derzeit funktioniert dieser Weg nicht.

Was dagegen funktioniert

Sie halten Zustand und die Liste der verfügbaren Methoden auf Modellseite. Sie können dem Modell einfach in jedem Schritt den state und die Liste der verfügbaren tools als Teil des „Weltbilds“ schicken: Im Systemprompt den aktuellen Schritt explizit beschreiben (zum Beispiel step = "browsing"), Schlüssel‑Flags (zum Beispiel cartItems = 2, role = "user") und nur das Teilset an Tools beilegen, das gerade erlaubt ist.

Das Modell kann Tools nicht von sich aus „vergessen“, folgt aber sehr gut expliziten Anweisungen wie: „In diesem Schritt darfst du nur diese Funktionen verwenden…“. Am Ende wirkt die gesamte Gating‑Logik für das Modell wie ein einfacher Vertrag: Hier ist der aktuelle Szenariozustand, hier ist die Liste der Knöpfe, die du drücken darfst, den Rest gibt es für dich quasi nicht. Das erfordert keine besondere „Magie“ – es genügt, state und die Liste der tools in den Anfragen an das Modell beim Wechsel zwischen Schritten konsequent zu aktualisieren.

Außerdem können Sie Anweisungen im structuredContent ergänzen, etwa so:

{
  "instructions": {
    "current_step": "browsing",
    "enabled_mcp_tools": ["search", "apply"]
  }
}

Ebenso können Sie Schutz auf Ebene Ihrer Business‑Logik ergänzen. Selbst wenn die Tool‑Liste schon „aktualisiert“ ist, ist es wichtig, die Gating‑Logik in den Handlern zu duplizieren, weil:

• das Modell Anweisungen und/oder Daten vergessen kann, wenn die Unterhaltung lang ist;
• das Modell versuchen kann, ein „Phantom“-Tool aufzurufen, das im vorherigen Schritt verfügbar war;

Ein gutes Design ist deshalb: Wir „verstecken“ die Tools vor dem Modell und prüfen im Handler zusätzlich, ob die Aktion jetzt erlaubt ist.

6. Modellseitiges vs. logisches Tool Gating

Im Anschluss an den vorigen Abschnitt: Alles, was auf Ebene des Modellaufrufs passiert (welche Flags/step Sie in den Prompt legen), ist modellseitiges Gating, und die Prüfungen in den Tool‑Handlern sind das logische.

In der Regel ist es sinnvoll, zwei Schichten zu trennen:

1. Modellseitiges Gating – das Modell weiß, dass ein Tool „jetzt erlaubt“ ist, weil Sie in den Anweisungen explizit schreiben, welche Funktionen in diesem Schritt verfügbar sind. Für das Modell sieht die Welt so aus: „Hier ist der aktuelle state, hier ist ein Satz von Knöpfen, andere gibt es nicht.“
2. Logisches Gating – Prüfungen innerhalb des Tools selbst. Selbst wenn das Modell checkout zu früh aufzurufen versucht (wegen Cache, Phantom‑Gedächtnis oder weil Sie ihm in einem früheren Schritt doch dieses Tool gezeigt haben), prüft der Handler den aktuellen Zustand und lehnt freundlich ab: sinngemäß „Wähle zuerst ein Geschenk aus, dann schließen wir die Bestellung ab“ (und wirft nicht einfach eine Exception!).

Warum braucht es beide Schichten? Weil die Infrastruktur rund um LLMs und die Szenarien selbst sich nicht ideal verhalten:

• das Modell kann sich merken, dass es checkout irgendwann einmal gesehen hat, und sich in Überlegungen oder gar in einem Tool‑Call darauf beziehen;
• Sie selbst können irrtümlich in einem Schritt einen breiteren Satz an tools übergeben als nötig, und das Modell beginnt überflüssige Funktionen zu nutzen;
• Clients/Middlewares können die Modellaufruf‑Konfiguration cachen und eine Zeit lang den alten Tool‑Satz senden.

In der Praxis bedeutet das schlicht: Sich darauf zu verlassen „wir haben das Tool nicht in tools gelegt – also wird es nie wieder aufgerufen“ ist gefährlich. Prüfungen in den Handlers sind dennoch nötig.

Beispiel für logisches Gating im Handler checkout in pseudo‑TypeScript:

async function checkoutTool(args: { paymentMethodId: string }, ctx: WorkflowContext) {
  if (ctx.step !== 'checkout') {
    return {
      error: 'Checkout not available yet. Please finish selecting a gift first.',
    };
  }

  if (ctx.cartItems === 0) {
    return {
      error: 'Your cart is empty. Add at least one gift before checkout.',
    };
  }

  // ... eigentliche Checkout-Logik
}

So eine Antwort hilft sowohl dem Nutzer als auch dem Modell: Das Modell sieht einen strukturierten Fehler und kann seinen Plan anpassen.

7. Wie man Tool Gating mit UI und Widget verknüpft

Tool Gating findet nicht nur auf dem Server statt. UI/UX sollte die Änderungen ebenfalls „spüren“.

Das Widget kennt den aktuellen Schritt (wir haben bereits über den widgetState gesprochen und darüber, dass dieser State zum Beispiel currentStep halten kann). Das Modell auch, denn der Schritt wird entweder explizit an die Tools übergeben oder im Systemprompt festgehalten. Wichtig ist, dass UI und der Satz aktiver Tools synchronisiert sind.

Wenn das Modell meint, der aktuelle Schritt sei „Auswahl“, das Widget aber die Oberfläche „Interview“ zeigt, ist der Nutzer irritiert. Umgekehrt – die UI zeigt bereits den Button „Bezahlen“, aber checkout ist noch nicht verfügbar – steht das Modell seltsam da: Der Button ist da, aber die Funktion „geht nicht“.

Ein kleines Ablaufdiagramm eines Schritts mit Tool Gating:

flowchart TD
  A[Der Nutzer füllt das Interview im Widget aus] --> B[Das Widget ruft das Tool save_preference / finish_interview auf]
  B --> C[MCP / Backend aktualisiert state.step]
  C --> D[Der Server ändert den Toolsatz für die Sitzung]
  D --> E[Der ChatGPT‑Client aktualisiert die für das Modell verfügbaren Tools]
  E --> F[Das Modell stellt neue Fragen
und/oder ruft neue Tools auf]
  C --> G[Das Widget erhält den neuen Schritt über widgetState
und passt die UI an]

Für den Nutzer wirkt das wie ein ganz gewöhnlicher Assistent/Wizard: zunächst ein paar Fragen, dann eine Geschenkliste, dann die finale Bestätigung. Unter der Haube werden jedoch gleichzeitig die UI umgeschaltet, die Tool‑Liste und die Anweisung für das Modell.

Im Next.js‑Widget lässt sich das sehr einfach ausdrücken. Nehmen wir an, Sie halten step im widgetState:

type Step = 'interview' | 'browsing' | 'checkout';

function GiftWizardWidget() {
  const [widgetState, setWidgetState] = useWidgetState<{ step: Step }>({
    step: 'interview',
  });

  if (widgetState.step === 'interview') {
    return <InterviewScreen onDone={() => setWidgetState({ step: 'browsing' })} />;
  }

  if (widgetState.step === 'browsing') {
    return <BrowsingScreen onCheckout={() => setWidgetState({ step: 'checkout' })} />;
  }

  return <CheckoutScreen />;
}

Hier zeigen wir die Tools nicht direkt, implizieren aber, dass der Wechsel von step im State mit dem Wechsel des Tool‑Satzes im Backend abgestimmt ist. Wir haben gesehen, wie die Schritte im Widget leben. Kehren wir nun auf die MCP‑Server‑Seite zurück und schauen, wie dieselben step und der Warenkorbinhalt die Tool‑Liste beeinflussen.

8. Beispiel: dynamische tools/list auf dem MCP‑Server

Sie haben bereits gesehen, dass ein MCP‑Server den Sitzungszustand halten und für Entscheidungen nutzen kann. In der separaten Betrachtung des GiftGenius‑Cases wird ein Beispiel gezeigt, in dem der Zustand step und der Warenkorb (cart) entweder im Speicher oder in Redis liegen. Davon hängt ab, welche Tools der Server als Antwort auf eine Listenanfrage zurückgibt.

Es kann gut sein, dass ChatGPT‑Apps zum Zeitpunkt dieser Vorlesung toolChanged innerhalb der aktuellen Sitzung bereits unterstützen. Es wäre sehr logisch, daher denke ich, es ist nur eine Frage der Zeit. Für diesen Fall habe ich eine kurze Skizze, wie man Tool Gating mit den nativen Mechanismen des MCP‑Protokolls umsetzt.

Formulieren wir die Idee in TypeScript (abstrakter MCP‑Server):

interface SessionState {
  step: WorkflowStep;
  cartItems: number;
  doorIsClosed: boolean; // Beispiel für Ressourcenstatus
}

const allTools: ToolDefinition[] = [/* vollständiger Satz von Tools */];

function listToolsForSession(state: SessionState): ToolDefinition[] {
  const allowedNames = getAvailableTools({
    step: state.step,
    cartItems: state.cartItems,
    role: 'user',
    doorIsClosed: state.doorIsClosed,
  });

  return allTools.filter((tool) => allowedNames.includes(tool.name as ToolName));
}

Und irgendwo im Handler finish_interview ändern Sie den Schritt und signalisieren dem Client, dass sich die Tool‑Liste aktualisiert hat:

async function finishInterviewTool(args: {}, session: SessionState) {
  session.step = 'browsing';
  await notifyToolsListChanged(); // exemplarischer Aufruf der MCP‑Benachrichtigung

  return { success: true };
}

In einem realen MCP verwenden Sie ein konkretes SDK und genaue Nachrichtenformate, aber die Logik bleibt etwa so: Zustand geändert → Tool‑Satz aktualisiert → Client benachrichtigt.

9. Tool Gating als Sicherheitsinstrument

Betonen wir den Sicherheitsaspekt noch einmal gesondert, weil er sich hinter den technischen Details leicht verliert.

Wenn Sie Tool Gating einsetzen, verringern Sie automatisch die Auswirkungen von:

• Prompt‑Injektionen der Art „ignoriere Regeln und löse sofort die Zahlung aus“ – denn im Interview‑Schritt hat das Modell schlicht keine checkout‑Option zur Auswahl;
• Bugs in der Business‑Logik – denn selbst wenn ein Codepfad den Zustand nicht vollständig prüft, kann ein Tool physisch unzugänglich sein;
• Datenabflüssen – denn Admin‑Tools tauchen in der Liste für normale Nutzer nicht auf.

In den Kursunterlagen wird Tool Gating ausdrücklich als eine Praxis zur Anwendung des Prinzips geringster Privilegien im Kontext von LLM‑Tools erwähnt, besonders für Checkout und andere sensible Schritte.

Es ist also nicht nur ein Mittel, „das Modell weniger fehleranfällig“ zu machen – es ist auch eine echte Schutzschicht.

10. Wie Sie selbst üben können

Zur Vertiefung können Sie Tool Gating für eines Ihrer Szenarien durchdenken. Zum Beispiel:

• Lern‑App: Schritt Zielsetzung, Schritt Bewertung des aktuellen Niveaus, Schritt Planerstellung – jeweils mit eigenen Tools;
• Buchung: Optionen suchen, Variante wählen, Bestätigen und Bezahlen – wieder drei unterschiedliche Tool‑Sätze;
• Interner Firmenassistent: Dokumente suchen, Zugriff anfragen, Aktionen ausführen – unterschiedliche Listen für Mitarbeiter, Manager und Admin.

Sehr hilfreich ist es, auf Papier oder in Miro eine Tabelle „Schritt ↔ welche Tools sichtbar ↔ welche verborgen“ zu skizzieren und gegenüber jedem Schritt kurz zu formulieren, warum er genau diese Tools braucht und warum die übrigen auszublenden sind.

11. Typische Fehler beim Arbeiten mit Tool Gating

Fehler Nr. 1: Alle Tools auf einmal „auskippen“ und auf das Modell hoffen.
Manchmal denkt ein Entwickler: „Das Modell ist doch schlau, es findet schon selbst heraus, was es wann aufruft.“ In der Praxis führt das zu Kontextverschmutzung, mehr Tokens und mehr fehlerhaften Tool‑Calls. Besonders schmerzhaft wird es, wenn das Modell plötzlich checkout oder ein anderes gefährliches Tool aufruft – einfach, weil es in der Liste steht. Tool Gating ist genau dafür da, diese Situation zu vermeiden.

Fehler Nr. 2: Glauben, dass das Verstecken eines Tools in der Liste genügt.
Selbst wenn der MCP‑Server ein Tool nicht mehr in tools/list liefert, kann sich das Modell daran „erinnern“, und die Infrastruktur kann einen alten Tool‑Satz cachen. Das Ergebnis ist ein Aufruf eines Phantom‑Tools. Wenn der Handler keine logischen Prüfungen durchführt, kann er eine Aktion „zur falschen Zeit“ ausführen. Deshalb braucht es Gating sowohl auf der Ebene der Tool‑Liste als auch innerhalb der Handlers.

Fehler Nr. 3: Asynchronität zwischen UI und Tool‑Satz.
Es kommt vor, dass das Widget bereits auf "checkout" umgeschaltet und einen hübschen „Bezahlen“-Button zeigt, Sie auf MCP‑Seite aber vergessen haben, checkout in die Liste der verfügbaren Tools aufzunehmen. Das Modell versteht nicht, warum es den Button gibt, das Tool aber nicht verfügbar ist, und beginnt seltsame Antworten zu produzieren. Oder umgekehrt: Der Tool‑Satz ist schon geändert, das Modell ist bereit, Geschenke auszuwählen, aber das Widget stellt noch Interview‑Fragen. Beim Workflow‑Design ist es wichtig, UI‑Zustand und Tool‑Liste synchron zu aktualisieren.

Fehler Nr. 4: Zu komplexe Gating‑Logik.
Manchmal inspiriert die Möglichkeit so sehr, dass man eine halbe BPMN‑Diagrammwelt mit Dutzenden Zuständen und Bedingungen für alle Lebenslagen baut. Am Ende versteht nicht einmal der Autor nach einer Woche, warum ein Tool nur donnerstags in Schaltjahren verfügbar ist. Für die meisten Apps reicht eine einfache Abfolge von Schritten und klare Regeln: nach Schritt, Benutzerrolle und ein paar Schlüssel‑Flags im Zustand.

Fehler Nr. 5: Tool Gating hart im Prompt verankern, ohne Server‑Unterstützung.
Man versucht manchmal, alles mit Worten im Systemprompt zu lösen: „In diesem Schritt verwende das Tool checkout nicht“ – ohne die reale Tool‑Liste zu ändern und ohne Prüfungen im Backend zu ergänzen. Das Modell hält sich manchmal daran, manchmal nicht – das Verhalten wird instabil. Prompt‑Anweisungen sind nützlich, sollten aber die technische Gating‑Schicht in der Infrastruktur ergänzen, nicht ersetzen.

Fehler Nr. 6: Rollen und Zugriffsrechte ignorieren.
In Apps mit Authentifizierung wird oft vergessen, dass Tool Gating nicht nur den Schritt, sondern auch die Rolle berücksichtigen muss. Am Ende sieht ein Nutzer ohne Adminrechte doch (oder schlimmer: kann aufrufen) Tools, die für Support oder DevOps gedacht sind. Im Modul zur Autorisierung haben Sie gesehen, wie Rechte in den Kontext gelangen; hier ist es wichtig, diese Information bei der Auswahl des Tool‑Satzes zu nutzen.

Fehler Nr. 7: Kein Monitoring fehlerhafter Tool‑Calls.
Wenn Sie sich beim Gating vertan haben, sind typische Symptome vermehrte Fehler wie „Tool not available“, „MethodNotFound“ oder Ihre eigenen logischen Fehler wie „Checkout is not available yet“. Wenn Sie solche Ereignisse nicht statistisch erfassen, merken Sie womöglich lange nicht, dass Nutzer regelmäßig gegen unsichtbare Wände laufen. Einfaches Logging und Zähler pro Fehlertyp helfen sehr, Probleme im Design von Workflow und Gating rechtzeitig zu erkennen.