Das Vorschlaghammer-Problem
Viele KI-Workflows fühlen sich heute an, als würde man eine Nuss mit einem Vorschlaghammer knacken.
Die Aufgabe ist eigentlich einfach: eine Tabelle lesen, neue Datensätze prüfen, einige Felder anreichern, eine Anfrage klassifizieren, einen Bericht erstellen, ein CRM aktualisieren, eine Benachrichtigung senden oder eine Antwort zur Prüfung vorbereiten.
Doch statt den Prozess zu entwerfen, übertragen Teams die gesamte Aufgabe an einen Agenten und bitten ihn, den Computer wie ein Mensch zu bedienen. Der Agent öffnet Anwendungen, klickt sich durch Bildschirme, liest Zeilen, entscheidet über den nächsten Schritt, wiederholt dieselben Anweisungen und verbraucht Tokens damit, einen bereits bekannten Workflow immer wieder neu zu entdecken.
Hinzu kommen Verfügbarkeitskosten. Die leistungsfähigsten KI-Tools werden häufig in begrenzten Sitzungen genutzt – mit praktischen Nutzungslimits, Ratenbegrenzungen oder Warteschlangen. Wenn ein Team diese Kapazität für repetitive Aufgaben verbraucht, die Software deterministisch ausführen könnte, verschwendet es nicht nur Tokens. Es beansprucht auch knappe, besonders wertvolle Modellzeit. Wenn dann eine wirklich anspruchsvolle Aufgabe auftaucht, muss das Team möglicherweise erneut auf verfügbare Kapazität warten.
Das kann sinnvoll sein, wenn die Umgebung unbekannt oder die Aufgabe tatsächlich explorativ ist. Für einen wiederholbaren Geschäftsprozess ist es jedoch nicht immer die beste Architektur.
Die meisten produktiven Workflows sind keine Agentenprobleme. Sie sind Automatisierungsprobleme mit gelegentlichen KI-Aufrufen.
Ein Workflow ist meist strukturierter, als er wirkt
Bei genauerer Betrachtung folgen viele KI-Workflows einem vorhersehbaren Muster.
Sie beginnen mit einem Trigger. Manchmal ist der Trigger zeitgesteuert: jeden Morgen, jeden Freitag, am Monatsende oder nachdem ein Berichtszeitraum abgeschlossen wurde. Manchmal ist er ereignisbasiert: Eine E-Mail geht ein, ein Kunde übermittelt ein Formular, ein Datensatz ändert sich in einer Datenbank, ein Ticket wird erstellt oder eine neue Datei wird in einem Ordner abgelegt.
Anschließend erhält der Workflow Eingabedaten. Sie können aus einer API, einem CRM, einem ERP-System, einer Tabelle, einem Dokument, einer Webanwendung, einer bestehenden Datenbank oder einer Kombination dieser Systeme stammen.
Danach iteriert der Workflow über die Eingaben. Er validiert Datensätze, filtert Fälle, vereinheitlicht Felder, wendet Regeln an, prüft Statuswerte, verzweigt anhand von Bedingungen und bereitet Ausgaben vor.
Nur einige dieser Schritte benötigen tatsächlich KI.
KI kann erforderlich sein, um unstrukturierten Text zu verstehen, eine Anfrage zu klassifizieren, Belege zusammenzufassen, eine Antwort zu formulieren, Dokumente zu vergleichen, den passenden Ausnahmeprozess zu bestimmen oder eine Empfehlung zu erstellen. Viele der umgebenden Schritte sind jedoch deterministisch. Sie sollten als Code umgesetzt werden – nicht durch wiederholtes Schlussfolgern.
Am Ende speichert oder übermittelt der Workflow das Ergebnis. Er aktualisiert eine Datenbank, schreibt Daten in ein CRM zurück, erstellt ein Dokument, versendet eine E-Mail, eröffnet eine Aufgabe, veröffentlicht eine Nachricht in Slack oder stellt ein Dashboard bereit.
Das ist keine Person, die sich durch einen Bildschirm klickt. Das ist ein Prozess.
Zur Laufzeit sollten Tokens für Intelligenz eingesetzt werden
Der kostspielige Fehler besteht darin, Modellaufrufe für die Orchestrierung zu verwenden, die Software direkt übernehmen kann.
Wenn jeder Durchlauf einen Agenten auffordert, dieselben Anweisungen zu lesen, durch dieselben Bildschirme zu navigieren, dieselben Spalten zu prüfen und über denselben offensichtlichen nächsten Schritt zu entscheiden, bezahlt das Unternehmen für wiederholte Koordination – nicht für Intelligenz.
Das bessere Muster ist einfach:
- deterministischen Code für Trigger, Schleifen, Validierung, Routing, Wiederholungen und Speicherung verwenden
- APIs und Konnektoren einsetzen, wenn Systeme bereits zuverlässige Schnittstellen bereitstellen
- KI nur für die Teile aufrufen, die von Sprachverständnis, Generierung, Schlussfolgerungen oder Beurteilung profitieren
- für jeden Schritt das passende Modell auswählen, statt jede Aufgabe an das leistungsstärkste Modell zu senden
- Traces, Kosten, Latenz, Eingaben, Ausgaben und Fehler sichtbar halten
Hier entstehen die Token-Einsparungen. Nicht nur durch günstigere Modelle, sondern auch dadurch, dass unnötige Modellaufrufe vollständig entfallen.
In Guanta-Deployments kann diese Architektur den Token-Verbrauch erheblich reduzieren, weil das Modell nicht mehr aufgefordert wird, den gesamten Prozess auszuführen. Das Unternehmen bezahlt für die benötigte Intelligenz, genau dann, wenn sie gebraucht wird, und mit dem Modell, das zur jeweiligen Aufgabe passt.
Mit der Zeit benötigen einige Teile möglicherweise überhaupt keine externen Modellaufrufe mehr. Kleinere Modelle, spezialisierte Klassifikatoren, lokale Inferenz, zwischengespeicherte Entscheidungen, Embeddings und herkömmlicher Code können größere Teile des Workflows übernehmen. Die Plattform sollte diese Entscheidungen ermöglichen, ohne dass der Prozess jedes Mal neu gestaltet werden muss.
KI gehört auch in die Entwicklungsphase
Das bedeutet nicht, insgesamt weniger KI einzusetzen.
Es bedeutet, KI an der richtigen Stelle einzusetzen.
KI kann beim Aufbau des Workflows äußerst nützlich sein. Sie kann dabei helfen, Anforderungen in Code zu übersetzen, Konnektoren zu generieren, Datentransformationen zu schreiben, Validierungslogik zu entwerfen, kleine interne Tools zu erstellen, Tests zu erzeugen, Legacy-APIs zu erklären und den Prozess zu beschleunigen, aus einem unübersichtlichen operativen Ablauf Software zu machen.
Sobald dieser Workflow jedoch feststeht, sollte das Unternehmen nicht weiterhin dafür bezahlen, dass ein Modell dieselbe Logik zur Laufzeit immer wieder neu generiert.
Setzen Sie KI intensiv in der Design- und Entwicklungsphase ein. Stellen Sie den Workflow anschließend auf einer Plattform bereit, die ihn zuverlässig ausführt. Rufen Sie zur Laufzeit nur dort KI auf, wo die aktuellen Daten tatsächlich Intelligenz erfordern.
Diese Unterscheidung ist entscheidend.
Agenten sind gut darin, herauszufinden, was zu tun ist, wenn ein Problem mehrdeutig ist. Plattformen sind gut darin, bekannte Aufgaben zuverlässig, wiederholt, sicher und nachvollziehbar auszuführen.
Die stärkste Architektur nutzt beides. KI hilft beim Erstellen des Workflows. Die Plattform führt den Workflow aus. KI wird innerhalb des Workflows nur an den Stellen aufgerufen, an denen sie einen echten Hebel bietet.
Warum eine Plattform wichtig ist
Wiederholbare KI-Arbeit braucht mehr als Prompts.
Sie benötigt Konnektoren zu Geschäftssystemen. Sie braucht zeit- und ereignisbasierte Ausführung. Sie braucht Statusverwaltung, Berechtigungen, Wiederholungen, Warteschlangen, Protokolle, Secrets, Schritte zur menschlichen Freigabe, Versionierung und Steuerung der Bereitstellung.
Außerdem braucht sie Observability.
Wenn ein Workflow ausgeführt wird, sollte das Team sehen können, was passiert ist:
- wodurch der Lauf ausgelöst wurde
- welche Eingabedatensätze verarbeitet wurden
- auf welche Systeme zugegriffen wurde
- welches Modell für jeden KI-Schritt verwendet wurde
- wie viele Tokens verbraucht wurden
- wie lange die einzelnen Schritte gedauert haben
- welche Datensätze fehlgeschlagen sind und warum
- welche Ausgaben geschrieben wurden
- welche Fälle eine menschliche Prüfung erfordern
Ohne diese Ebene wird der Betrieb von KI-Automatisierung schwierig. Ein Nutzer sieht möglicherweise eine Antwort, aber die Organisation kann Kosten, Qualität, Fehlerquellen oder den Zustand des Prozesses nicht nachvollziehen.
Darum wird in Wirklichkeit eine Plattform benötigt: ein Ort, an dem Anwendungen verbunden, Prozesse ausgeführt, KI gezielt aufgerufen, Ergebnisse an die richtigen Stellen übermittelt und sämtliche Abläufe jederzeit beobachtet werden können.
Welche Rolle Forward-Deployed Engineers spielen
KI kann beim Generieren des Workflow-Codes helfen. Dennoch muss jemand den tatsächlichen Prozess verstehen.
Das ist die Rolle des Forward-Deployed Engineers.
Ein FDE arbeitet eng mit dem Kunden zusammen und übersetzt die operative Realität in ein ausführbares Workflow-Design. Er identifiziert den Trigger, die Quellsysteme, die relevanten Felder, die Ausnahmen, die Freigabepunkte, die Sicherheitsanforderungen und das Geschäftsergebnis.
Er entscheidet, was als deterministischer Code umgesetzt werden sollte, wo KI tatsächlich 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 ihn produktionsreif.
Das ist wichtig, weil echte Workflows voller Kontext sind, der aus einem Ticket nicht offensichtlich wird. Manche ERP-Aktionen sind irreversibel. Einige Felder sind sensibel. Manche Ausnahmen sind politisch. Einige Fehler sind akzeptabel, andere bringen den Betrieb zum Erliegen. Manche Entscheidungen können automatisiert werden, während andere einen Menschen im Prozess erfordern.
Die Plattform verschafft FDEs zusätzlichen Hebel. Statt jede Bereitstellung in einem leeren Repository zu beginnen, können sie wiederverwendbare Konnektoren, Workflow-Bausteine, Observability, Sicherheitskontrollen und KI-gestützte Entwicklung nutzen. Der FDE übersetzt den Prozess. Die Plattform macht die Implementierung wiederholbar.
Diese Kombination vermeidet zwei Fallstricke: offene Agenten, die zur Laufzeit zu viel verbrauchen, und individuelle Beratungsprojekte, die nie zu wiederverwendbaren Produktfunktionen werden.
Das bessere Denkmodell
Das Ziel besteht nicht darin, jeden Agenten durch ein starres Skript zu ersetzen.
Das Ziel ist, Bekanntes von Unbekanntem zu trennen.
Bekannte Aufgaben sollten zu Software werden. Unbekannte oder sprachintensive Aufgaben können KI nutzen. Wiederholbare Arbeit sollte auf einer Plattform ausgeführt werden. Sensible Arbeit sollte über Kontrollen verfügen. Kostenintensive Arbeit sollte gemessen werden. Fehler sollten sichtbar sein. Verbesserungen sollten sich verstärken.
Für viele Unternehmen ist das die fehlende Ebene zwischen KI-Demos und produktivem Mehrwert.
Die Zukunft der KI-Automatisierung wird nicht aus einem einzigen riesigen Agenten bestehen, der den ganzen Tag durch jede Anwendung klickt. Sie wird aus Geschäftsprozessen bestehen, die als Workflows gestaltet, mithilfe von KI schneller erstellt, von einer Plattform betrieben, durchgängig überwacht und von Engineers unterstützt werden, die sowohl den Kunden als auch den Code verstehen.
So hören Unternehmen auf, eine Nuss mit einem Vorschlaghammer zu knacken.
Und so bezahlen sie für die KI, die sie tatsächlich benötigen.