Von Workflows zu Agent-Flows

Was Unternehmen „KI-Automatisierung“ nennen, ist meist nur schnelleres Tippen

Unternehmen haben das letzte Jahrzehnt damit verbracht, Geschäftslogik in Workflows zu gießen. Schritt A, dann B, dann C. Freigaben an festen Entscheidungspunkten. Ausnahmebehandlung über vordefinierte Verzweigungen. BPMN-Diagramme am Whiteboard, übersetzt in Airflow-DAGs oder Power-Automate-Flows.

Jetzt stecken dieselben Unternehmen LLMs in diese Workflows und nennen das KI-Transformation. Ist es aber nicht. Das ist, als würde man einem Pferdewagen ein Düsentriebwerk montieren. Das Triebwerk ist stark. Der Wagen fährt trotzdem nur auf dem vorgegebenen Weg.

Die MIT-Sloan-Studie zur Skalierung von KI zeigt: Die meisten Organisationen kommen über isolierte Pilotprojekte deshalb nicht hinaus, weil sie KI auf bestehende Prozesse aufsetzen, statt die Prozessform selbst neu zu denken. Die Grenze liegt nicht in der Leistungsfähigkeit der Modelle. Sie liegt in der Prozessarchitektur.

Diagnose: Warum Workflows unter Unsicherheit zerbrechen

Klassische Workflows kodieren Gewissheit. Sie setzen voraus, dass Sie den Weg kennen, bevor Sie ihn gehen. Diese Annahme trug, solange die Arbeit vorhersehbar war – Rechnungsverarbeitung, Auftragsabwicklung, Compliance-Prüfungen mit stabilen Regelwerken.

Agentengetriebene Arbeit funktioniert anders. Nehmen Sie eine Due-Diligence-Prüfung für eine mögliche Übernahme. Der Agent muss Finanzberichte ziehen, sie mit der Berichterstattung in den Medien abgleichen, regulatorische Risiken in den Jurisdiktionen identifizieren, in denen das Zielunternehmen tätig ist und Inkonsistenzen markieren, die eine tiefere Untersuchung rechtfertigen. Die Reihenfolge steht nicht vorab fest. Was der Agent in Schritt zwei findet, verändert, was er in Schritt drei tun sollte.

Drei konkrete Brüche treten auf, wenn Sie diese Art von Arbeit in einen klassischen Workflow zwingen:

Fehlendes Zustandsgedächtnis. Workflows sind zwischen den Schritten zustandslos. Jede Aufgabe bekommt Eingaben, erzeugt Ausgaben, reicht sie weiter. Aber ein Agent, der über ein komplexes Problem nachdenkt, braucht Gedächtnis – was er versucht hat, was gescheitert ist, welchen Kontext er sich aufgebaut hat. Ein Agent in der Schadensbearbeitung, der nicht weiß, dass er die Policendatenbank bereits abgefragt hat, fragt sie wieder ab. Und wieder.

Fragile Integrationen. Workflows binden Systeme über fest verdrahtete API-Aufrufe an. Braucht der Agent ein Tool, für das er nicht vorkonfiguriert wurde, bleibt er stehen. Es gibt kein Protokoll für „Ich muss etwas nachschlagen, wofür ich nicht ausgelegt bin“. Jede neue Fähigkeit verlangt einen Entwickler, der einen Konnektor baut und neu deployt.

Unsichtbares Reasoning. Workflows protokollieren den Abschluss von Aufgaben. Agent-Flows müssen das Warum protokollieren. Was hat der Agent erwogen? Welche Alternativen hat er verworfen? Wenn ein Workflow scheitert, schauen Sie ins Fehlerprotokoll. Wenn ein Agent-Flow eine falsche Antwort produziert, brauchen Sie die vollständige Spur seines Reasonings. Die meisten Workflow-Engines erfassen das nicht.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
graph LR
    subgraph WORKFLOW ["Klassischer Workflow"]
        W1["Schritt A"] --> W2["Schritt B"] --> W3["Schritt C"] --> W4["Fertig"]
    end
    subgraph AGENTFLOW ["Agent Flow"]
        A1["Planen"] --> A2["Tool ausführen"]
        A2 --> A3["Ergebnis prüfen"]
        A3 -->|"Plan überarbeiten"| A1
        A3 -->|"Weiter"| A4["Nächste Aktion"]
        A4 --> A5["Ergebnis prüfen"]
        A5 -->|"Plan überarbeiten"| A1
        A5 -->|"Fertig"| A6["Abschluss"]
    end
    style WORKFLOW fill:#2a1a1a,stroke:#ff6b6b,color:#ffffff
    style AGENTFLOW fill:#0a2a1e,stroke:#00ff88,color:#ffffff
    style W1 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b
    style W2 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b
    style W3 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b
    style W4 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b
    style A1 fill:#1a2540,stroke:#00d4ff,color:#00d4ff
    style A2 fill:#1a2540,stroke:#ffb347,color:#ffb347
    style A3 fill:#1a2540,stroke:#00ff88,color:#00ff88
    style A4 fill:#1a2540,stroke:#ffb347,color:#ffb347
    style A5 fill:#1a2540,stroke:#00ff88,color:#00ff88
    style A6 fill:#1a2540,stroke:#00ff88,color:#00ff88

Perspektivwechsel: „Yes, and …“ – was Improvisationstheater über Agent-Design lehrt

Folgender Vergleich hat das Problem für mich neu sortiert: Improvisationstheater.

Im Theater mit festem Skript folgt jeder Schauspieler dem Text. Zeilen sind auswendig gelernt. Bühnenwege sind einstudiert. Der Regisseur kontrolliert das Ergebnis. Workflows funktionieren nach demselben Muster – vordefinierte Schritte, vorhersehbare Resultate. Weicht jemand ab, bricht das Stück.

Improvisation hat ein Grundprinzip: „Yes, and …“. Ein Spieler macht ein Angebot. Der nächste nimmt es an und baut darauf auf. Die Szene entsteht aus dem, was im Moment entdeckt wird, nicht aus dem, was vorher geplant wurde. Die Spieler sind geübt, aber der Verlauf ist nicht geschrieben. Worauf es ankommt, ist ihre Fähigkeit, auf das zu reagieren, was tatsächlich passiert – nicht auf das, was passieren sollte.

Agent-Flows funktionieren genauso. Das ReAct-Muster – Reasoning + Acting, von Yao et al. an der Princeton University eingeführt – formalisiert genau das. Der Agent denkt über den aktuellen Zustand nach, handelt, beobachtet das Ergebnis, denkt erneut nach. Jeder Schritt baut auf dem auf, was entdeckt wurde, nicht auf dem, was geplant war. Planen, handeln, beobachten, überarbeiten. „Yes, and …“

Aber Improvisation ist kein Chaos. Die besten Improtruppen haben Struktur: Szenenformate, Figurenkonventionen, Zeitvorgaben, ein gemeinsames Verständnis davon, was eine Szene trägt. Erst die Struktur ermöglicht die Freiheit. Nehmen Sie die Struktur weg, bekommen Sie Lärm, keine Kreativität.

Agent-Flows brauchen dieselbe Art disziplinierter Struktur. Ohne sie wird aus „Yes, and …“ schnell „Yes, and … wir haben keine Ahnung, was passiert ist und warum.“

Framework: Drei architektonische Veränderungen für Agent-Flows

Der Übergang von Workflows zu Agent-Flows verlangt drei grundlegende Veränderungen. Ich habe noch kein Unternehmen gesehen, das bei agentischer KI Erfolg hatte, ohne alle drei anzupacken.

Veränderung 1: State und Memory als First-Class Citizens

Workflows reichen Daten zwischen Schritten weiter. Agent-Flows sammeln Kontext.

Ein Agent, der einen komplexen Versicherungsfall bearbeitet, muss sich erinnern: welche Dokumente er gesichtet hat, welche Inkonsistenzen er gefunden hat, welche externen Datenbanken er abgefragt hat, welche Hypothesen er gebildet und wieder verworfen hat. Das ist keine Variable, die zwischen Aufgaben weitergereicht wird. Es ist ein Arbeitsgedächtnis, das während der Ausführung wächst und sich verändert.

Praktisch heißt das: persistente State-Stores – nicht nur Message Queues. Memory auf Konversationsebene, auf Aufgabenebene und sitzungsübergreifend sind drei verschiedene Anforderungen, jede mit eigener Speicher- und Abrufstrategie. Ich bin nicht sicher, dass die Branche sich hier schon auf die richtigen Abstraktionen geeinigt hat. Die meisten Teams, mit denen ich spreche, bauen ihr State-Management von Hand – das ist teuer und fragil.

Veränderung 2: Tool Contracts statt Ad-hoc-Integrationen

Workflows rufen APIs auf. Agent-Flows verhandeln mit Tools.

Der Unterschied ist wesentlich. Wenn ein Workflow eine API aufruft, ist die Integration fest verdrahtet: Endpunkt, Payload-Format, Authentifizierung, Fehlerbehandlung – alles bereits zur Entwicklungszeit festgelegt. Wenn ein Agent mit einem System interagieren soll, muss er erkennen, welche Tools verfügbar sind, ihre Fähigkeiten und Grenzen verstehen, sie korrekt aufrufen und Fehler sauber behandeln.

Das Model Context Protocol (MCP) ist der vielversprechendste Versuch, das zu standardisieren. MCP definiert einen Vertrag: Das tut dieses Tool, das sind seine Ein- und Ausgaben, das sind seine Grenzen. Der Agent braucht keine Sonderintegration pro System. Er braucht ein Protokoll, mit dem er Tools zur Laufzeit findet und nutzt.

Das ist eine echte Veränderung der Integrationsarchitektur. Statt Punkt-zu-Punkt-Konnektoren, die Plattform-Teams pflegen, bekommen Sie standardisierte Tool Contracts, die Agenten zur Laufzeit auffinden. Der Trade-off ist real: Dynamische Tool-Discovery bringt Latenz und Fehlermodi mit, die statische Integrationen nicht haben.

Veränderung 3: Evaluation und Tracing als Teil der Entwicklung

Workflows haben Unit-Tests. Agent-Flows brauchen Eval-Suites.

Sie können einen Agenten nicht so unit-testen, wie Sie eine Funktion testen. Das Verhalten des Agenten hängt von der Folge seiner Beobachtungen ab, vom Zustand, den er aufbaut, und vom Reasoning, das er anwendet – alles variiert von Lauf zu Lauf. Ein Agent, der über falsches Reasoning zur richtigen Antwort kommt, ist eine Zeitbombe.

Jeden Reasoning-Schritt, jeden Tool-Aufruf und jede Zustandsänderung zu tracen, ist kein nachträglicher Debugging-Schritt. Es ist eine Entwicklungsanforderung. Wenn Ihr Schadensbearbeitungs-Agent eine Auszahlung freigibt, die er nicht hätte freigeben dürfen, müssen Sie die vollständige Entscheidungskette rekonstruieren: Welche Daten hat er gesehen, welche Tools hat er aufgerufen, welches Reasoning führte zur Freigabe, und an welcher Stelle dieses Reasoning fehlerhaft wurde.

OpenClaw kodiert Agent-Flows als plan, tool, verify, continue; NanoClaw-Worker sind bewusst eng begrenzte Ausführungseinheiten, die jeweils auf eine einzelne Tool-Domäne zugeschnitten sind. Dieses Muster – explizite Verifikation nach jedem Tool-Aufruf, begrenzter Ausführungsbereich pro Worker – adressiert Tracing und Blast-Radius gleichzeitig.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
graph TD
    S1["Veränderung 1: State + Memory"]
    S2["Veränderung 2: Tool Contracts"]
    S3["Veränderung 3: Eval + Tracing"]
    S1 --- CORE["Agent-Flow\nEngineering"]
    S2 --- CORE
    S3 --- CORE
    S1D["Persistenter Kontext\nArbeitsgedächtnis\nSitzungsübergreifender Abruf"]
    S2D["MCP-Protokoll\nDynamische Discovery\nStandardisierte Schnittstellen"]
    S3D["Reasoning-Traces\nVerifikation pro Schritt\nEval-Suites"]
    S1 --> S1D
    S2 --> S2D
    S3 --> S3D
    style CORE fill:#1a2540,stroke:#ffffff,color:#00d4ff,stroke-width:2px
    style S1 fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style S2 fill:#1a2540,stroke:#ffb347,color:#ffb347,stroke-width:2px
    style S3 fill:#1a2540,stroke:#00ff88,color:#00ff88,stroke-width:2px
    style S1D fill:#1a2540,stroke:#ffffff,color:#ffffff
    style S2D fill:#1a2540,stroke:#ffffff,color:#ffffff
    style S3D fill:#1a2540,stroke:#ffffff,color:#ffffff

Anwendung: Lemonades Schadenspipeline – vom Workflow zum Agent-Flow

AI Jim von Lemonade Insurance ist das klarste öffentlich dokumentierte Beispiel einer Schadenspipeline, die vom Workflow zum Agent-Flow umgebaut wurde. Der klassische Versicherungsprozess ist ein typischer linearer Workflow: Schadenmeldung entgegennehmen, Deckung prüfen, Schadenhöhe bewerten, Auszahlung berechnen, freigeben und auszahlen. Branchendurchschnitt: Tage bis Wochen.

Die Agent-Flow-Variante arbeitet anders. AI Jim nimmt den Schadensfall an und plant das Vorgehen anhand der Fallmerkmale. Ein einfacher Fall – kaputtes Handydisplay, gestohlenes Fahrrad – läuft im Schnellverfahren durch: Deckungsprüfung, Schadensbewertung, Auszahlungsberechnung, alles in einem Durchgang. Ein komplexer Fall oder eine hohe Schadenssumme löst einen anderen Plan aus: zusätzliche Verifikation, Abgleich mit Betrugsmustern, Weiterleitung an einen menschlichen Sachbearbeiter.

Der entscheidende Unterschied zeigt sich, wenn etwas Unerwartetes auftaucht. In einem klassischen Workflow würde eine Inkonsistenz zwischen der Schilderung des Anspruchstellers und den Belegen in eine Warteschlange für die manuelle Prüfung geleitet und dort warten. In Lemonades Agent-Flow überarbeitet AI Jim seinen Plan: Er zieht zusätzliche Daten, lässt eine zweite Analyse laufen und löst entweder die Inkonsistenz auf oder eskaliert mit einer strukturierten Zusammenfassung dessen, was genau nicht zusammenpasst und warum.

Die Ergebnisse sind öffentlich. 55 % der Schadensfälle werden vollautonom bearbeitet. Der Rekord: ein einzelner Fall in 2 Sekunden reguliert. 96 % der Erstmeldungen erledigt die KI. Komplexe Fälle gehen weiterhin an menschliche Sachbearbeiter, aber mit einem voranalysierten Briefing statt einer Rohakte. Das Muster bestätigt, was ich in der Branche immer wieder sehe: Das Schwierigste ist nicht, den Agenten zu bauen – sondern das State-Management und die Tracing-Infrastruktur, die den Agenten vertrauenswürdig machen.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
flowchart LR
    subgraph OLD ["Alt: Linearer Workflow"]
        O1["Empfangen"] --> O2["Prüfen"] --> O3["Bewerten"] --> O4["Berechnen"] --> O5["Freigeben"] --> O6["Zahlen"]
    end
    subgraph NEW ["Neu: Agent Flow"]
        N1["Empfangen + Planen"] --> N2["Tools ausführen"]
        N2 --> N3{"Unerwarteter\nBefund?"}
        N3 -->|"Ja"| N4["Plan überarbeiten"]
        N4 --> N2
        N3 -->|"Nein"| N5["Auflösen oder\nEskalieren"]
    end
    style OLD fill:#2a1a1a,stroke:#ff6b6b,color:#ffffff
    style NEW fill:#0a2a1e,stroke:#00ff88,color:#ffffff
    style N1 fill:#1a2540,stroke:#00d4ff,color:#00d4ff
    style N2 fill:#1a2540,stroke:#ffb347,color:#ffb347
    style N3 fill:#1a2540,stroke:#ffffff,color:#ffffff
    style N4 fill:#1a2540,stroke:#00d4ff,color:#00d4ff
    style N5 fill:#1a2540,stroke:#00ff88,color:#00ff88
    style O1 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b
    style O2 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b
    style O3 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b
    style O4 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b
    style O5 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b
    style O6 fill:#1a2540,stroke:#ff6b6b,color:#ff6b6b

Konsequenz: Hören Sie auf, das Skript zu automatisieren

Der Übergang von Workflows zu Agent-Flows ist nicht inkrementell. Er ist architektonisch. State-Management, Tool Contracts und Evaluations-Infrastruktur sind keine Nice-to-haves, die man später nachträglich ergänzt – sie sind Voraussetzungen. Unternehmen, die Agent-Flows als „smartere Workflows“ behandeln, stoßen an dieselbe Grenze, die MIT Sloan beschreibt: isolierte Pilotprojekte, die nie skalieren. Wer die Prozessarchitektur neu entwirft – wer vom Prinzip „dem Skript folgen“ zu „Yes, and …“ übergeht – baut Systeme, die Unsicherheit von Haus aus aushalten. Genau dort entsteht der Wert mit Zinseszinseffekt.

Quellen

• Yao et al. – ReAct: Synergizing Reasoning and Acting in Language Models (arXiv)
• MIT Sloan – Scaling AI for Results (Januar 2026)
• Model Context Protocol (MCP) – Einführung und Spezifikation
• Lemonade Insurance: AI Jim setzt neuen Weltrekord

Daniel Piatkowski — Data & Analytics-Veteran, der AI-native Unternehmen prägt.