Ein Workflow mit manuellen Zwischenschritten oder undokumentiertem Wissen kann einen Agenten vollständig stoppen. So beschreibt Waldek Mastykarz das Problem in seinem Beitrag über Agent Experience. Er beschreibt keinen Sonderfall, sondern den Alltag gewachsener Software. Waldek Mastykarz hat eine einfache Beobachtung gemacht: Wer eine Evaluation für einen Coding-Agenten baut, der eine Anwendung in die eigene Cloud deployen soll, merkt schnell, wo es klemmt. Ressourcen provisionieren, Code ausrollen, Funktion prüfen, danach aufräumen – jeder Schritt ist machbar, in der Kette wird daraus ein Hindernisparcours. Dort kippt die Perspektive: Was deinen Testaufbau ausbremst, bremst meist auch die Agenten deiner Nutzer.
Ein Gebäude, in dem die eigenen Leute jeden Lichtschalter blind finden, weil sie seit Jahren darin arbeiten, beschreibt das Problem gut. Für Besucher hängt keine Beschilderung, und der Weg zum richtigen Raum führt über Flure, die nur Eingeweihte kennen. KI-Agenten betreten dein Produkt wie solche Besucher: kein Gedächtnis für die Eigenheiten deiner Oberfläche, keine Routine, keine Kollegin, die kurz erklärt, wo die Berechtigung gesetzt wird. Sie müssen sich den Weg jedes Mal neu erschließen, und sie müssen ihn ohne dich gehen können. Sonst funktioniert er für sie nicht.
Warum Agenten dieselben Reibungen spüren wie dein Testaufbau
Viele Workflows in der Entwicklung sind um Menschen herum gebaut. Man navigiert durch Portale, kopiert Werte von einem Bildschirm in den nächsten, deutet Fehlermeldungen und wartet, bis eine Operation durchgelaufen ist. Mit der Zeit lernt man die Macken seiner Werkzeuge und entwickelt Workarounds, die irgendwann niemand mehr als Workaround erkennt. Dieses Wissen hält viele Prozesse zusammen – und einem Agenten fehlt es.
Ein Agent muss herausfinden, wie eine Aufgabe zu erledigen ist, die nötigen Funktionen erreichen, die Schritte koordinieren und am Ende prüfen, ob das Ergebnis stimmt. Ein Workflow, der einen manuellen Klick oder eine interne Absprache voraussetzt, stoppt ihn. Und selbst wenn jede Operation technisch erreichbar ist: Ein Dutzend Schritte bleibt ein Dutzend Gelegenheiten zu scheitern. Reibung ist in solchen Abläufen kein Schönheitsfehler, sondern der Grund, warum Agenten nicht zum Zug kommen.
Agenten sind längst keine Nische mehr. Im „State of AI Agents“-Report von Databricks für 2026 heißt es, KI-Agenten legen 80 Prozent der Datenbanken auf Neon an und erzeugen 97 Prozent der Datenbank-Branches. Solche Zahlen sagen wenig über die Qualität einzelner Modelle, aber viel über die Richtung: Agenten führen Infrastruktur-Workflows bereits in großem Umfang aus. Wenn Arbeit in dieser Größenordnung automatisiert läuft, werden Abläufe, die einen Menschen am Bildschirm voraussetzen, für einen wachsenden Teil der Nutzer zum Problem.
Agent Experience: Reibung kostet Zeit und Geld
Ein Mensch nimmt ein paar Minuten manuelle Konfiguration bei einem gelegentlichen Deployment in Kauf. Ein Agent läuft dieselbe Strecke viele Male, und jeder unnötige Schritt, jeder Wiederholungsversuch kostet Zeit und Inferenz. Dazu kommt das Nachdenken dazwischen: Jede Runde, in der der Agent erneut abwägt, welchen Aufruf er als nächstes macht, ist bezahlte Rechenzeit ohne Fortschritt. Reibung im Workflow schlägt bei Agenten direkt auf die Kosten der Aufgabe durch.
Eine Unterscheidung hilft hier. Ein Workflow kann für einen Agenten technisch ausführbar sein und trotzdem eine schlechte Agent Experience bieten – kurz AX, in Anlehnung an Developer Experience. AX beschreibt, wie gut ein Agent eine Technologie nutzen kann: ob er die richtigen Funktionen findet, ob er sich authentifizieren kann, ob er Fehler versteht und ob er erkennt, wann die Aufgabe erledigt ist. Ein Produkt, das diese Fragen nur mit Mühe beantwortet, funktioniert – aber schlecht und teuer.
API-Automatisierung reicht nicht
Der naheliegende Schritt ist, Funktionen über programmatische Schnittstellen zugänglich zu machen: APIs, CLIs oder MCP-Tools. MCP steht für Model Context Protocol, einen offenen Weg, über den Agenten Werkzeuge ansprechen können, ohne dass für jedes Produkt eine eigene Anbindung entsteht. Das hilft, denn ein Agent muss dann nicht mehr durch eine grafische Oberfläche klicken. Nur bleibt die Komplexität bestehen.
Ein Deployment legt ein Projekt an, konfiguriert eine Umgebung, provisioniert Infrastruktur, verteilt Berechtigungen, rollt Code aus und prüft das Ergebnis. Mit einer API für jede dieser Operationen wird der Ablauf automatisierbar – aber der Agent muss trotzdem jede Station entdecken und in der richtigen Reihenfolge koordinieren. Er braucht das Wissen, das vorher in den Köpfen der Entwickler steckte, und er braucht es in einer Form, die er in der Dokumentation findet. Ohne das bleibt die API-Automatisierung ein Satz Werkzeuge ohne Bauplan.
Ein Skill kann helfen: eine Anleitung, die den Ablauf beschreibt und bekannte Fallstricke abfängt. Als Zwischenlösung ist das vernünftig. Als Dauerzustand schafft es neue Abhängigkeiten: Nutzer müssen erfahren, dass es den Skill gibt, ihn installieren und aktuell halten. Die Benutzbarkeit deiner Technologie hängt dann davon ab, dass andere diesen zusätzlichen Schritt gehen. Ein Agent ohne Vorwissen, der sich allein über die öffentliche Dokumentation zurechtfindet, ist die strengere, aber aussagekräftigere Prüfung. Wenn dein Produkt für ihn funktioniert, funktioniert es auch für alle anderen, die einen Agenten um Hilfe bitten – auch für die, die von deinem Skill nie gehört haben.
Der bessere Ansatz liegt deshalb nicht im größeren Werkzeugkasten, sondern im einfacheren Weg. Eine Plattform könnte einen einzigen Vorgang anbieten, der vom Provisionieren bis zur Validierung alles erledigt, mit klaren Fortschrittsmeldungen und Fehlern, aus denen hervorgeht, was zu tun ist. Statt jedem Agenten beizubringen, wie er einen komplizierten Prozess koordiniert, wird der Prozess für alle einfacher. Wer über Agenten dutzende oder hunderte Male am Tag deployt, merkt Verbesserungen bei Zuverlässigkeit und Latenz schnell.
Cloud Deployment automatisieren: Engpässe finden
Wie findet man die Workflows, die Aufmerksamkeit brauchen? Ähnlich wie bei der Verbesserung von Developer Experience: die eigene Technologie benutzen, mit Nutzern sprechen, ihnen bei der Arbeit zusehen. Konkret: eine alltägliche Aufgabe wählen und einen Agenten damit beauftragen. Der Prompt sollte ein Ziel beschreiben, keine Schrittfolge. Wer das Deployment auf seine Plattform testen will, nennt die Plattform beim Namen und lässt den Agenten selbst herausfinden, wie er sie benutzt.
Dabei stört die eigene Expertise oft mehr, als sie hilft. Wer sein Produkt in- und auswendig kennt, schiebt dem Agenten fast automatisch die exakten Befehle, Konfigurationen und Links unter – und merkt nicht, dass er ihn um die Probleme herumlenkt, in die weniger erfahrene Nutzer laufen. Je mehr produktspezifisches Wissen im Prompt steckt, desto weniger sagt der Test aus. Entscheidend ist, ob der Agent ohne deine Hilfe zum Ziel kommt.
Beobachte den Agenten. Wo bleibt er hängen? Findet er die richtigen Schnittstellen? Kann er sich authentifizieren? Versteht er die Fehler, die er zurückbekommt? Wiederholt er Operationen, die schon erledigt sind? Kann er am Ende prüfen, ob die Aufgabe wirklich abgeschlossen ist? Schau nicht nur auf offensichtliche Fehlschläge: Ein Agent, der nach dreißig überflüssigen Tool-Aufrufen doch noch Erfolg hat, zeigt einen teuren und ineffizienten Workflow. Erfolg ist nicht dasselbe wie gute Agent Experience.
Suche erst die Ursache, bevor du eine Lösung wählst. Manchmal sind Dokumentation oder Fehlermeldungen unklar, manchmal fehlt eine API, manchmal muss der Workflow selbst neu gedacht werden – und manchmal liegt das Problem im Agenten oder in seinen Werkzeugen, nicht im Produkt. Diese Unterscheidung ist wichtig, weil ein neuer Skill oder ein MCP-Server nur eine von mehreren Antworten ist. Wer sofort das Werkzeug nachbessert, ohne die Reibung verstanden zu haben, baut einen Umweg um ein Problem, das bestehen bleibt.
Telemetrie zeigt nicht alle Probleme
Nutzungsdaten helfen bei der Priorisierung, haben aber eine Lücke. Ein Workflow, den Agenten selten verwenden, sieht unwichtig aus. Vielleicht wird er gerade deshalb selten verwendet, weil Agenten ihn nicht abschließen können. Niedrige Nutzung durch Agenten kann auf eine Hürde hindeuten, nicht auf geringe Nachfrage. Wer nur auf Zahlen schaut, optimiert die Bereiche, die ohnehin funktionieren.
Deshalb gehören Gespräche mit Entwicklern und eigene Tests repräsentativer Szenarien dazu. Besonders aufschlussreich sind Workflows, die Menschen gern an einen Agenten abgeben würden, aber weiterhin per Hand erledigen – dort fehlt die Nachfrage nicht, sie wird nur nicht erfüllt. Ziel ist, die eigene Technologie für Agenten benutzbar zu machen. Der Weg dorthin führt zuerst über die wichtigsten Workflows. Welche das sind, zeigt sich aus beobachteter Nutzung und aus dem, was Nutzer brauchen, aber nicht bekommen.
Agent Experience gehört in die laufende Produktentwicklung
AX ist keine Prüfung, die man einmal besteht. Produkte verändern sich, Modelle werden ausgetauscht, Agenten-Harnesses bringen neue Fähigkeiten und neues Verhalten mit. Ein Workflow, der heute rundläuft, kann morgen haken, weil der Agent inzwischen anders vorgeht. Repräsentative Agenten-Workflows gehören deshalb zur laufenden Entwicklung, nicht in ein Projekt mit Enddatum. Beobachten, auswerten, nachbessern – im selben Rhythmus wie das Produkt.
Nicht jeder Befund verlangt sofort eine Änderung. Manchmal ist es richtig, eine Einschränkung zu akzeptieren, weil ihre Behebung mehr kostet als der erwartete Nutzen. Das ist ein Produktkompromiss – solange er bewusst getroffen wird und nicht aus Zeitmangel entsteht. Außerdem liegt die Lösung manchmal bei einem anderen Team als dem, das das Problem gefunden hat. AX zu verbessern heißt, über die Grenzen einzelner Werkzeuge und Produktteile hinauszuschauen.
Je mehr Entwicklungsarbeit Agenten übernehmen, desto wichtiger wird, dass sie deine Workflows selbstständig durchlaufen können. APIs und Tools bereitzustellen ist ein Anfang. Entscheidend ist, Abläufe für einen Agenten auffindbar und verlässlich zu machen, ohne seine Zeit und die Tokens der Nutzer zu verbrennen. Wenn ein Workflow scheitert – bei einer Eval oder aus einem anderen Grund –, hilft kein aufwendigerer Testaufbau als erster Reflex. Vielleicht hast du die Stelle gefunden, an der deine Technologie besser werden muss. Nimm eine alltägliche Aufgabe, lass einen Agenten sie versuchen und schau zu, wo er hängt. Dann entscheide, ob das Problem beim Agenten liegt oder beim Workflow, den du ihm zugemutet hast.
Quelle: blog.mastykarz.nl
