Stell dir Montag, 9:12 Uhr, vor. Der AI-Agent schreibt: „Lead bearbeitet, Aufgabe erstellt, Manager zugewiesen.“ Du öffnest das CRM. Der Lead ist da, aber ohne Verantwortliche:n. Bei den Aufgaben ist nichts. Und im Postfach liegt ein E-Mail-Entwurf, dessen Versand niemand angefordert hat.
Die Antwort des Agenten klingt sicher. Sie kann sogar höflich die Schritte aufzählen: gelesen, abgeglichen, erstellt, geprüft. Für das Geschäft ist aber nicht wichtig, wie schön die Arbeit beschrieben ist. Wichtig ist, was danach im Arbeitssystem passiert ist.
Deshalb fühlen sich die ersten Tests mit Agenten oft seltsam an. Du hast die Routine scheinbar übergeben und prüfst danach CRM, Aufgaben, Dateien und Empfänger:innen doch wieder von Hand. Das ist keine Delegation. Das ist die alte manuelle Arbeit mit der zusätzlichen Pflicht, einen optimistischen Bericht zu lesen. Der Prozess ist so höflich kaputtgegangen, dass man ihn kaum ausschimpfen mag.
Die Lösung besteht nicht darin, vom Agenten noch einen längeren Bericht zu verlangen. Du brauchst einen kurzen Acceptance Contract: Welcher Zustand muss entstehen, wodurch wird er belegt, was darf nicht passieren, was darf der Agent schreiben und wann muss er stoppen.
1. Schöner Output, Aktivität und Ergebnis sind verschiedene Dinge
Bevor du die Kontrolle einrichtest, trenne drei Dinge, die leicht verwechselt werden. Sie können Teile derselben Arbeit sein, ersetzen einander aber nicht.
Output: Was der Agent gesagt oder gezeigt hat
Output ist ein Text, eine Tabelle, eine Kontaktliste, ein E-Mail-Entwurf oder die Nachricht „alles erledigt“. Er hilft dir zu verstehen, was der Agent gesehen hat und wie er seine Schlussfolgerung erklärt. Allein beweist er aber nicht, dass sich etwas verändert hat.
Der Satz „Aufgabe für den Manager erstellt“ beantwortet keine grundlegenden Fragen: Wo genau ist diese Aufgabe, wer ist zuständig, welche Felder sind ausgefüllt, ist kein Duplikat entstanden? Sichere Sprache wird nicht zu einem Eintrag im System, nur weil am Ende ein Punkt steht.
Activity: Was unterwegs passiert ist
Activity ist die Liste der Handlungen: Der Agent hat eine E-Mail geöffnet, Felder verglichen, eine Karte gefunden, Daten vorbereitet, versucht, eine Aufgabe zu erstellen. Ein solches Protokoll kann helfen, wenn du einen Sonderfall oder Fehler untersuchen musst. Viele Schritte machen den Endzustand jedoch nicht richtig.
Ein Drucker, der fleißig vierzig Seiten des falschen Dokuments druckt, zeigt ebenfalls beeindruckende Aktivität. Nützlicher wird sie dadurch leider nicht.
Outcome: Was nachweislich verändert wurde
Outcome ist der Zielzustand im Arbeitssystem. Das benötigte Objekt wurde erstellt oder aktualisiert, die Schlüsselfelder sind korrekt, die richtige Person sieht es dort, wo sie es erwartet, und die verbotene Handlung ist nicht passiert.
Wenn der Agent eine Aufgabe erstellen sollte, ist das Outcome nicht die Nachricht „Aufgabe erstellt“. Es ist eine konkrete Aufgabe im richtigen Projekt, mit der richtigen zuständigen Person, den Angaben für den nächsten Schritt und ohne Duplikat. Sollte der Agent auf eine Anfrage antworten, kann das Outcome zu Beginn nur ein gespeicherter Entwurf sein. Eine versendete E-Mail ist eine andere, riskantere Handlung.
Diagnose Nr. 1: Der Bericht ersetzt die Prüfung
Das Symptom ist einfach: Das Team nimmt die Arbeit an, weil im Bericht „erledigt“ steht, kann aber nicht schnell das konkrete erstellte oder veränderte Objekt zeigen. Einige Tage später tauchen fehlende Aufgaben, Duplikate oder Einträge in der falschen Warteschlange auf. Dann ist es schon schwer zu verstehen, wo das Problem begonnen hat.
Auch die Lösung ist einfach: Verlange für jede ausgeführte Handlung eine prüfbare Spur. Das kann eine ID oder ein Link zum Objekt sein, eine Kontrolle der Werte in Pflichtfeldern, eine gespeicherte Datei oder ein Eintrag im Protokoll. Niemand muss jeden Tag jedem Link folgen. Der Prozess muss eine solche Prüfung aber ermöglichen, ohne eine archäologische Expedition durch Browser-Tabs.
2. Die fünf Teile eines kurzen Acceptance Contract
Ein Acceptance Contract ist kein juristisches Dokument und keine technische Spezifikation mit fünfzig Seiten. Für den ersten Prozess reicht oft eine Karte. Ihre Aufgabe ist es, unterschiedliche Auslegungen von „erledigt“ schon vor dem Start zu beseitigen.
1. Zielzustand
Beschreibe, was nach der Arbeit des Agenten wahr sein muss. Nicht die Handlung, sondern den Zustand.
Schlecht: „Der Agent qualifiziert Anfragen.“ Besser: „Für eine Anfrage, die den Regeln entspricht, gibt es genau einen Eintrag in der festgelegten Pipeline; darin sind Quelle und Thema ausgefüllt; der Manager sieht den nächsten Schritt.“ Diesen Zustand kannst du ohne Rätselraten sehen und prüfen.
Versuche am Anfang nicht, mit einem Satz den gesamten Vertrieb oder den gesamten Support abzudecken. Ein enger Zustand begrenzt den Wert des Tests nicht. Er macht ihn messbar.
2. Nachweis
Benenn jetzt, wodurch der Zielzustand bestätigt wird. Ein Nachweis ist keine Nacherzählung des Agenten über das, was er angeblich getan hat. Es ist eine Spur im System oder eine wiederholbare Prüfung.
Die Prüfung kann zum Beispiel einen Eintrag über einen Schlüssel finden, die Werte der Pflichtfelder bestätigen, den Speicherort einer Datei zeigen oder den Empfänger mit einer abgestimmten Liste abgleichen. Audit Trail und deterministische Prüfungen senken das Risiko eines stillen Fehlers, machen den Prozess aber nicht fehlerfrei.
3. Verbotene Nebenwirkungen
Benenn nicht nur das gewünschte Ergebnis, sondern auch, was nicht passieren darf. Zum Beispiel: keine Duplikate erstellen, den Eigentümer einer vorhandenen Karte nicht ändern, keine E-Mails versenden, keine Dateien löschen, keine Einträge außerhalb der festgelegten Warteschlange bearbeiten.
Dieser Teil ist kritisch, weil Nebenwirkungen oft schmerzhafter sind als eine ausgelassene Handlung. Einen fehlenden Eintrag kannst du meist später erstellen. Eine nicht abgestimmte Nachricht oder ein beschädigter vorhandener Eintrag kann deutlich mehr manuelle Wiederherstellung brauchen.
4. Schreibrecht
Trenne ausdrücklich, was der Agent lesen darf, was er vorbereiten darf und was er selbst verändern darf. Das ist kein Misstrauen gegenüber dem Werkzeug, sondern eine normale Verantwortungsgrenze.
Für den ersten Test kann der Agent eingehende Anfragen lesen, sie klassifizieren, Entwürfe erstellen und Daten zu einer separaten Warteschlange hinzufügen. Das Versenden einer E-Mail, das Ändern eines wichtigen Status oder das Löschen eines Eintrags kann bei einem Menschen bleiben. So baut man AI-Systeme mit kontrollierten Aktionen: über festgelegte Grenzen statt über unbegrenzten Zugang in der Hoffnung auf das Beste.
5. Stoppbedingung
Der letzte Teil legt fest, wann der Agent nicht raten darf. Er muss stoppen, den Fall markieren und ihn an einen Menschen übergeben.
Eine Stoppbedingung kann ein fehlendes Pflichtmerkmal, widersprüchliche Daten, ein unbekannter Anfragetyp, ein ähnlicher vorhandener Eintrag oder eine Handlung außerhalb des Schreibrechts sein. Das ist kein Versagen des Agenten. Es ist das richtige Verhalten, wenn der Preis eines Fehlers höher ist als der Nutzen eines automatischen Schritts.
3. Diagnose Nr. 2: Der Agent bekam eine Aufgabe, aber keine Grenzen
Anfragen wie „bearbeite alle E-Mails“, „bring Ordnung ins CRM“ oder „bereite Antworten für Kund:innen vor“ klingen für einen Menschen mit Kontext verständlich. Für einen Agenten ist das ein zu großer Raum für Annahmen. Er kann versuchen, hilfreich zu sein, doch das Team erhält Entscheidungen, die niemand abgestimmt hat.
Bedingtes Beispiel: Ähnliche Daten in einer Anfrage
Angenommen, der Agent überträgt Anfragen aus E-Mails ins CRM. Es kommt eine E-Mail von einem Unternehmen, dessen Name einem bestehenden Kunden ähnelt, aber die Kontaktperson ist eine andere. Ohne Stoppbedingung kann der Agent einen neuen Lead erstellen, unvereinbare Daten zusammenführen oder eine alte Karte überschreiben.
Der Contract verändert das Verhalten. Der Agent erstellt einen Eintrag nur nach eindeutigen Regeln. Wird ein ähnlicher Eintrag gefunden, bearbeitet er keinen von beiden, hinterlässt eine Markierung für den Manager und fügt einen Nachweis hinzu, warum er gestoppt hat. Der Mensch entscheidet über den konkreten Sonderfall, statt am Ende der Woche Daten wiederherzustellen.
Bedingtes Beispiel: Antwort fertig, Versand aber nicht abgestimmt
Eine andere Situation: Der Agent analysiert eine Anfrage und bereitet eine Antwort vor. Der Text kann passend sein, der Empfänger korrekt, aber der Contract sagt: „Externer Versand nur nach Approve.“ Dann ist das angenommene Outcome ein Entwurf im richtigen Postfach, der mit der Anfrage verknüpft ist. Keine versendete E-Mail.
Diese Trennung bedeutet nicht, dass du auf Automatisierung verzichtest. Du prüfst Klassifikation, Routing und Datenaufbereitung, ohne dem ersten Test ein nicht rückgängig zu machendes Kommunikationsrisiko hinzuzufügen.
Eine Grenze macht den Fehler sichtbar
Wenn die Grenzen beschrieben sind, findest du die tatsächliche Ursache einer Störung leichter. Ist es ein Problem mit Eingangsdaten, Routing-Regeln, Zugriffsrechten oder dem Annahmekriterium? Ohne Contract verschmelzen all diese Ursachen zu einem unscharfen „der Agent hat irgendwo nicht richtig gearbeitet“.
Darum muss ein Mensch die Absicht, die Grenzen riskanter Handlungen und das Annahmekriterium festlegen, auch wenn der Agent selbst Routinen durchläuft. Der Agent führt die Route aus. Die Verantwortung dafür, welche Route zulässig ist, bleibt bei der Person, die den Prozess besitzt.
4. Canary, QA und menschliches Approve: Jede Komponente belegt etwas anderes
Teste den Agenten nicht sofort auf der gesamten Operation. Wähle eine enge Route, bei der Eingangsdaten, gewünschtes Ergebnis und eine Möglichkeit zum Stoppen eines Fehlers klar sind. Einen solchen kontrollierten Start nennt man canary.
Was ein canary belegt
Ein erfolgreicher canary belegt nur, dass der Agent eine konkrete Route unter festgelegten Bedingungen durchlaufen hat. Er hat zum Beispiel eine Anfrage eines bestimmten Typs genommen, einen Entwurf erstellt und eine prüfbare Spur hinterlassen.
Er belegt keine Bereitschaft für alle Sprachen, alle ungewöhnlichen E-Mails, alle künftigen Änderungen im Prozess oder jede neue Integration. Ein erfolgreicher Durchlauf ist ein Grund für den nächsten vorsichtigen Test, nicht dafür, dem Agenten alle Schlüssel für Büro, Lager und Kaffeemaschine zu geben.
Was QA prüft
QA prüft den Contract: Wurde der Zielzustand erreicht, gibt es einen Nachweis und sind keine verbotenen Nebenwirkungen passiert? Ein Teil der Prüfungen kann deterministisch sein: Es existiert genau ein Eintrag, die notwendigen Felder sind ausgefüllt, der Status ist richtig, der Entwurf wurde nicht zu einer versendeten Nachricht.
Solche Prüfungen sind besonders nützlich, wenn ein Mensch zuvor immer wieder denselben manuellen Abgleich wiederholt hat. Sie ersetzen bei einem komplexen Fall nicht den gesunden Menschenverstand, aber sie nehmen dir die Notwendigkeit, dem Agenten jedes Mal aufs Wort zu glauben.
Wann Approve verpflichtend bleibt
Ein menschliches Approve solltest du für externe, sensible oder schwer rückgängig zu machende Handlungen beibehalten: das Versenden einer Nachricht, die Übertragung von Daten, die Änderung eines wichtigen Status, die Bearbeitung eines finanziell oder für die Reputation wichtigen Eintrags. Es ist auch nötig, wenn Daten widersprüchlich sind oder den Regeln nicht entsprechen.
Sieh dir im Klar-Fall zu E-Mail-Anfragen an, wie eine begrenzte Route maschinelle Verarbeitung und menschliche Kontrolle verbinden kann. Ihr Wert liegt nicht in einem Versprechen vollständiger Autonomie, sondern in einem klar abgegrenzten Prozess, den du prüfen kannst.
5. Diagnose Nr. 3: Erfolg wird geprüft, das Ausbleiben von Schaden aber nicht
Das Team sieht eine erstellte Aufgabe und setzt ein Häkchen. Gleichzeitig kann der Agent aber eine zweite gleiche Aufgabe erstellt, die falsche Person zugewiesen oder eine fremde Warteschlange berührt haben. Wenn du nur auf den positiven Teil des Outcome schaust, geht ein stiller Fehler leicht vorbei.
Füge eine negative Prüfung hinzu
Benenn für jedes erwartete Ergebnis mindestens eine Prüfung nach dem Muster „Das ist nicht passiert“. Im CRM kann das das Ausbleiben eines Duplikats nach Schlüssel sein. Bei E-Mails das Ausbleiben einer versendeten Nachricht. Bei Dateien das Ausbleiben des Überschreibens des Originals. Bei Aufgaben das Ausbleiben von Änderungen in einem fremden Projekt.
Eine negative Prüfung muss nicht kompliziert sein. Sie erkennt einfach an: Der Erfolg eines Schritts rechtfertigt keine unerwünschte Folge an anderer Stelle.
Verwechsle Kontrolle nicht mit Misstrauen
Der Contract macht den Agenten nicht zum Verdächtigen. Er macht Erwartungen für den Eigentümer, das operative Team und die Person sichtbar, die den Prozess einrichtet. Wenn die Regeln klar sind, wird leichter verständlich, was korrigiert werden muss: Daten, Route, Rechte oder Annahmebedingung.
Kontrolle gibt auch eine ehrliche Antwort auf die Frage „Können wir den Test ausweiten?“. Nicht weil der Bericht überzeugender geworden ist, sondern weil eine konkrete Route ein geprüftes Ergebnis ohne verbotene Folgen hinterlassen hat.
6. Die minimale Ergebniskarte und dein erster Test
Für den ersten Test brauchst du kein kompliziertes Dashboard. Nimm einen wiederkehrenden Prozess, dessen Ergebnis in einem konkreten System sichtbar ist und bei dem du einen Fehler ohne Schaden stoppen kannst. Zum Beispiel das Vorbereiten von Antwortentwürfen oder das Erstellen von Aufgaben aus klar strukturierten Anfragen.
Eine Karte mit fünf Feldern
Schreib auf einer Seite auf: Zielzustand, Nachweis, verbotene Nebenwirkungen, Schreibrecht und Stoppbedingung. Ergänze ein Szenario mit normalen Daten und eines mit mehrdeutigen Daten. So prüfst du nicht nur, ob der Agent vorankommt, sondern auch, ob er unnötige Handlungen unterlässt.
Erwarte nicht, dass die erste Version alle Sonderfälle abdeckt. Ihre Aufgabe ist bescheidener und nützlicher: Sie soll zeigen, ob du ein konkretes Ergebnis annehmen kannst, ohne manuell in verschiedenen Systemen danach suchen zu müssen.
Ein erster Schritt
Wähle eine Handlung, die der Agent angeblich schon „abschließt“, und schreibe heute dafür einen Zielzustand und einen Nachweis im Arbeitssystem auf. Damit beginnt eine Prüfung, der du vertrauen kannst.