So entwerfen Sie ein Gespräch für einen KI-Agenten, Schritt für Schritt

Um ein Gespräch für einen KI-Agenten zu entwerfen, schreiben Sie es als Beispiel-Turns aus, bevor jemand baut: Legen Sie die Aufgabe des Agenten und seine Eskalationsgrenze fest, schreiben Sie den Regelfall, zweigen Sie in jede Richtung ab, in der er scheitern kann, spezifizieren Sie den Systemaufruf hinter jeder Antwort, bestimmen Sie die Stimme mit Beispielpaaren und lassen Sie das Ergebnis dann prüfen und schriftlich abnehmen. Das ist die ganze Methode. Der Rest dieses Beitrags geht jeden Schritt im Detail durch: was Sie erstellen, welcher Fehler ihn am häufigsten scheitern lässt und woran Sie erkennen, dass der Schritt erledigt ist.

Vorab zwei Voraussetzungen. Erstens brauchen Sie die rohen Anforderungen: welche Systeme es gibt, was die Kundschaft tatsächlich fragt, wem die Warteschlange für die Übergabe an Menschen gehört. Unser Leitfaden zu Anforderungen für die Business-Analyse enthält die Fragen, mit denen Sie sie zusammentragen. Zweitens hilft es zu wissen, was das fertige Design enthält; die Liste der Abschnitte steht in unserer Vorlage für Gesprächsdesign.

Schritt 1: Aufgabe und Eskalationsgrenze festlegen

Schreiben Sie einen Absatz, der festhält, was der Agent übernimmt, was er nie übernimmt und unter welcher genauen Bedingung er die Kundschaft an einen Menschen übergibt. Dieser letzte Satz ist die Eskalationsgrenze, und er ist der folgenreichste Satz im Design: Alles andere wird von ihm begrenzt.

Ergebnis: eine Umfangsbeschreibung, die Aufgaben mit erkennbarem Endpunkt nennt. „Erklärt eine Abbuchung, kündigt ein Abonnement, nimmt eine Kartenreklamation bis zur Einreichung auf“ ist eine Aufgabe. „Bearbeitet Fragen zur Abrechnung“ ist ein Thema, und Themen lassen sich nicht testen.

Typischer Fehler: Eskalation als Nebensache, etwa „gibt an den Support ab, wenn er nicht weiterweiß“. Eskalation ist ein gestalteter Moment mit eigenem Beispiel-Turn, eigener Datenübergabe und einem konkreten Auslöser: die ausdrückliche Bitte um einen Menschen, ein gescheiterter Wiederholungsversuch, ein Schwellenwert für die Stimmung, ein regulierter Themenbereich.

Fertig, wenn: jemand von außerhalb des Projekts den Absatz liest und zehn echte Kundenanfragen korrekt in „Agent“ oder „Mensch“ einsortiert, ohne Sie etwas zu fragen.

Schritt 2: Den Regelfall als echte Turns schreiben

Schreiben Sie das Hauptszenario als abwechselnde Beispiel-Turns, von der ersten Nachricht bis zur Lösung. Jede Zeile sollte ein Satz sein, den der Agent tatsächlich senden könnte. Schreiben Sie beide Seiten: was die Kundschaft plausibel sagt, auch in der halbfertigen Formulierung, und wie der Agent antwortet.

Ergebnis: ein Dialog, den jede Person in wenigen Minuten von oben bis unten lesen kann, jeweils für ein Szenario. Legen Sie Szenarien nicht zusammen: Eine Reklamation und eine Kündigung sind zwei Designs, die sich eine Begrüßung teilen.

Typischer Fehler: Zusammenfassen. Ein Kasten mit „Agent fragt nach der Bestellnummer“ verbirgt jede Entscheidung, auf die es ankommt: wie er fragt, ob er erklärt, wozu er die Nummer braucht, was er mit einer unvollständigen Antwort macht. Gegen eine Zusammenfassung kann niemand ein Veto einlegen, also kommt das Veto stattdessen im Abnahmetest (UAT), wenn eine Änderung teuer ist.

Fertig, wenn: Sie das Gespräch mit jemandem aus dem Team laut lesen können und es trägt, und ein Stakeholder auf einen bestimmten Satz zeigen und ihm widersprechen kann. Einwände in dieser Phase zeigen, dass der Prozess funktioniert.

Schritt 3: Die Fehlerabzweigungen ergänzen

Jetzt verzweigen Sie. Vier Gruppen decken das meiste ab, was der Produktivbetrieb dem Agenten zuwirft: Das System hinter einer Antwort ist ausgefallen oder langsam; die Kundschaft ist wütend; die Anfrage liegt außerhalb des Umfangs; die Person ist beleidigend oder probiert einen Jailbreak aus. Jede Abzweigung wird wie der Regelfall geschrieben, als echte Turns mit einem klaren Ende.

Ergebnis: für jedes Szenario die Abzweigungen, die zutreffen. Die Timeout-Abzweigung entscheidet, was der Agent in Sekunde drei und in Sekunde dreißig sagt. Die Abzweigung für wütende Kundschaft entscheidet, wo die Entschuldigung endet und die Eskalation beginnt. Die Abzweigung für Anfragen außerhalb des Umfangs benennt, wohin der Agent weiterleitet. Die Missbrauchs-Abzweigung entscheidet, worauf sich der Agent nicht einlässt und wann er das Gespräch beendet.

Typischer Fehler: eine einzige Standardentschuldigung, die überall wiederverwendet wird: „Etwas ist schiefgelaufen, bitte versuchen Sie es später erneut“ als Antwort auf ein Timeout, eine abgelehnte Erstattung und eine Absage nach Richtlinie. Die Kundschaft merkt das, und der Lenkungsausschuss auch. Die zweite Variante dieses Fehlers ist, Fehlerfälle an den Standard-Fallback der Plattform abzugeben, was heißt, dass sie gar niemand entworfen hat.

Fertig, wenn: jede Abzweigung bewusst endet: gelöst, weitergeleitet oder eskaliert. Wenn ein Szenario noch keine Fehlerabzweigungen hat, ist es noch nicht entworfen; warum der Regelfall kein Design ist, haben wir an anderer Stelle beschrieben.

Schritt 4: Die Tools hinter jeder Antwort spezifizieren

Jeder Agent-Turn, der eine Tatsache nennt oder eine Aktion ausführt, beruht auf einem Systemaufruf. Schreiben Sie ihn neben den Turn: das System, den Endpunkt oder die Operation, die Parameter und für jeden Parameter, ob der Agent die Kundschaft danach fragt, ihn aus dem Kontext ableitet oder aus der Sitzung erhält.

Ergebnis: eine Spezifikation pro Aufruf: was er liest oder schreibt, ob ein erneuter Versuch unbedenklich ist, was der Agent beim Warten sagt und was er sagt, wenn der Aufruf fehlschlägt, und genau dort setzen Ihre Abzweigungen aus Schritt 3 an.

Typischer Fehler: das unbenannte System. „Der Agent prüft den Bestellstatus“ übersteht jede Prüfung, weil niemand dafür zuständig ist. Dann stellt sich Tage vor dem Go-live heraus, dass „Können Sie meine Bestellung prüfen?“ drei Systeme berührt und niemand entschieden hat, was passiert, wenn eines davon in ein Timeout läuft.

Fertig, wenn: eine Person aus der Entwicklung, die nie im Raum war, das Design lesen und jede Anbindung auflisten kann, die für die Umsetzung nötig ist, ohne ein Meeting.

Schritt 5: Die Stimme mit Beispielpaaren festlegen

Adjektive lassen sich nicht übertragen. „Freundlich, aber professionell“ ergibt bei jeder Person, die daran schreibt, einen anderen Agenten. Beispielpaare lassen sich übertragen: Dieser Satz trifft die Stimme; dieser fast gleiche Satz verfehlt sie, und hier steht, warum.

Ergebnis: eine kurze Liste von Merkmalen der Stimme, jeweils mit einem Paar aus passendem und unpassendem Satz, dazu Tonregeln für die Situationen, die sie brauchen: eine Anfrage ablehnen, schlechte Nachrichten überbringen, sich für einen Ausfall entschuldigen. Fünf Merkmale reichen völlig. Zwanzig sind ein Styleguide, den niemand liest.

Typischer Fehler: eine Sperrliste verbotener Wörter. Eine Sperrliste sagt Schreibenden, was sie meiden sollen, und nichts darüber, was sie schreiben sollen, also füllt jede Person die Lücke mit dem eigenen Gespür, und die Stimme des Agenten driftet von Turn zu Turn.

Fertig, wenn: zwei Personen jeweils einen neuen Turn in der festgelegten Stimme entwerfen und eine dritte nicht erkennen kann, wer welchen geschrieben hat.

Schritt 6: Mit den Menschen prüfen, die später ein Veto einlegen könnten

Jedes Agent-Projekt hat Beteiligte, die es noch vor dem Start stoppen können: Recht oder Compliance; die Betriebsleitung, der die Warteschlange gehört, in die Sie eskalieren; die Entwicklung, die für die Systeme zuständig ist, die Ihre Tools berühren; und die IT-Sicherheit, wenn Kundendaten fließen. Holen Sie diese Personen jetzt an den Tisch und legen Sie ihnen das Design vor, die Fehlerabzweigungen zuerst.

Ergebnis: ein geprüftes Design, in dem jeder Einwand in einem geänderten Turn aufgelöst ist. „Die Rechtsabteilung will weichere Formulierungen bei der Absage“ ist erst erledigt, wenn der Absage-Turn sich tatsächlich anders liest.

Typischer Fehler: eine Demo statt des Designs. Demos sammeln Komplimente; Designs sammeln Korrekturen, und Korrekturen sind es, weswegen Sie gekommen sind. Die andere Variante dieses Fehlers ist, Prüfende erst nach Beginn der Umsetzung einzuladen, wenn jeder Einwand einen Sprint statt einer Minute kostet.

Fertig, wenn: jede benannte Person mit Vetorecht die Fehlerabzweigungen gelesen hat und ihre Einwände als Änderungen im Dokument stehen.

Schritt 7: Die schriftliche Abnahme einholen

Zustimmung in einem Meeting verflüchtigt sich. Lassen Sie eine namentlich benannte Person eine bestimmte Version des Designs schriftlich abnehmen, bevor die Umsetzung beginnt.

Ergebnis: eine dokumentierte Abnahme: wer abgenommen hat, welche Version, an welchem Datum. Die Version zählt so viel wie der Name. Ein Design, das sich nach der Abnahme weiter ändert, wurde nie abgenommen.

Typischer Fehler: Kopfnicken im Workshop als Zustimmung zu werten. In Monat vier der Umsetzung sieht jemand aus der Führungsebene, wie der Agent eine Erstattung ablehnt, und sagt: „So haben wir das nicht vereinbart.“ Wenn nichts aufgeschrieben wurde, hat diese Person im Zweifel recht, und jemand trägt den Aufwand für die Nacharbeit. Für die Fassung dieses Problems mit Kundenbeteiligung siehe den Beitrag zur Abnahme eines Agent-Designs durch das Kundenunternehmen.

Fertig, wenn: Sie beantworten können, ohne Ihr Postfach zu durchsuchen, wer das Design abgenommen hat, welche Version und wann.

Schritt 8: Weitergeben und das Design aktuell halten

Das Design geht jetzt an die, die bauen: an ein internes Team, an einen Anbieter oder an die Konfiguration einer Plattform. Es ist der Bezugspunkt, an dem die Umsetzung gemessen wird, und das funktioniert nur, wenn es währenddessen weiter stimmt.

Ergebnis: eine Übergabe plus eine Arbeitsvereinbarung: Wenn eine Randbedingung der Umsetzung eine Änderung an Formulierung oder Ablauf erzwingt, und das wird sie, fließt die Änderung noch in derselben Woche ins Design zurück. Das abgenommene Design und der ausgelieferte Agent dürfen nicht unbemerkt auseinanderlaufen.

Typischer Fehler: die Übergabe als Ziellinie. Ein Design, das sich von der Umsetzung entfernt, wird binnen Wochen nicht mehr zu Rate gezogen, und dann beginnt jede Meinungsverschiedenheit wieder bei null. Ein veraltetes Design ist schlimmer als keines, weil es mit Autorität lügt.

Fertig, wenn: im UAT gegen das Design getestet wird und jede Abweichung entweder als Fehler in der Umsetzung oder als dokumentierte Änderung am Design eingeordnet ist.

Wie lange dauert das alles?

Weniger als die Alternative. Der Regelfall für ein Szenario kostet einen Workshop-Nachmittag. Die Fehlerabzweigungen und Tool-Spezifikationen brauchen ein paar Arbeitssitzungen mehr, vor allem weil sie Entscheidungen erzwingen, die Menschen aufgeschoben haben. Prüfung und Abnahme laufen im Tempo Ihrer Organisation. Stellen Sie das einem Sprint gegenüber, der neu gemacht werden muss, oder einer Sitzung des Lenkungsausschusses, in der niemand die Frage „Was sagt er, wenn die API ausfällt?“ beantworten kann, und das Design ist der günstige Teil des Projekts.

Nichts davon verlangt eine bestimmte Software. Teams arbeiten die Abfolge in Dokumenten und Tabellen ab, und Schritt 8 ist meist die Stelle, an der sie leise eingehen. Wir haben Klate gebaut, weil das Design, das diese Methode hervorbringt (die Beispiel-Turns, Fehlerabzweigungen, Tool-Schnittstellen, Beispielpaare zur Stimme und der Abnahmevermerk), Besseres verdient, als über einen Foliensatz und eine Tabelle verstreut zu sein. Wenn Sie die Methode an einem Ort gebündelt sehen möchten, führt Sie die Produktseite durch.