Pay to Play

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: Was ich aus drei Tagen Agentic-AI-Workshop und einigen Monaten Copilot mitgenommen habe: Der Agent macht nur, was man ihm sagt, und genau da fängt die Arbeit an.

🎚️ Soundcheck

Es ist eine Weile her seit der letzten Ausgabe. Ich war in der Zwischenzeit viel auf der Microsoft-Plattform unterwegs und habe zuletzt einen dreitägigen Workshop zu Agentic AI gegeben. Der Workshop war so aufgebaut, dass optimalerweise die sogenannten Citizen Developer, also ganz normale POs oder Projektmanager, die Agenten selbst umsetzen können. So wird es ja gerade überall erzählt.

Es hat nicht geklappt, zumindest nicht so, wie es sich die Teilnehmer teils vorgestellt haben. Und das lag auch gar nicht an den Teilnehmern selbst. Ich meine, dass ein Agent in der Demo das eine ist und ein Agent im Betrieb etwas völlig anderes, und dass die Tutorials genau an der Stelle aufhören, wo es anfängt, schwierig zu werden. „Demo ist schnell gebaut“ sagt jeder, aber was danach konkret schiefgeht, hat kaum jemand vor Augen. Deshalb will ich es heute an einem Beispiel aus dem Workshop zeigen und danach ermitteln, was dieselbe Denkweise im laufenden Betrieb kostet.

🎤 Main Set: Transkript rein, Jira-Tickets raus, Excel kaputt

Die Aufgabe

Eine der Übungen im Workshop war auf einen kleinen Use Case ausgelegt: Ein Agent bekommt das Transkript eines Meetings und soll daraus Jira-Tickets machen. Ein Sprachmodell kann so etwas gut, und der erste Teil war auch wirklich schnell fertig. Transkript rein, Ticket-Vorschläge raus.

Dann kam die Frage, wo die Tickets jetzt hin sollen. Jira-Zugriff hatten wir in der Schulungsumgebung keinen, der Use Case sollte aber trotzdem irgendwie funktionieren. Also haben die Teilnehmer gesagt: Gut, dann nehmen wir halt eine Excel-Liste, mit Excel können wir umgehen, da wissen wir, wie es funktioniert. Der Agent bekam ein Tool, um in die Excel zu schreiben, und den Auftrag, die Tickets dort anzulegen.

Was passiert ist

Der Agent hat genau das getan. Und zwar so, wie ein Agent es halt immer macht: parallel. Fünf Tickets, fünf gleichzeitige Tool-Aufrufe auf dieselbe Excel-Datei. Das Ergebnis: Ein Ticket wurde vom nächsten überschrieben, weil Excel im Hintergrund noch dabei war, den vorherigen Schreibvorgang zu synchronisieren, während der nächste schon reinkam. Am Ende fehlten Tickets, und keiner wusste erstmal, warum.

Für die Teilnehmer war es komplett unverständlich. Der Agent hatte doch gemacht, was man ihm gesagt hatte. Ja, hatte er. Also der nächste Versuch: Dem Agenten wurde ausdrücklich gesagt, die Aufrufe bitte nacheinander zu machen. Und rate mal: Es funktioniert natürlich trotzdem nicht immer. Mal hält sich der Agent daran, mal nicht. Eine Anweisung im Prompt ist eben eine Bitte, keine Garantie. Dazu kommt, dass sich vorher niemand gefragt hatte, ob eine Excel-Datei überhaupt dafür gedacht ist, von mehreren Prozessen gleichzeitig beschrieben zu werden. Ist sie nämlich nicht. Excel ist kein transaktionaler Speicher, da gibt es keine Sperren und keine Garantie, dass aus fünf gleichzeitigen Schreibzugriffen fünf Zeilen werden.

Was man hätte machen müssen

Architektonisch gesehen war der Aufbau grundfalsch, und die richtige Lösung ist technisch gar nicht so wild, sie setzt aber zwei Dinge voraus, die man kennen muss. Erstens gehört der Schreibvorgang nicht in den Agenten, sondern in einen Agent Flow, in dem eine Schleife die Tickets nach und nach anlegt. Da ist die Reihenfolge dann nicht mehr Verhandlungssache mit dem Modell, sondern fest verdrahtet. Der Agent entscheidet, was angelegt wird, der Flow kümmert sich kontrolliert um das Wie. Zweitens war Excel die falsche Technologie. Wenn mehrere Schreibzugriffe gleichzeitig auf denselben Datenbestand treffen können, gehört eine richtige Datenbanktabelle her, in der Microsoft-Welt zum Beispiel Dataverse, die solche Zugriffe sauber verarbeitet, statt sie sich gegenseitig überschreiben zu lassen.

Für jemanden mit Entwicklungshintergrund ist es offensichtlich. Für die Teilnehmer war es ein Konzept, das sie erstmal verstehen mussten, bevor sie überhaupt verstehen konnten, warum ihr Agent nicht funktioniert hat. Und klar, wenn man die KI fragt, sagt die auch: Ja, kann man so machen, aber dann müsstest du es vielleicht noch so und so lösen. Nur hilft diese Antwort eben nur dem, der die Begriffe dahinter einordnen kann. Für alle anderen baut sich ein Rattenschwanz auf: Schleife, Sequenzierung, Transaktion, jedes für sich lernbar, aber zusammen ist es genau die technische Expertise, die der Citizen Developer laut verbreiteter Meinung gar nicht mehr braucht.

Jetzt kann man natürlich sagen: In echt gibt es doch den Jira-Cloud-Connector, damit ist das Thema vom Tisch. Stimmt sogar. Mit dem Connector braucht man für diesen Fall gefühlt gar keinen Agenten mehr, man sagt dem Chat, was man will, und das Ticket ist da. Mir geht es aber um den Kern dahinter. Im Unternehmen hat man es nicht nur mit Jira zu tun, sondern auch mit Legacy-Systemen, die nicht mal eben einen MCP-Server haben, oder mit irgendeiner Fachanwendung ohne Schnittstelle. Und genau gegen solche Wände läuft man dann. Man denkt, ich sag dem Agenten einfach, er soll da x Zeilen anlegen, und nehme als Speicher, womit ich mich auskenne. Hinterher hat man etwas gebaut, was man komplett nochmal machen kann, weil die Wahl von Anfang an falsch war.

🥁 Track 2: Was es im Betrieb kostet

Entwicklung oder Betrieb

Das Workshop-Beispiel ist der kleine Fall. Der große Fall, der mir im Copilot gerade immer wieder begegnet, folgt demselben Muster, nur hängt eine Rechnung dran: Der Copilot verbraucht mehr Credits, als er eigentlich müsste, wenn man ihm das passende System zur Verfügung stellen würde.

Beispiel Vertrieb. Anstatt dass der Copilot für Sales mühselig im Internet Firmeninfos recherchiert, Seite für Seite, kann man auch Systeme bauen, die der Copilot dynamisch verwenden kann und die dieselben Informationen zu einem Bruchteil des Credit-Preises beschaffen. Was die Web-Recherche so teuer macht, steht in Microsofts eigener Rate Card: Mit einem Reasoning-Modell wird jeder Modellaufruf nach Token abgerechnet, 10 Credits pro 1.000 Token, zusätzlich zur Grundgebühr der Aktion. Microsoft rechnet es selbst vor: Eine einzige Folgefrage mit zwei Modellaufrufen kostet 141 Credits, dieselbe Frage als neues Gespräch ohne warmen Cache 461 Credits. Bei rund einem Cent pro Credit im Pay-as-you-go sind das 1,40 bis 4,60 Dollar, für eine Frage.

Ein gebautes Tool dagegen, ob Agent Flow, Connector oder MCP-Server, ist in der Rate Card eine Agent Action zu 5 Credits, Agent-Flow-Aktionen kosten 13 Credits pro hundert Stück. Die eigentliche Recherche läuft deterministisch im Hintergrund, ohne dass ein Modell dafür Token verbrennt. Der Copilot kriegt ein fertiges, strukturiertes Ergebnis und muss es nur noch in Sprache fassen.

Damit stellt sich die Frage: Kosten für die Entwicklung oder „einfach“ für den Betrieb? Entwicklung heißt, Automatisierungen einmal bauen und im Betrieb Geld sparen. Betrieb heißt, die KI verbraucht bei jeder Anfrage erneut viele Credits, um das Problem zu lösen. Klar, wenn ich die KI einmal pro Woche loslaufen lasse, ist es nicht kriegsentscheidend, dann lohnt sich die Entwicklung schlicht nicht. Würde eine KI das aber täglich machen, und vielleicht auch noch für verschiedene Personen im Unternehmen, dann wird der Betrieb schnell teuer.

Ein Blick ins Kleingedruckte gehört dazu: Für Mitarbeiter mit M365-Copilot-Lizenz weist Microsoft die interne Nutzung als „No charge“ aus, im Rahmen von Fair-Use-Grenzen und nur, solange der Agent in der Identität des Nutzers läuft. Sobald der Agent autonom startet, per Zeitplan oder Event, oder externe Nutzer bedient, zahlt der Tenant jeden Credit. Und bei 125 Prozent des Prepaid-Kontingents werden die Agenten blockiert, mitten im Gespräch. Wer skalieren will, landet fast immer bei autonomen Agenten, also genau da, wo jeder Token zählt.

Vor allem aber: uneinheitlich

Teuer ist aber nur die eine Hälfte. Wenn fünfzig Leute denselben Copilot dieselbe Recherche frei machen lassen, kriegt jeder Nutzer ein Ergebnis mit anderem Schwerpunkt, anderen Quellen, anderem Format, je nachdem, wie er gefragt hat und was das Modell gerade gefunden hat. Für den Einzelnen ist es jeweils brauchbar. Fürs Unternehmen ist es nicht vergleichbar und nicht weiterverwendbar. Ein gebautes System liefert immer dieselben Felder in derselben Struktur aus denselben Quellen. Skalieren heißt ja nicht nur mehr Nutzer, sondern auch, dass die Ergebnisse zusammenpassen.

Und die Datenplattform darunter

Dazu kommt, dass die zugrundeliegende interne Datenplattform natürlich auch stimmen muss. Ein Tool ist nur so gut wie die Daten, auf die es zugreift. Ist das CRM veraltet und liegen die Firmendaten in drei Systemen widersprüchlich herum, dann sind alle Informationen immer nur ein verschwindender Snapshot der aktuellen Situation, der aus dem Kontextfenster genauso schnell wieder verschwindet, wie er reingekommen ist. Daraus wird kein Wissen, das sich aufbaut. Die Wissensschicht aus Ausgabe #003, das Gedächtnis aus Ausgabe #009 und die Ingestion aus Ausgabe #013 sind genau die Bausteine, mit denen aus Snapshots eine Plattform wird.

🎯 Encore: Der eine Gedanke für Entscheider

Der Agent macht nur, was man ihm sagt, und selbst daran hält er sich nicht immer. Es muss also jemand wissen, was man ihm sagen muss, welches System er dafür braucht und was passiert, wenn fünf Aufrufe gleichzeitig auf eine Excel-Datei treffen. Diese Expertise verschwindet nicht, nur weil das Werkzeug Low-Code ist. Und für alles, was regelmäßig, für viele Leute und nach bekanntem Muster läuft, gilt: immer mit System arbeiten und initial lieber ein bisschen investieren, statt den Copilot jedes Mal neu denken zu lassen.

Die Prüffrage für Entscheider: Welche unserer Copilot-Anfragen laufen täglich und für viele Nutzer nach demselben Muster, und wer bei uns hat die Expertise, genau diese einmal als System zu bauen?

💿 B-Side

Anti-Pattern: Dem Copilot ein Reasoning-Modell und Web-Zugriff geben, der Fachabteilung sagen, sie soll sich einfach Agenten bauen, und als Speicher nehmen, was man kennt. Was dabei rauskommt, sind Agenten, die dieselben Probleme auf unterschiedliche Weise und zu vollen Token-Kosten lösen, auf Speicher schreiben, der dafür nicht gebaut ist, und Ergebnisse liefern, die niemand zusammenführen kann. Microsoft hat mit Agent 365 inzwischen eine Kontrollebene mit Agent-Registry angekündigt, damit werden solche Agenten zumindest sichtbar. Billiger oder einheitlicher werden sie dadurch aber nicht.

Mein Rat: Vor dem nächsten Copilot-Projekt den Agent Usage Estimator von Microsoft mit den echten Zahlen füttern, täglich, pro Nutzer, mit Reasoning-Modell, und daneben den Aufwand legen, dieselbe Aufgabe einmal als Tool zu bauen. Und die Frage, wohin der Agent eigentlich schreibt, vorher von jemandem beantworten lassen, der weiß, was ein gleichzeitiger Schreibzugriff ist.

---

Das war Rag'n'Roll #015.

Weiterleiten erwünscht🤘