KI-Agent vs. Workflow vs. Automation: Welche Architektur passt?

Nicht jeder Prozess mit einem LLM braucht einen AI Agent. In vielen Unternehmen ist ein klassischer Workflow mit einzelnen KI-Schritten zuverlässiger, günstiger und leichter abzusichern.

Die wichtigste Unterscheidung lautet:

Wer bestimmt zur Laufzeit den nächsten Schritt – die vorab definierte Prozesslogik oder das Modell?

Anthropic beschreibt genau diese Trennung: Workflows orchestrieren LLMs und Tools über vordefinierte Codepfade; Agents steuern ihren Prozess und Tool-Einsatz dynamischer selbst. Quelle: Anthropic – Building effective agents.

Die Kurzfassung

| Architektur | Wer steuert den Ablauf? | Stärke | Hauptrisiko | | --- | --- | --- | --- | | klassische Automation | Regeln / Code | deterministisch, günstig, testbar | geringe Flexibilität | | LLM-Workflow | Regeln / Code + einzelne KI-Schritte | flexible Verarbeitung in kontrolliertem Ablauf | Fehler in KI-Schritten | | AI Agent | Modell entscheidet nächste Schritte / Tools | hohe Flexibilität bei variablen Aufgaben | schwerer vorhersehbar und testbar | | Hybrid | Workflow begrenzt Agentenraum | kontrollierte Autonomie | mehr Architekturarbeit |

Empfehlung: Verwenden Sie die geringste Autonomie, die das Problem tatsächlich benötigt.

1. Klassische Automation

Eine klassische Automation eignet sich, wenn Inputs, Regeln und Aktionen klar sind.

Beispiel:

1. Rechnung kommt per E-Mail.
2. PDF wird gespeichert.
3. Lieferant wird über Stammdaten erkannt.
4. Freigabe wird anhand Betrag und Kostenstelle geroutet.
5. Daten werden ins ERP geschrieben.

Wenn diese Logik vollständig regelbasiert funktioniert, bringt ein autonomer Agent wenig Mehrwert.

Vorteile

• reproduzierbares Verhalten,
• klare Fehlerpfade,
• einfache Tests,
• geringe Latenz,
• geringere Kosten,
• leichteres Auditing.

2. LLM-Workflow

Ein LLM-Workflow hält den Prozess deterministisch, nutzt KI aber dort, wo unstrukturierte Information verarbeitet werden muss.

Beispiel:

1. Dokument empfangen.
2. LLM extrahiert relevante Felder.
3. Schema-Validierung prüft die Ausgabe.
4. Regelwerk entscheidet den nächsten Schritt.
5. Mensch bestätigt bei Unsicherheit.
6. API schreibt freigegebene Daten.

Das LLM löst eine enge kognitive Teilaufgabe, bestimmt aber nicht frei den gesamten Prozess.

Für viele Unternehmensanwendungen ist das ein sehr guter Sweet Spot.

3. AI Agent

Ein Agent bekommt ein Ziel, Kontext und erlaubte Tools. Er entscheidet stärker selbst:

• welche Information fehlt,
• welches Tool er aufruft,
• in welcher Reihenfolge,
• ob ein Zwischenergebnis reicht,
• ob er einen alternativen Weg versucht.

Anthropic definiert Agenten 2026 praktisch als Modelle, die ihren Prozess und Tool-Einsatz selbst steuern und in einer Schleife planen, handeln, beobachten und anpassen. Quelle: Anthropic – Trustworthy agents in practice.

Das ist nützlich, wenn der Lösungsweg nicht sinnvoll vollständig vorprogrammiert werden kann.

Entscheidungsmatrix

| Frage | Wenn „ja“ | Architektur-Tendenz | | --- | --- | --- | | Ist der Prozess stabil und vollständig beschreibbar? | ja | Automation / Workflow | | Gibt es unstrukturierte Texte, aber feste Folgeprozesse? | ja | LLM-Workflow | | Muss das System zwischen mehreren Tools dynamisch wählen? | ja | Agent möglich | | Ändert sich der Lösungsweg je nach Zwischenergebnis? | ja | Agent / Hybrid | | Sind falsche Aktionen teuer oder irreversibel? | ja | Workflow + Human Gate | | Muss jeder Schritt deterministisch reproduzierbar sein? | ja | kein autonomer Agent | | Gibt es viele Ausnahmen, die schwer regelbasiert modellierbar sind? | ja | begrenzter Agent kann sinnvoll sein | | Ist die Aufgabe nur „Text generieren“? | ja | meist kein Agent nötig |

Das Autonomie-Prinzip

Agentic AI sollte nicht als binäre Kategorie betrachtet werden.

Sinnvoller ist ein Autonomie-Spektrum:

1. Assist: Modell liefert Vorschlag, Mensch handelt.
2. Structured AI step: Modell erzeugt strukturierte Ausgabe, Workflow handelt.
3. Bounded agent: Modell darf zwischen wenigen Tools und Pfaden entscheiden.
4. High-autonomy agent: Modell plant mehrere Schritte und handelt weitgehend selbst.

Je höher die Autonomie, desto stärker müssen Kontrolle und Evaluation werden.

Warum mehr Autonomie mehr Architektur braucht

Ein Workflow kann vorab getestet werden, weil der Ablauf bekannt ist.

Ein Agent kann:

• andere Tools auswählen,
• Schritte wiederholen,
• unerwartete Reihenfolgen wählen,
• externe Inhalte interpretieren,
• Zustand verändern.

Damit wird nicht nur die finale Antwort relevant, sondern die gesamte Execution Trace.

Deshalb gehören bei Agenten mindestens folgende Fragen in die Architektur:

• Welche Tools sind erlaubt?
• Mit welcher Identität werden Tools ausgeführt?
• Welche Parameter dürfen gesetzt werden?
• Welche Aktionen benötigen Freigabe?
• Welche Systeme sind read-only?
• Wie werden Tool Calls geloggt?
• Wann muss der Agent stoppen?
• Was passiert bei Unsicherheit oder Fehlern?

Human-in-the-loop ist eine Architekturkomponente

„Der Mensch schaut notfalls drauf“ ist kein Kontrollkonzept.

Human Gates müssen konkret definiert sein.

Beispiele:

• vor einer Zahlung,
• vor dem Versand externer Kommunikation,
• vor Löschung oder Änderung produktiver Daten,
• bei niedrigem Confidence-Signal,
• wenn ein Policy-Check fehlschlägt,
• wenn Daten aus nicht vertrauenswürdigen Quellen stammen.

Die Freigabe gehört als technischer Zustand in den Workflow, nicht als informelle Erwartung.

Tool Calling verändert das Risikoprofil

Ein Chatbot, der nur Text erzeugt, kann falsche Antworten liefern.

Ein Agent mit Tools kann zusätzlich:

• Daten verändern,
• APIs aufrufen,
• Nachrichten senden,
• Dateien verschieben,
• Rechte ausnutzen,
• Geschäftsprozesse auslösen.

Das bedeutet: Tool-Security ist nicht nur Prompt Engineering.

Erforderlich sind unter anderem:

• Least Privilege,
• getrennte Tool-Identitäten,
• Input-/Output-Validierung,
• klare Allow-Lists,
• Transaktionsgrenzen,
• Audit Logs,
• Freigaben für kritische Aktionen.

Hybrid-Architektur: oft die beste Enterprise-Lösung

In Unternehmen ist häufig nicht „Workflow oder Agent“, sondern eine Kombination sinnvoll.

Beispiel:

Deterministischer Workflow

1. Auftrag wird klassifiziert.
2. Rechte und Kontext werden vorbereitet.
3. Budget und erlaubte Aktionen werden festgelegt.

Bounded Agent

4. Agent recherchiert innerhalb zugelassener Quellen.
5. Agent wählt aus drei freigegebenen Tools.
6. Agent erstellt einen Vorschlag.

Deterministischer Workflow

7. Validierung prüft Ergebnis.
8. Mensch genehmigt kritische Aktion.
9. System führt sie aus und protokolliert sie.

So bleibt flexible Entscheidungslogik dort, wo sie Nutzen bringt, während Systemgrenzen kontrollierbar bleiben.

Kosten und Latenz nicht vergessen

Agenten können mehrere Modell- und Tool-Aufrufe benötigen.

Ein Prozess, der mit einem einzelnen strukturierten LLM-Call lösbar ist, sollte nicht automatisch in eine mehrstufige Agentenschleife umgebaut werden.

Mehr Autonomie kann bedeuten:

• mehr Tokens,
• mehr API-Calls,
• höhere Latenz,
• mehr Fehlermöglichkeiten,
• komplexere Evaluation,
• höhere Betriebs- und Supportlast.

Die Architektur sollte deshalb nach Business Task, nicht nach Agentic-AI-Trend gewählt werden.

Wie Sie die Entscheidung testen

Nehmen Sie einen realen Prozess und bauen Sie zwei kleine Varianten:

Variante A – kontrollierter Workflow

• feste Schritte,
• ein bis zwei LLM-Funktionen,
• klare Validierung.

Variante B – bounded Agent

• identische Aufgabe,
• klar definierte Tool-Liste,
• begrenzte Schleifen,
• dieselben Testfälle.

Vergleichen Sie:

• Task Success,
• Fehlerquote,
• Anzahl menschlicher Eingriffe,
• Latenz,
• Kosten,
• Reproduzierbarkeit,
• Security- und Berechtigungsrisiken.

Dann entscheiden Sie anhand von Evidenz statt Architekturmode.

Wann ein Workshop sinnvoll ist

Wenn noch unklar ist, welche Prozesse überhaupt agentisch werden sollten, ist Build häufig zu früh.

Dann sollten zuerst Use Case, Prozessgrenzen, erlaubte Aktionen, Daten, Risikoklasse und Erfolgskriterien geklärt werden.

Dafür ist der KI-Workshop: Use Cases priorisieren und Pilot planen der passende Einstieg.

Wenn die Zielarchitektur bereits klarer ist, kann AI Architecture Consulting die Systemgrenzen, Integrationen und Betriebsmodelle konkretisieren.

Wenn bereits ein Agent existiert

Ein funktionierender Demo-Agent ist noch kein Produktionsnachweis.

Sobald ein Agent Tools nutzt oder Geschäftsprozesse beeinflusst, müssen Outcome, Tool-Auswahl, Parameter, Berechtigungen, Guardrails und Fehlerpfade messbar getestet werden.

Dafür folgt als nächster Deep Dive: AI Agent Evaluation: Zuverlässigkeit, Tool Calls und Regressionen messen.

Für einen vorhandenen PoC ist KI Production Readiness die passende kommerzielle Anschlussseite.