KI-Agenten – also Software, die Aufgaben nicht nur beantwortet, sondern eigenständig mehrere Schritte abarbeitet – stehen derzeit auf vielen Projektlisten. Zwei aktuelle Meldungen setzen dieser Euphorie nüchterne Zahlen und Erfahrungen entgegen: Das Analysehaus Gartner warnt vor Kostenrisiken bei tokenbasierter Abrechnung, und ein Gründer berichtet öffentlich, warum er seinen ersten Agenten wieder abgeschaltet hat.

Die Token-Rechnung kommt später

Laut Gartner können KI-Agenten die Kostenerwartungen um mehr als 50 Prozent überschreiten, wenn pro Token abgerechnet wird. Ein Token ist eine Texteinheit – grob gesagt ein Wortbestandteil –, die ein Sprachmodell bei Eingabe und Ausgabe verarbeitet. Bezahlt wird also nicht pro Nutzer oder pro Monat, sondern pro verarbeiteter Menge.

Das ist der entscheidende Unterschied zu klassischen Lizenzmodellen: Bei einem Agenten lässt sich die verarbeitete Menge im Vorfeld schwer abschätzen. Ein Agent, der eine Aufgabe in mehreren Schritten löst, ruft das Modell wiederholt auf, übergibt Zwischenergebnisse, liest Kontext nach und korrigiert sich selbst. Jeder dieser Schritte erzeugt Tokens. Was im Prototyp mit wenigen Testfällen harmlos aussieht, skaliert im Produktivbetrieb mit der Zahl der Vorgänge – und mit der Länge der Kontexte, die der Agent mitschleppt.

Gartner prognostiziert gleichzeitig mehr autonome IT-Abläufe und hybride KI-Infrastrukturen, also Betriebsmodelle, die Cloud-Dienste und eigene Umgebungen kombinieren. Beides passt zusammen: Je mehr Routine an Agenten übergeben wird, desto relevanter wird die Frage, wo und zu welchen Konditionen die Rechenlast anfällt.

Der erste Agent wird oft wieder abgeschaltet

Die zweite Perspektive kommt aus der Praxis. Snipki-Gründer Jens Polomski hat seinen ersten KI-Agenten mit dem Namen Neo wieder abgeschaltet. Die Idee dahinter hat er nicht verworfen – wohl aber die konkrete Umsetzung. Als zentrales Problem benennt er Tool-Hopping: das ständige Wechseln zwischen neuen Werkzeugen, das Unternehmen Zeit und Fokus kostet, ohne dass ein belastbarer Nutzen entsteht.

Das Muster dürfte vielen bekannt vorkommen. Ein neues Werkzeug erscheint, ein Prototyp entsteht in wenigen Tagen, die Begeisterung ist groß – und drei Monate später steht die nächste Plattform zur Diskussion, während der erste Agent nie den Weg in einen stabilen Prozess gefunden hat. Abgeschaltet wird dann nicht, weil die Technik versagt hätte, sondern weil kein klar abgegrenzter Anwendungsfall dahinterstand.

Zwei Blickwinkel, ein gemeinsamer Befund

Die beiden Quellen betrachten unterschiedliche Ebenen: Gartner argumentiert aus der Perspektive von IT-Budgets und Infrastruktur, der Praxisbericht aus der Perspektive der täglichen Arbeit. Sie treffen sich jedoch an einem Punkt: Der Engpass liegt selten in der Modellqualität, sondern in der fehlenden Vorarbeit.

Wer vor dem Start nicht definiert, welche Aufgabe ein Agent übernimmt, wie oft er läuft und woran sich sein Nutzen messen lässt, bekommt beides – unkalkulierbare Kosten und eine Werkzeuglandschaft, die sich schneller dreht als die Prozesse dahinter. Die Gartner-Zahl von mehr als 50 Prozent Abweichung ist dabei eine Prognose und kein Erfahrungswert aus einem konkreten Projekt; sie beschreibt ein Risiko, keine Gesetzmäßigkeit.

Was sich daraus für die Projektplanung ableiten lässt

Aus den beiden Befunden ergeben sich einige nüchterne Konsequenzen für Unternehmen, die Agenten in Prozesse oder in die Softwareentwicklung einbauen wollen:

  • Use Case zuerst, Werkzeug danach. Ein Agent braucht eine klar umrissene Aufgabe mit definiertem Start- und Endpunkt. Erst daraus ergibt sich, welche Plattform überhaupt infrage kommt.
  • Kostenmodell vor dem Prototyp durchrechnen. Entscheidend ist nicht der Preis pro Million Tokens, sondern die erwartete Zahl der Durchläufe multipliziert mit dem durchschnittlichen Tokenverbrauch pro Durchlauf – inklusive der internen Zwischenschritte.
  • Obergrenzen technisch verankern. Limits pro Vorgang, pro Tag und pro Kostenstelle gehören in die Architektur und nicht in eine Betriebsvereinbarung, die niemand liest.
  • Verbrauch sichtbar machen. Ohne Monitoring, das Tokenverbrauch einzelnen Anwendungsfällen zuordnet, lässt sich eine Kostenabweichung erst auf der Monatsrechnung erkennen.
  • Werkzeugwechsel bewusst begrenzen. Ein Wechsel sollte eine Entscheidung mit Begründung sein, kein Reflex auf eine Produktankündigung.
  • Abschalten als normalen Projektschritt einplanen. Wenn ein Agent seinen Zweck nicht erfüllt, ist das Beenden die günstigere Variante gegenüber dem stillen Weiterlaufen.

Hybride Infrastruktur als Kostenhebel

Gartners Hinweis auf hybride KI-Infrastrukturen ist in diesem Zusammenhang mehr als eine Randnotiz. Wenn absehbar ist, dass bestimmte Aufgaben in hoher Frequenz und mit gleichbleibendem Muster anfallen, verändert sich die Rechnung: Eine Verarbeitung in der eigenen oder in einer dedizierten Umgebung kann gegenüber der reinen Abrechnung pro Token wirtschaftlich werden. Diese Entscheidung lässt sich allerdings nur treffen, wenn belastbare Verbrauchsdaten vorliegen – also nach einer Pilotphase mit Messung, nicht davor.

Gleichzeitig gilt: Nicht jede Aufgabe braucht einen Agenten. Viele wiederkehrende Abläufe lassen sich mit klassischer Automatisierung günstiger, schneller und vor allem nachvollziehbarer lösen. Ein Agent lohnt sich dort, wo Entscheidungen unter wechselnden Bedingungen getroffen werden müssen – nicht dort, wo ein deterministischer Ablauf genügt.

Einordnung für Web- und Softwareprojekte

Für Web- und Softwareprojekte heißt das: KI-Agenten sollten wie jede andere Komponente behandelt werden – mit definiertem Anwendungsfall, kalkuliertem Betriebskostenmodell und Messpunkten, die den Nutzen belegen. Ein Pilot mit engem Rahmen und harten Verbrauchsgrenzen bringt mehr Erkenntnis als eine breit angelegte Agentenlandschaft, deren Kosten erst im Nachhinein sichtbar werden. Und das Abschalten eines Agenten ist kein gescheitertes Projekt, sondern ein Ergebnis – sofern daraus die Anforderungen für den nächsten Versuch entstehen.

Quellen