Das Vorschlaghammer-Problem
Viele KI-Workflows heute wirken, als würde man mit einem Vorschlaghammer eine Nuss knacken.
Die Aufgabe ist meist simpel: eine Tabelle lesen, neue Datensätze prüfen, ein paar Felder anreichern, eine Anfrage klassifizieren, einen Bericht erstellen, ein CRM aktualisieren, eine Benachrichtigung senden oder eine Antwort zur Überprüfung vorbereiten.
Statt den Prozess zu entwerfen, geben Teams die gesamte Aufgabe einem Agenten und lassen ihn den Computer wie eine Person bedienen. Der Agent öffnet Anwendungen, klickt sich durch Bildschirme, liest Zeilen, entscheidet den nächsten Schritt, wiederholt dieselben Anweisungen und verschwendet Tokens, um einen Workflow neu zu entdecken, der schon bekannt war.
Es gibt außerdem einen Verfügbarkeitskostenpunkt. Die leistungsfähigsten KI-Werkzeuge werden oft in begrenzten Sessions benutzt, mit praktischen Nutzungslimits, Ratenbegrenzungen oder Warteschlangen. Wenn ein Team diese Kapazität für repetitive Arbeit aufbraucht, die Software deterministisch ausführen könnte, verschwendet es nicht nur Tokens. Es bindet knappe, wertvolle Modellzeit. Wenn dann eine wirklich schwierige Aufgabe auftaucht, wartet das Team womöglich wieder auf Kapazitäten.
Das kann sinnvoll sein, wenn die Umgebung unbekannt ist oder die Aufgabe wirklich explorativ. Für einen wiederholbaren Geschäftsprozess ist es jedoch nicht immer die beste Architektur.
Die meisten Produktions-Workflows sind keine Agentenprobleme. Es sind Automatisierungsprobleme mit gelegentlichen KI-Aufrufen.
Ein Workflow ist meist strukturierter, als er wirkt
Bei genauerem Hinsehen folgen viele KI-Workflows einer vorhersehbaren Form.
Sie beginnen mit einem Trigger. Manchmal ist der Trigger geplant: jeden Morgen, jeden Freitag, zum Monatsende oder nach Schließung eines Reporting-Fensters. Manchmal ist er ereignisbasiert: eine E-Mail kommt an, ein Kunde füllt ein Formular aus, ein Datensatz ändert sich in einer Datenbank, ein Ticket wird erstellt oder eine neue Datei landet in einem Ordner.
Dann erhält der Workflow Eingabedaten. Diese können von einer API, einem CRM, einem ERP, einer Tabelle, einem Dokument, einer Webanwendung, einer bestehenden Datenbank oder einer Kombination von Systemen stammen.
Anschließend wird über die Eingabe iteriert. Datensätze werden validiert, Fälle gefiltert, Felder normalisiert, Regeln angewendet, Status geprüft, auf Bedingungen verzweigt und Ausgaben vorbereitet.
Nur einige Schritte benötigen tatsächlich KI.
KI kann nötig sein, um Bedeutung aus unstrukturiertem Text zu extrahieren, eine Anfrage zu klassifizieren, Belege zusammenzufassen, eine Antwort zu entwerfen, Dokumente zu vergleichen, zu entscheiden, welcher Ausnahmepfad gilt, oder eine Empfehlung zu generieren. Viele umgebenden Schritte sind jedoch deterministisch. Sie sollten Code sein, nicht wiederholte Schlussfolgerungen.
Schließlich speichert oder liefert der Workflow das Ergebnis. Er aktualisiert eine Datenbank, schreibt zurück ins CRM, erstellt ein Dokument, sendet eine E-Mail, öffnet eine Aufgabe, postet in Slack oder stellt ein Dashboard bereit.
Das ist kein Mensch, der sich durch Bildschirme klickt. Das ist ein Prozess.
Laufzeit-Tokens sollten für Intelligenz eingesetzt werden
Der teure Fehler ist, Modellaufrufe für Orchestrierung zu verwenden, die Software direkt selbst erledigen kann.
Wenn bei jedem Lauf ein Agent gebeten wird, dieselben Anweisungen zu lesen, dieselben Bildschirme zu navigieren, dieselben Spalten zu prüfen und denselben offensichtlichen nächsten Schritt zu entscheiden, zahlt das Unternehmen für wiederholte Koordination, nicht für Intelligenz.
Das bessere Muster ist einfach:
- deterministischen Code für Trigger, Schleifen, Validierung, Routing, Retries und Speicherung verwenden
- APIs und Connectoren nutzen, wo Systeme bereits zuverlässige Schnittstellen bieten
- KI nur für die Teile aufrufen, die von Sprachverstehen, -generierung, -reasoning oder -urteil profitieren
- für jeden Schritt das passende Modell wählen, statt jede Aufgabe an das leistungsstärkste Modell zu senden
- Traces, Kosten, Latenz, Eingaben, Ausgaben und Fehler sichtbar halten
Hierher kommen die Token-Einsparungen. Nicht nur durch günstigere Modelle, sondern durch das komplette Entfernen unnötiger Modellaufrufe.
In Guanta-Deployments kann diese Architektur den Tokenverbrauch drastisch senken, weil das Modell nicht mehr gebeten wird, den gesamten Prozess auszuführen. Das Unternehmen zahlt für die Intelligenz, die es braucht, genau dann, wenn es sie braucht, mit dem Modell, das zur Aufgabe passt.
Mit der Zeit benötigen einige Teile möglicherweise überhaupt keine externen Modellaufrufe mehr. Kleinere Modelle, spezialisierte Klassifizierer, lokale Inferenz, gecachte Entscheidungen, Embeddings und konventioneller Code können einen größeren Teil des Workflows übernehmen. Die Plattform sollte diese Entscheidungen ermöglichen, ohne den Prozess jedes Mal neu entwerfen zu müssen.
KI gehört auch in die Build-Zeit
Das heißt nicht, insgesamt weniger KI zu verwenden.
Es bedeutet, KI am richtigen Ort einzusetzen.
KI kann beim Aufbau des Workflows extrem nützlich sein. Sie kann helfen, Anforderungen in Code zu übersetzen, Connectoren zu generieren, Datentransformationen zu schreiben, Validierungslogik zu entwerfen, kleine interne Tools zu erstellen, Tests zu produzieren, Legacy-APIs zu erklären und die Arbeit zu beschleunigen, einen unordentlichen operativen Prozess in Software zu überführen.
Sobald der Workflow jedoch bekannt ist, sollte das Unternehmen nicht weiter dafür bezahlen, dass ein Modell dieselbe Logik immer wieder zur Laufzeit erzeugt.
KI intensiv in der Design- und Build-Phase einsetzen. Dann den Workflow auf einer Plattform deployen, die ihn zuverlässig ausführt. Zur Laufzeit KI nur dort aufrufen, wo die Live-Daten wirklich Intelligenz erfordern.
Dieser Unterschied ist entscheidend.
Agenten sind gut darin herauszufinden, was zu tun ist, wenn das Problem unklar ist. Plattformen sind gut darin, bekannte Arbeit zuverlässig, wiederholt, sicher und beobachtbar auszuführen.
Die stärkste Architektur nutzt beides. KI hilft, den Workflow zu erstellen. Die Plattform führt den Workflow aus. KI wird innerhalb des Workflows nur an den Punkten aufgerufen, an denen sie echten Hebel schafft.
Warum eine Plattform wichtig ist
Wiederholbare KI-Arbeit braucht mehr als Prompts.
Sie braucht Connectoren zu Geschäftssystemen, geplante und ereignisbasierte Ausführung, Zustand, Berechtigungen, Retries, Queues, Logs, Geheimnisse, Schritte zur menschlichen Genehmigung, Versionierung und Deployment-Kontrollen.
Sie braucht außerdem Observability.
Wenn ein Workflow läuft, sollte das Team sehen können, was passiert ist:
- was den Lauf ausgelöst hat
- welche Eingabedatensätze verarbeitet wurden
- welche Systeme angesprochen wurden
- welches Modell für jeden KI-Schritt verwendet wurde
- wie viele Tokens verbraucht wurden
- wie lange jeder Schritt gedauert hat
- welche Datensätze fehlgeschlagen sind und warum
- welche Ausgaben geschrieben wurden
- welche Fälle menschliche Überprüfung benötigen
Ohne diese Ebene wird KI-Automatisierung schwer betreibbar. Ein Nutzer sieht vielleicht eine Antwort, aber die Organisation kann weder Kosten, Qualität, Fehlermodi noch den Gesundheitszustand des Prozesses verstehen.
Deshalb ist die eigentliche Notwendigkeit eine Plattform: ein Ort, um Anwendungen zu verbinden, Prozesse auszuführen, KI selektiv aufzurufen, Ergebnisse dorthin zu liefern, wo sie gebraucht werden, und das gesamte System jederzeit zu beobachten.
Wo vor Ort eingesetzte Ingenieur:innen (FDEs) hineinpassen
KI kann helfen, den Workflow-Code zu erzeugen, aber jemand muss die reale Vorgehensweise verstehen.
Das ist die Rolle der vor Ort eingesetzten Ingenieur:innen.
Eine/ein FDE sitzt nah beim Kunden und übersetzt die operative Realität in ausführbares Workflow-Design. Sie/Er identifiziert den Trigger, die Quellsysteme, die relevanten Felder, die Ausnahmen, Genehmigungspunkte, Sicherheitsauflagen und das Geschäftsergebnis.
FDEs entscheiden, was deterministischer Code sein sollte, wo KI wirklich nützlich ist, welches Modell ausreicht, was niemals an ein Modell gesendet werden darf und was für Audits und Verbesserungen protokolliert werden muss.
KI kann den ersten Entwurf schreiben. FDEs machen daraus Produktionsreife.
Das ist wichtig, weil echte Workflows voller Kontext sind, der aus einem Ticket nicht ersichtlich ist. Manche ERP-Aktionen sind irreversibel. Manche Felder sind sensibel. Manche Ausnahmen sind politisch. Manche Fehler sind akzeptabel, andere unterbrechen den Betrieb. Manche Entscheidungen lassen sich automatisieren, andere brauchen einen Menschen in der Schleife.
Die Plattform verleiht FDEs Hebelwirkung. Statt jede Implementierung in einem leeren Repository zu starten, können sie wiederverwendbare Connectoren, Workflow-Primitiven, Observability, Sicherheitskontrollen und KI-gestützte Entwicklung nutzen. Die FDE übersetzt den Prozess. Die Plattform macht die Implementierung wiederholbar.
Diese Kombination vermeidet zwei Fallen: offene Agenten, die zur Laufzeit zu viel verbrauchen, und kundenspezifische Beratungsprojekte, die nie zu wiederverwendbarer Produktfunktionalität werden.
Das bessere mentale Modell
Das Ziel ist nicht, jeden Agenten durch ein starres Skript zu ersetzen.
Das Ziel ist, Bekanntes von Unbekanntem zu trennen.
Bekannte Arbeit sollte zu Software werden. Unbekannte oder sprachintensive Arbeit kann KI nutzen. Wiederholte Arbeit sollte auf einer Plattform laufen. Sensible Arbeit sollte Kontrollen haben. Teure Arbeit sollte gemessen werden. Fehler sollten sichtbar sein. Verbesserungen sollten sich kumulieren.
Für viele Unternehmen ist das die fehlende Schicht zwischen KI-Demos und produktivem Mehrwert.
Die Zukunft der KI-Automatisierung wird nicht ein einziger riesiger Agent sein, der den ganzen Tag jede Anwendung durchklickt. Es werden Geschäftsprozesse sein, als Workflows entworfen, schneller mit KI generiert, von einer Plattform betrieben, durchgängig überwacht und von Ingenieur:innen unterstützt, die sowohl Kunde als auch Code verstehen.
So hören Unternehmen auf, mit einem Vorschlaghammer eine Nuss zu knacken.
Und so bezahlen sie nur für die KI, die sie tatsächlich brauchen.