KI-Agent oder fester Workflow? Wann sich der Aufwand für einen echten Agenten lohnt

Was „KI-Agent" in diesem Kontext wirklich heißt

Der Begriff Agent wird gerade so inflationär verwendet, dass er fast bedeutungslos geworden ist. Für diesen Artikel verstehen wir unter einem KI-Agenten ein System, das selbst entscheidet, welche Schritte es in welcher Reihenfolge ausführt, um ein Ziel zu erreichen. Das Gegenmodell ist ein fester Workflow, bei dem die Schritte und ihre Abfolge vorgegeben sind, auch wenn an einzelnen Stellen ein Sprachmodell mitwirkt.

Diese Unterscheidung ist wichtig, weil sie fundamentale Konsequenzen für Planung, Tests, Betrieb und Kosten hat. Eine Anwendung, die ein Modell punktuell nutzt, bleibt in vielen Punkten wie klassische Software planbar. Eine Anwendung, die ein Modell Entscheidungen treffen lässt, verhält sich in der Produktion deutlich anders.

Warum der Reflex zum Agenten oft voreilig ist

In Diskussionen fällt der Agentenbegriff häufig, sobald Aufgaben mehrstufig wirken. Die Argumentation läuft dann oft: „Das ist zu komplex für einen festen Ablauf, das sollte ein Agent selbst lösen." In vielen Fällen ist das Gegenteil richtig. Was sich komplex anfühlt, lässt sich oft in eine Sequenz klarer Schritte zerlegen, die einzeln prüfbar und wartbar sind.

Ein Agent wirkt elegant, weil er Varianz absorbieren kann. In Produktion zeigt sich aber, dass gerade diese Varianz das Testen, das Debugging und die Kosten in die Höhe treibt. Wer den Agenten als Default wählt, statt als bewusste Antwort auf eine konkrete Anforderung, bezahlt dafür mit längeren Projektzeiten und schwer einschätzbarer Qualität.

Feste Workflows: wo sie stark sind

Feste Workflows mit punktueller KI sind stark, sobald die Aufgabe in eine klare Sequenz zerlegbar ist und die Schritte stabil bleiben. Beispiel: „E-Mail empfangen, Anhang klassifizieren, relevante Felder extrahieren, Daten ins Zielsystem schreiben, Bearbeitungsstand melden." Jeder Schritt hat einen definierten Input und Output, jede Stelle ist einzeln testbar, und das Modell wird nur dort eingesetzt, wo Sprachverständnis echten Mehrwert liefert.

Solche Setups sind günstig im Betrieb, gut debugbar und lassen sich mit klassischem Monitoring abdecken. Sie skalieren robust, weil bei hoher Last nicht ein Modell eine unklare Folge von Entscheidungen trifft, sondern ein festes Programm saubere Einzelaufrufe steuert. Viele Use Cases, die heute als Agent verkauft werden, sind in Wahrheit genau diese Art von Workflow mit Modell-Assistenz, und sie sind dort perfekt aufgehoben.

KI-Agenten: wo sie wirklich überlegen sind

Ein echter Agent lohnt sich dort, wo sich der nächste sinnvolle Schritt nicht vorab beschreiben lässt und das System aus mehreren möglichen Handlungen wählen muss. Typische Kandidaten sind offene Recherche-Aufgaben, interaktive Supportdialoge mit Systemzugriff, Analysefälle, bei denen das Ergebnis über den nächsten Schritt entscheidet, oder Assistenten, die auf Zuruf in sehr unterschiedlichen Tools arbeiten.

Solche Aufgaben sind nicht gleichbedeutend mit „komplex". Sie zeichnen sich dadurch aus, dass die Pfade nicht vorhersehbar sind und die Kosten eines ungenutzten Pfades hoch wären. Wo ein fester Workflow jeden denkbaren Zweig explizit bauen müsste, gewinnt ein Agent, weil er zur Laufzeit entscheidet. Dafür zahlt man mit anspruchsvollerem Testen und höherem Aufwand in Qualitätssicherung und Monitoring.

Entscheidungskriterien

Fünf Fragen helfen, die Entscheidung nüchtern zu treffen. Erstens: Lässt sich der nächste Schritt auf Basis bekannter Eingabeparameter eindeutig festlegen? Wenn ja, spricht viel für einen festen Workflow. Zweitens: Wie groß ist die Menge realistischer Pfade? Wenige Pfade lassen sich explizit modellieren, viele nicht mehr sinnvoll.

Drittens: Wie teuer ist ein Fehlschritt? Je höher das Schadenspotenzial, desto mehr spricht für explizite Kontrolle und gegen freie Entscheidung eines Modells. Viertens: Wie gut sind die verfügbaren Tools und Schnittstellen beschrieben? Ein Agent ist nur so gut wie die Werkzeuge, die er sauber aufrufen kann. Fünftens: Wie wichtig sind Latenz und Kosten? Agenten führen oft mehrere Modellaufrufe pro Anfrage aus, was Antwortzeiten und laufende Kosten spürbar prägt.

In der Praxis liegt die Antwort selten bei „ja, Agent" oder „nein, Workflow", sondern irgendwo dazwischen. Genau deshalb lohnt es sich, diese fünf Fragen pro Anwendungsfall konkret zu beantworten, statt global zu entscheiden.

Mischformen: der sinnvolle Mittelweg

Viele stabile Produktionen arbeiten mit einem expliziten Rahmen und einem eingebetteten Agenten für klar begrenzte Teilschritte. Ein Workflow steuert die Hauptstrecke, garantiert Reihenfolge, Berechtigungen und Fehlerbehandlung, und an genau einer Stelle darf ein Agent frei entscheiden, zum Beispiel welches Bestandssystem für eine konkrete Rückfrage angesprochen wird.

Diese Mischform ist oft die beste Antwort, weil sie die Kontrollvorteile fester Abläufe mit der Flexibilität von Agenten verbindet, ohne die Betriebskosten eines vollen Agenten-Systems. Sie erfordert aber eine bewusste Architekturentscheidung. Wer das vermischt, baut weder einen klaren Workflow noch einen sauberen Agenten, sondern etwas, das beides nicht richtig kann. Wir arbeiten an dieser Art von Architekturen bei KI-Agenten & Automatisierung.

Testen und Betrieb: der unterschätzte Kostenblock

Ein fester Workflow lässt sich weitgehend mit klassischen Testverfahren absichern: Unit-Tests, Integrationstests, Smoke-Tests in definierten Szenarien. Bei einem Agenten reicht das nicht. Das Verhalten hängt von Prompt, Modell, verfügbaren Tools und Kontext ab. Eine kleine Änderung an einem dieser Parameter kann das Verhalten in einer anderen Situation verschieben.

Deshalb braucht jeder produktiv genutzte Agent eine strukturierte Testgrundlage mit realistischen Szenarien, klaren Erwartungen und regelmäßiger Regression. Diese Arbeit wird in Projekten systematisch unterschätzt. Sie gehört zu einer erwachsenen LLM-Qualitätssicherung und ist einer der Hauptgründe, warum die Gesamtkosten eines Agenten deutlich über denen eines vergleichbaren Workflows liegen können.

Typische Fehler in der Entscheidung

Der erste Fehler ist, den Agenten als Default zu wählen, weil er moderner klingt. Moderne Architektur zeichnet sich nicht durch maximalen Entscheidungsspielraum der KI aus, sondern durch bewusste Verteilung der Verantwortung zwischen Programm und Modell.

Der zweite Fehler ist, Agenten ohne klare Werkzeug-Spezifikation zu bauen. Ein Agent, dessen Tools unklar beschrieben sind, erzeugt instabile Ergebnisse, egal wie stark das Modell ist. Ein Agent ohne ein gutes Tool-Set ist wie ein Mitarbeiter ohne Zugriff auf die eigenen Systeme.

Der dritte Fehler ist, den Workflow-Anteil zu vernachlässigen. Selbst in agentenbasierten Systemen bleibt es sinnvoll, klar begrenzte Abschnitte deterministisch zu halten: Eingangsprüfung, Authentifizierung, Berechtigungen, Eskalationspfade. Wer diese in den Agenten verlagert, verlagert Risiko, statt es zu lösen.

Der vierte Fehler ist, die Entscheidung nur auf der Greenfield-Seite zu treffen. Viele Agentenprojekte scheitern nicht an der Idee, sondern an der Integration mit bestehenden Systemen. Je enger die Verzahnung mit Legacy-Systemen, desto mehr spricht für einen klar strukturierten Workflow, der an wenigen Stellen Modellintelligenz nutzt.

Wann professionelle Unterstützung sinnvoll ist

Für klar abgegrenzte Automatisierungen mit wenigen Pfaden ist die Entscheidung meist in wenigen Tagen machbar. Sobald aber mehrere Systeme, unklare Fachlogik, hohe Anforderungen an Nachvollziehbarkeit oder sensible Daten im Spiel sind, lohnt sich ein Blick von außen — nicht auf die Frage „Agent oder Workflow?", sondern auf die saubere Zuordnung: wo ist welche Art der Automatisierung angemessen, und wie greifen die Teile ineinander?

Wir arbeiten mit Unternehmen, die nicht den spektakulärsten Ansatz suchen, sondern den belastbaren. Häufig ist das eine bewusste Kombination aus festen Workflows und punktuellen Agenten, flankiert von strukturierter LLM-Qualitätssicherung und einer Architektur, die im Bereich AI Engineering spätere Anpassungen zulässt. Wer gerade diese Entscheidung in einem konkreten Projekt trifft, sollte sie nicht an der Tool-Oberfläche treffen, sondern am Aufgabentyp.