Die Fälle gestalten, die ein Agent an eine Person weitergibt

Auslöser, die sich aufschreiben und testen lassen

• Durch Richtlinie vorbehalten: Beschwerden mit Hinweis auf rechtliche Schritte, als schutzbedürftig markierte Kunden, alles, was laut Ihren Regeln eine Person entscheidet
• Fehlende oder widersprüchliche Informationen, die ein klärender Schritt nicht aufgelöst hat
• Ein Systemfehler jenseits des Retry-Budgets und jeder Schreibvorgang mit unbekanntem Ergebnis
• Ein unbekannter Fall: eine Dokumentvorlage, ein Lieferantentyp oder eine Sprache, die im Testset fehlt
• Ein überschrittenes Schritt- oder Kostenbudget; der Leitfaden von Anthropic zu Agenten beschreibt das als Abbruchbedingung, etwa eine maximale Zahl von Iterationen
• Der Kunde verlangt nach einer Person

Beachten Sie, was fehlt: die Selbsteinschätzung des Modells als einziger Auslöser. Die angegebene Sicherheit eines Modells ist nicht von sich aus kalibriert. Sie darf zusätzliche Eskalationen auslösen, aber die obige Liste sollte nicht von ihr abhängen.

Eskalation in beide Richtungen testen

Eskalation kann auf zwei Arten scheitern. Eine unnötige Übergabe kostet Prüfzeit und untergräbt das Vertrauen in den Agenten. Eine versäumte Übergabe lässt den Agenten einen Fall abschließen, den er nicht hätte anfassen dürfen, was meist teurer ist. Der Leitfaden von Anthropic zu Agenten-Evals empfiehlt zu testen, wann ein Verhalten eintreten soll und wann nicht. Für Eskalationen braucht das Testset Fälle, die übergeben werden müssen, und ähnliche Fälle, die nicht übergeben werden dürfen, und die Ergebnisse sollten getrennt ausgewiesen werden.

Was die Übergabe enthält

Das folgende Format ist eine Skizze für einen hypothetischen Agenten, der Schadenfälle aufnimmt. Es soll in dem Werkzeug angezeigt werden, in dem die Person ohnehin arbeitet, nicht als Rohdaten gelesen werden.

case_id: clm-40517
reason: CONTRADICTORY_INFORMATION
question_for_reviewer: >
  Damage date on the form (12 Aug) is before the policy start (15 Aug).
  The photos are dated 18 Aug. Which date applies?
done:
  - claim created, status awaiting_assessment (ref CL-889120)
failed: []
unknown:
  - acknowledgement email: send timed out, delivery not confirmed
not_done:
  - coverage check, blocked on the date question
proposed_next_step: >
  If 18 Aug applies, run coverage check. If 12 Aug applies,
  decline under clause 4.2 after review.
evidence: [form.pdf, photo_metadata.json, policy_P-2.pdf]
agent_version: claims-intake 2026.10.2
answer_due_by: next working day 12:00

Zwei Felder tragen den größten Teil des Nutzens. Die Frage sollte eine sein, die die Person beantworten kann, keine vage Bitte, den Fall zu prüfen. Die Liste der unbekannten Punkte zeigt, welche externen Wirkungen eingetreten sein können oder nicht, damit die Person prüft, bevor sie etwas wiederholt.

Die Warteschlange auf der anderen Seite

Eine Eskalationswarteschlange braucht eine verantwortliche Person, eine Zuordnung nach Grund, damit die passende Fachkraft jeden Fall sieht, und ein Ziel dafür, wie lange ein Fall warten darf. Das SRE Workbook von Google behandelt solche Ziele als Verhältnis guter Ereignisse zu allen Ereignissen, mit einer schriftlichen Regel für den Fall, dass sie verfehlt werden, und dieselbe Struktur funktioniert für das Alter der Warteschlange.

Legen Sie fest, ob die Person den Fall abschließt oder die Frage beantwortet und ihn zurückgibt. Die Rückgabe funktioniert, wenn der Zustand des Agenten gespeichert ist: interrupt() in LangGraph hält einen Lauf zum Beispiel an, bis er mit der Antwort der Person fortgesetzt wird. In beiden Fällen darf der Agent nach der Eskalation nicht mehr in den Fall schreiben.

Was Eskalationen Ihnen zeigen

Halten Sie fest, wie die Person jeden Fall gelöst hat, in einem strukturierten Feld statt in Freitext. Nach einigen Wochen zeigen die Gründe, wo die Arbeit liegt. Kommen die meisten Eskalationen von einer unzuverlässigen Abfrage, reparieren Sie das Tool. Kommen sie von einer bestimmten Dokumentvorlage, nehmen Sie Fälle dafür ins Testset auf. Lösen Menschen eine Kategorie jedes Mal gleich, ist sie womöglich reif für den Agenten, nachdem er die Tests bestanden hat.

Wo die Gestaltung von Eskalationen scheitert

Die häufigsten Fehler sind organisatorischer Natur: eine Warteschlange ohne verantwortliche Person, Eskalation als Ablage für jeden unbequemen Fall, eine prüfende Person ohne Zugriff auf das System, das der Agent genutzt hat, oder eine Übergabe in einem separaten Werkzeug, das niemand ansieht. Die Microsoft-Leitlinie zu kompensierenden Transaktionen sagt Ähnliches für gescheiterte Vorgänge: Ist ein manueller Eingriff nötig, sollte der Alarm den genauen Grund enthalten. Ein guter erster Schritt: Listen Sie Ihre heutigen Eskalationsgründe auf, schreiben Sie zu jedem die Frage, die eine Person beantworten müsste, und prüfen Sie, ob der Agent sie formulieren kann.