Ein Betriebshandbuch für Agenten
Ein Agent, der für andere arbeitet, braucht eine Seite, auf der steht, wer zuständig ist, was er darf, wo sein Protokoll liegt und wie man ihn anhält. Die Vorlage – und der Ablauf für den Tag, an dem etwas schiefgeht.
Boaz Lichtenstein
Ein Agent, den du allein für dich betreibst, lebt in deinem Kopf. Du weißt, was er darf und wo du ihn abschaltest. Sobald er für ein Team arbeitet – oder du drei Wochen im Urlaub bist –, reicht das nicht mehr. Dann braucht er ein Betriebshandbuch.
Das klingt nach Bürokratie und ist eine Seite.
Die eine Seite
AGENT: Retouren-Vorprüfung
Zweck Sortiert eingehende Retouren vor und schreibt
Antwortentwürfe. Entscheidet nichts.
Zuständig Jana M. · Vertretung: Malik S.
Auslöser Ereignis: neues Ticket in der Kategorie „Retoure“
Darf allein Tickets und Bestellungen lesen, Entwürfe anlegen
Mit Freigabe Antwort senden (durch Menschen im Ticketsystem)
Nie Erstattung auslösen, Kundendaten ändern
Liest Ticketsystem, Bestellexport
Schreibt nur Entwürfe im Ticketsystem
Modell Cloud-Modell; Kundendaten gehen an den Anbieter
(Vertrag zur Auftragsverarbeitung liegt vor)
Budget höchstens 200 Läufe/Tag, 150 Euro/Monat
Protokoll Ticket-Historie + Lauf-Log im Ordner „Agenten-Logs“
Prüfung Testsatz mit 24 Fällen; nach jeder Änderung und
monatlich
Notaus Ticketsystem › Automationen › „Retouren-Vorprüfung“
deaktivieren
Nächste Durchsicht 15.01.2027Jede Zeile beantwortet eine Frage, die im Ernstfall jemand stellt. Wenn du eine Zeile nicht ausfüllen kannst, hast du etwas gefunden, das vor dem Betrieb geklärt gehört.
Die Zeilen, die am häufigsten fehlen
Zuständig – mit Namen. „Das Team“ ist niemand. Eine Person und eine Vertretung.
Die Datenwege. Was liest der Agent, und wohin geht es? Bei einem Cloud-Modell gehen die gelesenen Daten an den Anbieter. Das ist bei Kundendaten eine Datenschutzfrage, die vor dem ersten Lauf beantwortet sein muss.
Das Protokoll. Wo steht, was der Agent wann getan hat? Ohne Protokoll lässt sich nach einem Vorfall weder der Schaden bestimmen noch die Ursache.
Der Notaus. Nicht „den Agenten deaktivieren“, sondern der genaue Pfad.
Den Notaus üben
Gib die Seite jemandem, der den Agenten nicht gebaut hat, und lass ihn den Agenten anhalten. Stoppe die Zeit. Dauert es länger als eine Minute, ist die Beschreibung zu ungenau – oder der Zugang fehlt. Beides willst du nicht an dem Tag herausfinden, an dem es darauf ankommt.
Wenn etwas schiefgeht
Fünf Schritte, in dieser Reihenfolge:
- Anhalten. Erst der Notaus, dann alles andere.
- Sichern. Protokoll und Ergebnisse festhalten, bevor irgendetwas geändert oder gelöscht wird.
- Schaden begrenzen. Was ist hinausgegangen, wer muss es wissen, was lässt sich zurückholen?
- Ursache finden. War es der Auftrag, eine Quelle, ein Werkzeug, eine Manipulation von außen, ein Modellwechsel?
- Absichern, dann wieder starten. Der Vorfall wird zu einem Fall im Testsatz. Erst wenn der Agent ihn besteht, läuft er wieder.
Der fünfte Schritt ist der, der gern übersprungen wird. Ohne ihn hast du ein Problem behoben und keines verhindert.
Wer was ändern darf
Ein Satz im Prompt, ein neues Werkzeug, ein anderes Modell – jede dieser Änderungen kann das Verhalten kippen. Leg fest:
- Wer ändern darf.
- Dass vor und nach jeder Änderung der Testsatz läuft.
- Wo die Änderung festgehalten wird – am einfachsten in der Versionskontrolle, in der Prompt, Regeldatei und Skills ohnehin liegen.
Und beachte die Änderungen, die du nicht selbst machst: Anbieter tauschen Modelle hinter gleichbleibenden Namen aus. Nach jeder solchen Ankündigung läuft der Testsatz.
Das Verzeichnis darüber
Aus den einzelnen Seiten entsteht von selbst das Verzeichnis aller Agenten – dieselbe Liste, die du aus Automationen überwachen kennst. Einmal im Quartal gehst du sie durch: Was läuft noch, was nutzt jemand, was darf mehr, als es braucht?
Diese Dokumentation ist nicht nur für dich. Die nächsten beiden Stationen zeigen, an welchen Stellen Gesetz und Geschäftsleitung genau danach fragen.