Was ist ein Agent — und warum die Workflow-Frage verschwindet

Die Definition, ohne Magie

„Agent" ist innerhalb von zwei Jahren vom Fachbegriff zum Verkaufsargument geworden. In vielen Gesprächen meint das Wort inzwischen alles zwischen einem Chatbot mit Systemprompt und einem verteilten System, das eigenständig Geld bewegt. Für Unternehmen, die AI in regulierte Prozesse bringen wollen, ist diese Unschärfe teuer: Wer nicht sagen kann, was ein Agent ist, kann auch nicht sagen, welche Kontrollen er braucht.

Deshalb die nüchterne Version:

Ein Agent ist ein Softwaresystem, das ein Sprachmodell in einen wiederholten Entscheidungs- und Ausführungszyklus einbettet.

Das Modell trifft Entscheidungen. Das umgebende System führt sie aus, prüft sie, protokolliert sie und entscheidet, ob die Schleife weiterläuft. Das ist der wichtigste Satz dieses Artikels: Das Modell ist eine Komponente, nicht das System.

Die Schleife selbst ist unspektakulär:

Ziel → Modell → Aktion → Beobachtung → Zustand → Wiederholen

1. Ziel und Kontext. Das Modell erhält ein Ziel, den bisherigen Zustand und die verfügbaren Tools als typisiertes Schema.
2. Entscheidung. Das Modell formuliert eine Aktion. Es führt nichts aus — es äußert einen Wunsch.
3. Prüfung und Ausführung. Die Laufzeitumgebung validiert den Aufruf, prüft ihn gegen Berechtigungen und Budgets und führt ihn aus. Das ist deterministischer Code, nicht Modell-Ermessen.
4. Beobachtung. Das Ergebnis — Erfolg, Fehler, Teilergebnis — wird in den Zustand zurückgeschrieben.
5. Nächster Turn. Bis das Ziel erreicht ist, ein Budget greift oder ein Mensch entscheiden muss.

Ein Workflow ist das Gegenstück: Modelle und Tools werden über vordefinierte Codepfade orchestriert. Der Pfad steht fest, bevor der erste Aufruf passiert. Ein Agent steuert seinen Pfad selbst; ein Workflow bekommt ihn vorgegeben.

Die alte Entscheidungstabelle

Auf dieser Unterscheidung ruhte bis vor Kurzem eine der meistzitierten Faustregeln des Feldes — Anthropic hat sie in Building effective agents sauber formuliert, und wir haben sie selbst so weitergegeben:

| Situation | Bisherige Empfehlung | |---|---| | Der Pfad ist bekannt und stabil | Workflow | | Die Anzahl der Schritte ist vorhersehbar | Workflow | | Ablauf und Kontrollen müssen validierbar und wiederholbar sein | Workflow | | Der Pfad hängt von Zwischenergebnissen ab | Agent | | Der Prozess muss auf unstrukturierte Ausnahmen reagieren | Agent |

Die Logik dahinter: Ein Agent kauft Flexibilität und bezahlt mit Vorhersagbarkeit. In regulierten Prozessen war das der falsche Tausch — also Workflow.

Diese Tabelle ist als Beschreibung der Werkzeuglandschaft von 2024 korrekt. Als Architekturprinzip ist sie es nicht. Denn die dritte Zeile — validierbar und wiederholbar — beschreibt keine Eigenschaft von Agenten. Sie beschreibt eine Eigenschaft der Laufzeitumgebungen, in denen Agenten bisher betrieben wurden.

Warum der Trade-off existierte

Was einen Agenten „unvorhersehbar" machte, war nie die Schleife. Es war die Umgebung:

• Modellversionen ohne Pinning. Derselbe Prompt trifft nächste Woche ein stilles Modell-Update.
• Kontext ohne Protokoll. Was das Modell in Turn 7 tatsächlich gesehen hat, lässt sich im Nachhinein nicht rekonstruieren.
• Tool-Zustände ohne Aufzeichnung. Die API antwortete gestern anders als heute — welcher Stand galt beim Lauf?
• Budgets und Berechtigungen als Empfehlung. Im Systemprompt formuliert statt zur Laufzeit durchgesetzt.

Der Workflow war validierbar, weil sein Codepfad fixiert war. Der Agent war es nicht, weil seine Ausführung nirgends beweisfähig festgehalten wurde. Das ist kein Naturgesetz. Das ist ein Implementierungsstand.

Bemerkenswert ist, was Regulierung tatsächlich verlangt: selten bitweise identische Ergebnisse, sondern dass Ablauf, Kontrollen, Datenherkunft und Entscheidungen nachvollziehbar, validierbar und wiederholbar sind. Die Workflow-Empfehlung war nie „Agenten sind verboten". Sie war: „Agenten können das derzeit nicht nachweisen."

Deterministische Ausführung ändert die Rechnung

Genau an dieser Stelle haben wir gebaut. Auf der LumeSec AI Platform läuft jeder Agent-Turn in einer Laufzeitumgebung, die vier Dinge garantiert:

1. Alles ist versioniert. Modellversion, Systemprompt, Tool-Contracts, Policy-Stand und Einstellungen sind Teil des aufgezeichneten Laufs — nicht Metadaten daneben.
2. Alles ist Ereignis. Jeder Kontext, jede angeforderte Aktion, jede Prüfung, jede Beobachtung wird deterministisch serialisiert und als Event festgehalten.
3. Jeder Lauf trägt einen Trace-Hash. Das Hash über die deterministisch serialisierten Events. Ein Replay desselben Laufs erzeugt denselben Hash — replay-äquivalent, nicht bloß „ähnliches Ergebnis".
4. Jedes Event ist signiert. Ed25519, append-only, im Besitz des Kunden. Auditoren verifizieren eine Kette, keine Erzählung.

Berechtigungen und Budgets hängen dabei am Turn, nicht am Agenten, und werden zur Laufzeit durchgesetzt. Human-in-the-Loop ist eine Eigenschaft der Schleife, kein nachgelagerter Review.

Damit hat ein Agent exakt die Eigenschaften, die die Tabelle den Workflows vorbehalten hatte: Sein Ablauf ist rekonstruierbar, seine Kontrollen sind belegbar, sein Lauf ist wiederholbar — unter Beweis. Und der Workflow verliert nichts: In derselben Umgebung ist ein Workflow schlicht ein Agent mit null Freiheitsgraden. Beide laufen unter demselben Audit-Kontrakt.

Die Frage, die übrig bleibt

Die Entscheidung „Agent oder Workflow?" ist damit keine Governance-Entscheidung mehr. Sie ist eine Designfrage geworden: Wie viel Freiheit braucht dieser Prozess?

• Ein stabiler, bekannter Pfad bekommt null Freiheitsgrade — er läuft als vollständig vordefinierter Ablauf.
• Ein Prozess mit unstrukturierten Ausnahmen bekommt Spielraum — innerhalb runtime-durchgesetzter Berechtigungen, Budgets und Abbruchbedingungen.
• Beides erzeugt denselben signierten, replay-äquivalenten Nachweis.

Man wählt nicht mehr zwischen Kontrolle und Flexibilität. Man stellt einen Regler ein — und die Nachweisführung bleibt konstant.

Zur Ehrlichkeit gehört die Abgrenzung: Determinismus heißt hier Replay-Äquivalenz — gleiche Inputs, gleicher Trace-Hash, über Versionen, Regionen und Zeit hinweg. Es heißt nicht, dass ein Modell auf neue Eingaben wie eine Nachschlagetabelle reagiert. Neue Fälle erzeugen weiterhin Modell-Urteile. Der Unterschied: Jedes dieser Urteile ist begrenzt, budgetiert, signiert und im Nachhinein Schritt für Schritt rekonstruierbar. Das ist die Eigenschaft, die Prüfer tatsächlich verlangen — und die bisher der Grund war, Agenten aus regulierten Prozessen fernzuhalten.

Ein Chatfenster macht noch keinen Agenten. Eine Schleife macht noch kein System, das man in einen regulierten Prozess stellen kann. Und eine Entscheidungstabelle, die auf dem Misstrauen gegenüber der Laufzeitumgebung beruht, überlebt die Laufzeitumgebung nicht, die dieses Misstrauen gegenstandslos macht.

Predictable AI. Built for Enterprise.

---

Quellen

• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022 (arXiv:2210.03629) — Reasoning und Acting in einer Schleife.
• Anthropic, Building effective agents, Engineering Blog, 2024-12-19 — die Abgrenzung zwischen Workflows mit vordefinierten Codepfaden und Agenten, die ihren Ablauf selbst steuern.
• OWASP GenAI Security Project, Top 10 for LLM Applications, Ausgabe 2025 — LLM01 Prompt Injection, LLM06 Excessive Agency, LLM10 Unbounded Consumption.
• Russell & Norvig, Artificial Intelligence: A Modern Approach — die klassische Agentendefinition.