Ein Agent ist Software, die ihren nächsten Schritt selbst entscheidet. Das macht sie nützlich, und gefährlich, wenn niemand die Grenzen gezogen hat.
Was ein Agent eigentlich ist
Klassische Automatisierung folgt einem Skript: Steht in diesem Feld X, dann tu Y. Sie bricht in dem Moment, in dem die Realität das Skript verlässt. Ein Agent bekommt stattdessen ein Ziel. Er liest das Ticket, entscheidet, dass er den Kundendatensatz braucht, ruft das CRM auf, prüft die Erstattungsrichtlinie, entwirft eine Antwort und schlägt eine Aktion vor. Jeder Schritt ist eine Entscheidung des Modells, getroffen mit den Tools, die ihr ihm gebt.
Das ist der ganze Trick, und das ganze Risiko. Modelle sind gut in Ermessensentscheidungen bei unordentlichem Input. Sie sind nicht gut darin zu wissen, wann sie aufhören sollten. Die Engineering-Arbeit besteht also nicht darin, den Agenten schlauer zu machen. Sie besteht darin festzulegen, welche Tools er anfassen darf, welche Aktionen einen Menschen brauchen, was er ausgeben darf und was passiert, wenn er unsicher ist.
Wo sich Agenten lohnen
Die besten Kandidaten sind Workflows mit Volumen, Vielfalt und einer klaren Definition von „fertig“: Support-Triage, Schadenaufnahme, Aufräumen im Sales Ops, Erstreaktion auf Incidents, dokumentenlastige Backoffices. Arbeit, bei der eine Fachkraft den Großteil des Tages damit verbringt, Kontext aus fünf Systemen zusammenzutragen, bevor sie eine Entscheidung trifft, die dreißig Sekunden dauert.
Der Nutzen ist selten eine Geschichte über Stellenabbau. Es geht um Zeit. Der Agent sammelt, der Mensch entscheidet. Gut gemacht erledigt der Agent den Routineanteil von Anfang bis Ende und bereitet den Rest so gründlich vor, dass auch die menschliche Entscheidung schneller wird.
Die Engineering-Arbeit besteht nicht darin, den Agenten schlauer zu machen. Sondern darin, die Grenzen zu ziehen, die er nicht überschreiten darf.
Wo Agenten aus dem Ruder laufen
Agenten scheitern auf vorhersehbare Weise. Sie bekommen zu viele Berechtigungen, weil das Einrichten so schneller ging. Sie lesen ein Dokument, das Anweisungen enthält, und befolgen sie; das ist indirekte Prompt Injection. Sie drehen Schleifen, versuchen es erneut und geben Geld aus. Sie führen eine Aktion aus, die technisch erlaubt und praktisch verheerend ist, etwa dem falschen Kunden etwas zu erstatten, weil niemand ein Limit definiert hat.
Nichts davon ist exotisch. Genau das passiert, wenn ein Agent wie eine Demo gebaut und wie ein Produkt betrieben wird.
Wie wir sie in der Spur halten
Wir starten beim Workflow, nicht beim Modell. Zuerst kartieren wir, was ein Mensch heute tut, und markieren jede Aktion mit Folgen in der echten Welt. Diese Aktionen bekommen eine Berechtigung, ein Limit oder ein menschliches Freigabe-Gate. Der Agent bekommt eine Allow-List von Tools und sonst nichts, ein Ausgabelimit, Rate Limits und einen Kill Switch, den jemand wirklich getestet hat.
Dann testen wir ihn so, wie wir ihn angreifen würden: Edge Cases, seltsame Inputs, vergiftete Dokumente. Jeder Lauf hinterlässt einen Trace, den ihr hinterher lesen könnt: was er gesehen hat, was er entschieden hat, welches Tool er aufgerufen hat, wer freigegeben hat. Der Rollout erfolgt schrittweise, eine Queue oder ein Team nach dem anderen, mit einem Owner auf eurer Seite, der Stopp sagen kann.