Was ein Agent ist — und was nicht
Drei Dinge werden im Alltag „KI“ genannt und sind völlig verschieden. Der Unterschied entscheidet über Kosten, Nutzen und Risiko.
„Wir sollten da einen Agenten bauen“ ist derzeit ein Satz, der in fast jeder Besprechung fällt — und fast nie dasselbe meint. Bevor irgendetwas gebaut wird, muss ein einziger Unterschied sitzen. Klicken Sie sich durch die drei Arten.
Ein Skript, ein Makro, eine Schnittstelle. Es macht jedes Mal dasselbe, in derselben Reihenfolge, egal was hereinkommt.
Es entscheidet nichts. Das ist keine Schwäche, sondern der Grund, warum man ihm vertrauen kann: Was es gestern tat, tut es morgen auch. Ein Automat, der Rechnungsnummern vergibt, wird nie kreativ.
Sie stellen eine Frage, Sie bekommen einen Text. Was damit geschieht, entscheiden und tun Sie: kopieren, einfügen, verschicken, verwerfen.
Er wirkt nur über Sie. Er kann nichts speichern, nichts verschicken, nichts löschen. Deshalb ist er ungefährlich — und deshalb skaliert er nicht: Für dreißig Belege müssen Sie dreißig Mal etwas kopieren.
Sie geben nicht die Schritte, sondern das Ziel — und Sie geben ihm Werkzeuge, mit denen er handeln kann: Dateien lesen, in einer Datenbank nachsehen, etwas ablegen.
Dann läuft er in einer Schleife: überlegen, ein Werkzeug benutzen, das Ergebnis lesen, wieder überlegen. Wie oft das geschieht und welches Werkzeug wann an der Reihe ist, steht in keinem Quelltext.
Der eine Satz, an dem sich alles entscheidet
Wer legt die Reihenfolge der Schritte fest — Sie beim Schreiben oder er beim Laufen? Beantwortet man diese Frage mit „ich“, ist es ein Programm. Beantwortet man sie mit „er“, ist es ein Agent, und dann gelten andere Regeln: Man gibt ihm keine Anweisungen, sondern Grenzen.
| Automat | Assistent | Agent | |
|---|---|---|---|
| Reihenfolge der Schritte | steht fest | entfällt | er entscheidet |
| Wirkt selbst in der Welt | ja | nein | ja |
| Kosten je Vorgang | nahe null | gering | spürbar |
| Gleiche Eingabe, gleiches Ergebnis | immer | meistens | nicht garantiert |
| Was Sie ihm geben | Schritte | eine Frage | Ziel, Werkzeuge, Grenzen |
Alle drei nebeneinander
WarumWarum die Schleife technisch banal ist — und trotzdem alles ändert
Was in Vorträgen nach einem neuartigen System klingt, ist im Quelltext eine for-Schleife mit einem Aufruf darin. Es gibt keinen Agenten-Server, keine Agenten-Laufzeit, kein Agenten-Betriebssystem. Es gibt ein Programm, das immer wieder dieselbe Frage stellt: „Und jetzt?“
Neu ist nicht die Technik, sondern wer die Reihenfolge bestimmt. In jedem Programm, das Sie kennen, steht die Reihenfolge im Code — sie ist nachlesbar, prüfbar, unveränderlich zwischen zwei Deployments. Hier entsteht sie zur Laufzeit, aus dem Text, den das Modell gerade sieht.
Daraus folgt der ganze Rest dieses Kurses: Man kann einen Agenten nicht durch Anweisungen sicher machen, sondern nur durch Grenzen — durch Werkzeuge, die es nicht gibt, durch Prüfungen im Code, durch Deckel, die zählen, und durch ein Protokoll, das hinterher zeigt, was geschehen ist.
TiefeWo eine Schleife üblicherweise stecken bleibt
Drei Muster erklären fast jeden Lauf, der nicht endet:
Er hält sich nicht für fertig. Im Auftrag fehlt ein prüfbares Schlusskriterium. „Bearbeite die Belege sorgfältig“ hat kein Ende; „fertig, wenn jede Datei aus beleg_liste abgelegt oder vorgelegt ist“ hat eines.
Ein Werkzeug antwortet mehrdeutig. Gibt beleg_ablegen nur „ok“ zurück, weiß der Agent nicht sicher, ob dieser Beleg damit erledigt ist. Gibt es „abgelegt, id 4711 — nimm den nächsten Beleg“ zurück, weiß er es.
Er wiederholt einen Fehlversuch. Ein Werkzeug meldet „vorübergehender Fehler“, er versucht es erneut, dasselbe Ergebnis, erneut. Von außen sieht das aus wie Arbeit. Das Gegenmittel steht in Station 03: Das Werkzeug zählt selbst mit und ändert nach dem dritten Mal seine Antwort.
Alle drei Muster haben eines gemeinsam: Sie sind im Protokoll auf einen Blick zu sehen — drei identische Zeilen hintereinander. Ohne Protokoll sind sie unsichtbar und man streitet über das Modell.