Du baust einen Agenten, wo eine Regel gereicht hätte

Der Auftrag klingt vernünftig, und in vielen Häusern fällt er ungefähr so: Die Bearbeitung der Eingangsrechnungen soll endlich von allein laufen. Jemand baut dafür einen Agenten. Nach ein paar Wochen ist er fertig, und in der Vorführung macht er alles richtig. Er liest die Rechnung, erkennt den Lieferanten, schlägt das Konto vor, legt den Vorgang an. Die Runde ist zufrieden, und das zu Recht.

Dann kommt der Alltag. Am Dienstag ordnet der Agent dieselbe Rechnungsart einem anderen Konto zu als am Montag. Am Donnerstag legt er einen Vorgang zweimal an, weil er den ersten nicht wiedergefunden hat. Am Freitag läuft alles glatt. Niemand kann erklären, woran der Unterschied lag, denn am Ablauf hat sich nichts geändert. Also schaut die Buchhaltung ab jetzt wieder jeden einzelnen Vorgang an. Der Ablauf ist damit langsamer als vorher, nur mit mehr Technik darin.

Das ist kein Modellproblem, und das nächste Modell wird es auch nicht lösen. Es ist ein Bauentscheid, den am Anfang niemand als Entscheidung wahrgenommen hat. Der Weg stand nämlich längst fest: Rechnung kommt rein, Pflichtangaben prüfen, Lieferant zuordnen, Konto zuordnen, Vorgang anlegen, bei Abweichung an einen Menschen geben. Fünf feste Schritte und eine Ausnahme.

Für einen Weg, der feststeht, ist ein Agent das falsche Werkzeug. Ein Agent ist ein KI-Programm aus Modell, Werkzeugen und Gedächtnis, das ein Ziel bekommt und den Weg dorthin selbst wählt. Genau dafür ist er gebaut, und genau das ist hier das Problem: Er entscheidet jedes Mal neu und liefert deshalb jedes Mal etwas anderes.

Woran du merkst, dass bei euch ein Agent arbeitet, wo eine Regel reichen würde

Der einfachste Test dauert zwei Minuten: Schick denselben Vorgang zweimal durch den Ablauf und vergleich die beiden Ergebnisse. Kommt zweimal dasselbe heraus, ist alles in Ordnung. Kommt zweimal etwas leicht Verschiedenes heraus, obwohl die Eingabe identisch war, hast du an dieser Stelle Unbestimmtheit eingebaut. Bei einer Aufgabe mit Beurteilungsspielraum ist das erwünscht. Bei einer Kontozuordnung ist es ein Defekt.

Das zweite Anzeichen ist eine Frage, die im Haus niemand beantworten kann: Wie oft liegt das Ding eigentlich richtig? Nicht gefühlt, sondern als Zahl über die letzten hundert Durchläufe. Diese Zahl entsteht nur, wenn jemand Evals angelegt hat, also feste Testfälle mit bekannter richtiger Antwort, gegen die der Ablauf regelmäßig läuft. Fehlen sie, ersetzt der Eindruck der letzten drei Tage die Messung, und der Eindruck schwankt mit dem Tag.

Das dritte Anzeichen ist die Prüfschleife, die wächst statt zu schrumpfen. Ein Ablauf, der Arbeit abnehmen sollte, erzeugt am Ende Kontrollarbeit. Das ist der Punkt, an dem die Rechnung kippt, denn geprüft wird jetzt jeder Vorgang, während vorher nur die Ausnahmen geprüft wurden. Wer die Durchlaufzeit von Anstoß bis Ergebnis misst, sieht das sofort. Wer nur fragt, ob es sich schneller anfühlt, sieht es nie.

Das vierte Anzeichen steht auf der Rechnung. Niemand kann sagen, was ein einzelner Durchlauf kostet, weil niemand den Tokenverbrauch je Vorgang anschaut. Ein Token ist die kleinste Texteinheit, in der ein Modell liest und schreibt, und jeder Denkschritt eines Agenten hat darin einen Preis. Ein Agent, der einen feststehenden Ablauf jedes Mal neu durchdenkt, bezahlt Denkarbeit für eine Frage, die längst beantwortet ist.

Diese vier Anzeichen zusammen erklären eine unangenehme Zahl: Rund neun von zehn Agenten-Projekten erreichen die Produktion nie. Der Grund ist fast nie ein zu schwaches Modell. Der Grund ist fehlende Verlässlichkeit.

Warum der Griff zum Agenten sich richtig anfühlt

Dieser Fehler entsteht nicht aus Nachlässigkeit, sondern aus einer echten Stärke des Werkzeugs. Ein Agent verzeiht dir eine unfertige Prozessbeschreibung. Du musst den Ablauf nicht zu Ende denken, du schreibst das Ziel hin, und er sucht sich den Rest. Genau deshalb steht der Prototyp nach zwei Tagen und die saubere Regelstrecke nach zwei Wochen. Wer unter Zeitdruck baut, nimmt den kürzeren Weg, und das ist nachvollziehbar.

Dazu kommt, dass im Alltag vier verschiedene Dinge denselben Namen bekommen. Die reine Automatisierung führt einen festgelegten Ablauf aus, ohne dass ein Modell mitentscheidet. Der Assistent antwortet auf Zuruf und tut sonst nichts. Der halbautonome Agent bekommt ein Ziel und wählt seinen Weg selbst. Das orchestrierte Agentensystem verteilt eine Aufgabe auf mehrere spezialisierte Agenten und koordiniert sie. Im Gespräch heißt alles davon „Agent", und weil das Wort gerade überall steht, wandert die Erwartung mit. Für die meisten Fälle im Mittelstand reicht die erste Stufe mit ein paar KI-Schritten darin, kein echter Agent.

Der Preis für die Verwechslung ist Unbestimmtheit an Stellen, die vorher berechenbar waren. Ein deterministischer Schritt liefert bei gleicher Eingabe jedes Mal dieselbe Ausgabe, ein Modellschritt nicht. Jede Stelle, an der ein Modell entscheidet, ist damit eine Stelle, die schwanken kann. Verlässlichkeit wird überhaupt erst messbar, wenn wenige Stellen schwanken, denn dann weißt du, wo du suchen musst, wenn etwas schiefgeht. Bei einem Agenten, der frei wählt, kann jede Stelle die Ursache sein.

Der zweite Teil der Rechnung ist der Ablauf selbst. Ein schlechter Prozess wird durch Automatisierung nicht besser, er wird nur schneller schlecht und ist danach in Software zementiert. Wer den Ablauf nie aufgeschrieben hat, merkt beim Bauen nicht, dass drei Schritte darin seit Jahren niemand mehr braucht. Das erklärt einen Teil der ernüchterndsten Zahl dieses Themas: Rund 95 Prozent der KI-Projekte bringen keinen messbaren Rückfluss, meist weil die Datenbasis fehlt und der erhoffte Nutzen nie definiert wurde.

Kurz gesagt

Ein Agent entscheidet jedes Mal neu, eine Regel liefert jedes Mal dasselbe. Beides ist ein Vorteil, nur nicht an derselben Stelle.

Fünf Schritte, die den Agenten auf seine Stelle zurückschneiden

Schritt für Schritt

Zeichne den Ablauf auf, bevor du entscheidest, wer ihn ausführt

Eine Seite reicht: je Schritt die Eingabe, die Ausgabe, die Stelle, an der jemand entscheidet, die Daten, die dieser Schritt braucht, und das System, das er anfasst. Das ist die unspektakulärste Stunde des ganzen Vorhabens und die einzige, die dir sagt, welcher Teil wirklich unklar ist. Streich dabei zuerst die Schritte, die niemand mehr braucht, sonst automatisierst du sie mit.

Markier jeden Schritt mit einer von zwei Farben: Weg steht fest oder jemand muss urteilen

Die erste Farbe bekommt alles, was du einem neuen Kollegen als Regel diktieren könntest, etwa „bei dieser Lieferantennummer immer dieses Konto". Die zweite Farbe bekommt alles, wo zwei erfahrene Leute zu unterschiedlichen Ergebnissen kämen, etwa die Einschätzung, ob eine Reklamation kulant behandelt wird. In den meisten Abläufen im Mittelstand ist die erste Farbe deutlich häufiger als erwartet.

Bau jeden feststehenden Schritt als Regel und gib nur die Urteilsschritte an ein Modell

Eine Regel ist billiger im Betrieb, schneller im Durchlauf und liefert jedes Mal dasselbe Ergebnis. Sie ist außerdem prüfbar, weil du sie lesen kannst, während die Entscheidung eines Modells im Nachhinein nur schwer zu rekonstruieren ist. Der Ablauf, der dabei herauskommt, ist meistens eine klassische Automatisierung mit zwei oder drei KI-Schritten darin, und genau das ist das Ziel, nicht ein Kompromiss.

Schreib zehn Testfälle auf, bevor der Ablauf in den echten Betrieb geht

Nimm zehn Vorgänge aus der Vergangenheit, bei denen du die richtige Antwort kennst, darunter zwei, die damals schiefgegangen sind. Lass den Ablauf gegen diese zehn Fälle laufen, jedes Mal, wenn jemand etwas daran ändert. Für geteilte Anleitungen im Team gilt dabei eine brauchbare Faustzahl: Erst wenn rund 80 Prozent der Ergebnisse ohne Nacharbeit verwendbar sind, lohnt es sich, sie breiter auszurollen.

Häng den Ablauf an eine einzige Zahl und schau nach vier Wochen, welcher Modellschritt sich zur Regel verhärtet hat

Die Zahl ist meistens die Durchlaufzeit von Anstoß bis Ergebnis, manchmal die Fehlerquote oder die Stückkosten. „Fühlt sich schneller an" zählt nicht, weil du damit weder etwas verteidigen noch etwas verbessern kannst. Und nach vier Wochen siehst du oft, dass ein Modellschritt fast immer dieselbe Entscheidung trifft. Dann ist er reif, eine Regel zu werden, und der Agent verschwindet Stück für Stück aus dem Ablauf.

Die Entscheidung, die vor dem Prototyp fällt

Die Frage war nie, ob ihr Agenten baut. Es gibt Fälle, in denen ein Agent das einzig passende Werkzeug ist, und wer ihn grundsätzlich meidet, verschenkt genau diese Fälle, in denen der Weg zum Ziel eben nicht vorher feststeht: die Recherche mit offenem Ausgang, die Aufbereitung eines unbekannten Dokumentenstapels, die Vorbereitung einer Entscheidung aus verstreuten Quellen.

Die Frage ist, an welchen Stellen deines Ablaufs Unbestimmtheit erlaubt ist. Das ist eine Architekturfrage, keine Werkzeugfrage, und sie fällt vor dem ersten Prototyp, nicht danach. Wer sie stellt, baut am Ende weniger Agenten, aber die, die er baut, überleben den Alltag. Wer sie nicht stellt, hat nach einem halben Jahr ein System, das in der Vorführung glänzt und in der Buchhaltung Kontrollarbeit erzeugt.

Wenn du wissen willst, wo dein Unternehmen dabei gerade steht, mach den KIRA-Check. Er verortet dich über sechs Stufen und fünf Achsen, und eine dieser Achsen heißt Systeme und Harness, also genau die Umgebung um das Modell herum, um die es hier ging. Du bekommst dein Profil und die zwei Engpässe, die dich aktuell bremsen. Zehn Minuten, keine Note am Ende.

KIRA-Check

Wo steht dein Unternehmen wirklich?

Verorte deinen Reifegrad über sechs Stufen und fünf Achsen, und finde die zwei Engpässe, die euch gerade bremsen.

Erstgespräch anfragen