Automation ist nicht Agentic AI
Der Unterschied zwischen Ablauf und Handlungsspielraum.

Viele KI-Projekte werden heute als „agentisch" bezeichnet, obwohl sie im Kern nur automatisierte Abläufe mit einem Sprachmodell an einzelnen Stellen sind. Ein Trigger startet eine Kette, Daten werden weitergereicht, ein Modell erzeugt Text, danach folgt der nächste fest definierte Schritt. Das kann sehr nützlich sein. Es ist aber etwas anderes als ein System, das innerhalb eines Zielrahmens selbst entscheiden darf, wie es weiterarbeitet.
Der Unterschied ist nicht akademisch. Er entscheidet darüber, wie ein System geplant, getestet, überwacht und abgesichert werden muss. Eine klassische Automation braucht vor allem einen korrekten Ablauf. Ein agentisches System braucht zusätzlich einen kontrollierten Handlungsspielraum. Sobald nicht mehr nur festgelegt wird, was als Nächstes passiert, sondern ein Modell mitentscheidet, welcher nächste Schritt sinnvoll ist, verändert sich die Architektur.
Deshalb sollte die Frage nicht lauten: „Ist dieses System ein Agent?" Die produktivere Frage lautet: Welche Entscheidungen darf das System selbst treffen, und welche bleiben fest verdrahtet?
Automation ist ein vorab entworfener Weg
Automation bedeutet zunächst, dass ein bekannter Ablauf maschinell ausgeführt wird. Ein Ereignis löst eine definierte Folge aus. Die einzelnen Schritte können einfache Regeln, Datenbankabfragen, API-Aufrufe oder auch KI-Modelle enthalten. Entscheidend ist nicht, ob irgendwo KI vorkommt. Entscheidend ist, wo die Prozesslogik liegt.
Bei einer klassischen Automation liegt diese Logik überwiegend außerhalb des Modells. Ein Entwickler, eine Fachperson oder ein Workflow-System hat vorher festgelegt, was auf einen bestimmten Zustand folgt. Wenn A eintritt, wird B ausgeführt. Falls Bedingung C erfüllt ist, geht der Prozess zu D, sonst zu E. Auch komplexe Verzweigungen können vollständig automatisiert sein, ohne agentisch zu werden.
Gerade in stabilen Prozessen ist das ein Vorteil. Vorhersehbare Abläufe lassen sich leichter testen, reproduzieren und überwachen. Wenn Rechnungen aus einem bekannten Eingangskanal gelesen, nach festen Kriterien benannt, in einem definierten Ordner gespeichert und anschließend an eine Buchhaltungsschnittstelle übergeben werden sollen, kann eine deterministische Automation genau richtig sein. Ein Agent, der bei jedem Durchlauf neu überlegt, wie er die Dateien behandelt, würde hier möglicherweise nur zusätzliche Kosten und Unsicherheit erzeugen.
Automation ist deshalb keineswegs die „alte" oder minderwertige Variante. Sie ist die stärkere Wahl, wenn das Problem selbst gut strukturiert ist.
Ein Sprachmodell in der Kette macht noch keinen Agenten
Die Verwechslung beginnt oft dort, wo ein LLM in einen Workflow eingebaut wird. Ein System nimmt beispielsweise eine E-Mail entgegen, lässt sie von einem Modell klassifizieren und führt anschließend anhand der Klassifikation eine feste Aktion aus. Die Klassifikation ist probabilistisch, der Gesamtprozess kann trotzdem weitgehend automatisiert sein.
Ähnlich verhält es sich mit einer Sequenz aus mehreren Prompts. Wenn Prompt A immer Prompt B auslöst und danach stets Prompt C folgt, entsteht eine KI-gestützte Pipeline. Sie kann anspruchsvoll sein und sehr gute Ergebnisse liefern. Agentisch wird sie erst dann, wenn das Modell relevante Teile des Ausführungswegs selbst steuert.
Diese Unterscheidung ist wichtig, weil „KI" und „Agency" zwei verschiedene Eigenschaften sind. Ein System kann hochintelligente Einzelschritte ausführen und trotzdem kaum Handlungsspielraum besitzen. Umgekehrt kann ein relativ einfaches Modell in einem System mit beträchtlichem Handlungsspielraum operieren, wenn es Werkzeuge auswählen, Zwischenergebnisse bewerten, Wiederholungen auslösen und Folgeaktionen bestimmen darf.
Die technische Kernfrage lautet also nicht: Wie intelligent ist der einzelne Schritt? Sondern: Wie viel Kontrolle über den Prozess besitzt das Modell zur Laufzeit?
Agentic AI verschiebt Ablaufkontrolle in die Laufzeit
Agentische Systeme verlagern einen Teil der Ablaufkontrolle vom vorab geschriebenen Prozess in die Laufzeit. Das Modell erhält ein Ziel, Kontext, Werkzeuge, Regeln und Grenzen. Danach entscheidet es innerhalb dieses Rahmens, welche Aktion als Nächstes sinnvoll ist.
Das kann bedeuten, dass ein Agent zuerst eine Datei liest, anschließend eine Wissensbasis durchsucht, danach erkennt, dass eine Information fehlt, eine weitere Recherche startet, einen Zwischenstand bewertet und erst dann einen Bericht erzeugt. Die genaue Folge muss nicht in jedem Durchlauf gleich sein.
Anthropic beschreibt genau diese architektonische Grenze: Bei Workflows werden Modelle und Werkzeuge über vordefinierte Codepfade orchestriert; bei Agents steuert das Modell Prozess und Werkzeugnutzung dynamischer selbst.[1] OpenAI trennt ähnlich zwischen LLM-Anwendungen, in denen das Modell nur einzelne Aufgaben erledigt, und Agents, bei denen das Modell die Ausführung des Workflows mitsteuert, Werkzeuge zustandsabhängig auswählt, Fehler korrigieren und bei Bedarf stoppen oder zurückgeben kann.[2]
Damit entstehen Fähigkeiten, die eine feste Automation nur mit immer mehr Verzweigungen nachbilden könnte. Gleichzeitig entsteht aber auch eine neue Fehlerfläche. Jede zusätzliche Entscheidungsmöglichkeit ist zugleich eine zusätzliche Möglichkeit, die falsche Entscheidung zu treffen.
Der eigentliche Unterschied liegt in der nächsten Entscheidung
Die sauberste Grenze lässt sich an einer einfachen Frage erkennen: Wer bestimmt den nächsten Schritt?
In einer Automation entscheidet der vorher entworfene Ablauf. Selbst wenn ein Modell innerhalb eines Schritts klassifiziert, zusammenfasst oder Text erzeugt, bleibt der nächste Systemzustand durch Regeln bestimmt. In einem agentischen System kann dagegen das Modell aus dem aktuellen Zustand ableiten, welche Aktion, welches Werkzeug oder welcher Teilpfad als Nächstes sinnvoll ist.
| Architekturfrage | Automation | Begrenzte Agentik | Weiter Handlungsspielraum |
|---|---|---|---|
| Reihenfolge der Schritte | vorgegeben | teilweise wählbar | dynamisch |
| Werkzeugwahl | fest | aus definierter Auswahl | situativ innerhalb breiter Grenzen |
| Umgang mit fehlenden Informationen | fester Fehlerpfad | nachfragen, suchen oder eskalieren | mehrere alternative Pfade |
| Wiederholungen | feste Retry-Regel | modellgesteuert mit Limit | dynamisch bis Stop-Bedingung |
| Abschluss | technisch vorgegeben | Ziel + Exit-Kriterien | Modellentscheidung innerhalb harter Limits |
| Externe Aktionen | fest verdrahtet | nur freigegebene Aktionen | kontextabhängige Aktionen mit Guardrails |
| Fehlerbehandlung | definierte Branches | interpretieren und neu planen | alternative Strategie suchen |
Diese Tabelle zeigt auch, warum die Kategorien nicht binär sind. Zwischen starrer Automation und weitreichender Agency existiert ein großes Spektrum sinnvoller Mischformen.
Handlungsspielraum ist die bessere Messgröße als „Autonomie"
Der Begriff Autonomie ist bei KI schnell zu groß. Ein System ist nicht entweder vollständig autonom oder vollständig fremdgesteuert. In der Praxis existiert ein Kontinuum.
Ein Assistent kann nur Vorschläge machen. Ein nächstes System darf aus drei freigegebenen Aktionen wählen. Ein stärker agentisches System kann selbst bestimmen, welche Werkzeuge es nutzt, in welcher Reihenfolge es arbeitet und ob ein Teilproblem erneut bearbeitet werden muss. Ein noch weiterreichendes System kann externe Aktionen auslösen, Daten verändern oder längere Zeit selbstständig weiterarbeiten.
Für Projektdesign ist deshalb der Begriff Handlungsspielraum nützlicher. Er zwingt zu einer konkreten Beschreibung dessen, was das System entscheiden darf. Damit wird aus einer unscharfen Autonomie-Diskussion eine technische und organisatorische Designfrage.
Handlungsspielraum lässt sich mindestens entlang von sechs Dimensionen denken: Sequenzierung – darf das Modell die Reihenfolge der Arbeit bestimmen? Werkzeugwahl – darf es zwischen unterschiedlichen Daten- und Aktionswerkzeugen wählen? Informationsbeschaffung – darf es selbst erkennen, dass Kontext fehlt, und neue Evidenz anfordern? Aufgabenzerlegung – darf es Teilprobleme neu schneiden oder zusätzliche Schritte erzeugen? Fehlererholung – darf es nach Fehlschlägen eine andere Strategie wählen? Und Ausstieg und Eskalation – darf es selbst beenden, stoppen oder einen Menschen einschalten?
Je mehr dieser Dimensionen modellgesteuert werden, desto agentischer wird die Ausführung. Aber nicht jede Dimension muss maximal geöffnet sein.
Zustandsbezug macht Agentik operativ
Ein agentisches System entscheidet nicht im luftleeren Raum. Es braucht einen aktuellen Zustand, gegen den es sein Ziel und seine nächsten Möglichkeiten interpretieren kann.
Der Zustand kann enthalten, welche Aufgaben abgeschlossen sind, welche Daten vorliegen, welche Annahmen gelten, welche Werkzeuge verfügbar sind, welche Aktionen bereits fehlgeschlagen sind, welches Budget verbleibt und welche Entscheidungen noch offen sind. Ohne einen solchen Zustand wird „Autonomie" schnell zu bloßer Textgenerierung mit längerem Prompt.
Gerade dieser Zustandsbezug trennt eine intelligente Einzelfunktion von einem operativen Agenten. Ein Klassifikator kann eine Nachricht sehr gut einordnen. Ein Agent muss zusätzlich verstehen, was diese Einordnung für den weiteren Prozess bedeutet.
Das hat eine wichtige Konsequenz: Agentik ist nicht nur eine Modelleigenschaft. Sie entsteht aus dem Zusammenspiel von Modell, Zustand, Werkzeugen, Rechten, Regeln und Ausstiegsbedingungen.
Nicht jeder variable Workflow ist agentisch
Auch ein klassisches Software-System kann sehr dynamisch wirken. Es kann hunderte Regeln, Event-Handler und Verzweigungen besitzen. Es kann auf unterschiedliche Nutzerrollen, Datenwerte oder Fehlerzustände reagieren. Solange die Entscheidung darüber, welcher Pfad genommen wird, vollständig im Code beschrieben ist, bleibt der Prozess im Kern deterministisch orchestriert.
Umgekehrt kann ein sehr schlicht wirkender Agent echten Handlungsspielraum besitzen. Vielleicht hat er nur drei Werkzeuge. Wenn das Modell aber selbst entscheiden darf, welches davon es wann nutzt, ob es einen Schritt wiederholt, ob zusätzliche Information nötig ist und wann es fertig ist, liegt relevante Prozesskontrolle beim Modell.
Der Unterschied ist also nicht „einfach versus komplex" und auch nicht „regelbasiert versus KI". Der Unterschied lautet vordefinierte Pfadauswahl versus modellgesteuerte Pfadauswahl.
Das Agency Budget: Wie viel Entscheidung braucht die Aufgabe?
Eine hilfreiche Planungsfrage lautet: Wie groß soll das Agency Budget dieses Systems sein? Gemeint ist der bewusst erlaubte Entscheidungsspielraum.
Ein kleines Agency Budget bedeutet, dass das System nur wenige klar abgegrenzte Entscheidungen treffen darf. Es kann beispielsweise zwischen bekannten Werkzeugen wählen, fehlende Informationen erkennen und einen Menschen um Freigabe bitten. Ein großes Agency Budget erlaubt mehr Sequenzierung, mehr Toolnutzung, mehr Wiederholungen und vielleicht auch direkte Veränderungen an externen Systemen.
Das Budget sollte nicht nach technischer Faszination vergeben werden, sondern nach Aufgabenlogik. Je stabiler die Regeln, je höher die Kosten eines Fehlers und je stärker Reproduzierbarkeit verlangt wird, desto kleiner sollte der freie Entscheidungsspielraum häufig sein. Je unstrukturierter die Information, je variabler der Weg zum Ziel und je wichtiger kontextabhängige Abwägungen sind, desto eher kann begrenzte Agentik einen echten Vorteil bringen.
Diese Perspektive macht Agentik planbar. Statt abstrakt über „mehr Autonomie" zu sprechen, kann ein Team festlegen, welche Entscheidungen delegiert werden, welche Werkzeuge erreichbar sind, welche Aktionen reversibel sein müssen und wann zwingend eskaliert wird.
Agentik ist kein Synonym für maximale Freiheit
Ein häufiger Denkfehler lautet: Wenn Agentic AI durch selbstständigere Entscheidungen definiert wird, dann müsse ein besseres Agentensystem möglichst viele Entscheidungen selbst treffen. Das ist falsch.
In professionellen Systemen ist gezielte Begrenzung häufig ein Qualitätsmerkmal. Ein Rechercheagent kann frei in einer freigegebenen Quellenmenge suchen, aber nichts veröffentlichen. Ein Coding-Agent kann Tests ausführen und Dateien in einem isolierten Arbeitsbereich ändern, aber nicht direkt in Produktion deployen. Ein Support-Agent kann einen Lösungsvorschlag formulieren, aber eine große Rückerstattung nur eskalieren.
Die Frage ist nicht, ob das System handeln kann. Die Frage ist, welcher Teil des Handelns für diese Aufgabe sinnvoll delegierbar ist.
Damit wird die Grenze selbst zum Designelement. Ein guter Agent ist nicht derjenige, der alles darf, sondern derjenige, dessen Entscheidungsraum zur Variabilität und zum Risiko der Aufgabe passt.
Der stärkste Entwurf ist häufig hybrid
In realen Projekten ist die beste Architektur oft weder vollständig deterministisch noch maximal agentisch. Die stärksten Systeme kombinieren beide Logiken.
Ein deterministischer Rahmen kann Eingaben validieren, Berechtigungen kontrollieren, sensible Daten filtern, Zeit- und Kostenlimits setzen und definieren, welche Aktionen überhaupt möglich sind. Innerhalb dieses Rahmens kann ein Agent jene Arbeit übernehmen, die Kontextinterpretation und flexible Entscheidungen benötigt.
Man kann sich das als stabile Hülle mit adaptivem Kern vorstellen. Die Hülle hält Sicherheits- und Prozessgrenzen fest. Der Kern entscheidet innerhalb dieser Grenzen, wie das Ziel erreicht wird.
| Aufgabe | Sinnvolle Grundlogik | Begründung |
|---|---|---|
| Datei nach Namensschema ablegen | Automation | Regel vollständig bekannt |
| Recherchefrage aus unvollständigem Material präzisieren | Agentisch | Kontext und fehlende Information müssen interpretiert werden |
| Zahlung über festgelegte Schnittstelle auslösen | Automation + Human Gate | hohe Konsequenz, klarer Prozess |
| mehrere Quellen prüfen und Widersprüche priorisieren | begrenzte Agentik | Weg hängt vom Zwischenstand ab |
| periodischen Statusbericht versenden | Automation | Zeitpunkt und Empfänger sind stabil |
| Projektplan bei neuen Evidenzen neu strukturieren | Agentisch mit Grenzen | Reihenfolge und Fokus können sich ändern |
Diese Hybridarchitektur hat einen weiteren Vorteil: Sie macht Fehlerlokalisierung leichter. Wenn klar ist, welche Teile deterministisch und welche modellgesteuert sind, kann ein Team gezielter untersuchen, ob ein Problem aus Daten, Regeln, Werkzeugen oder agentischen Entscheidungen entstanden ist.
Was deterministisch bleiben sollte
Deterministische Logik ist besonders wertvoll, wenn Regeln vollständig bekannt sind, Ausnahmen begrenzt bleiben oder die Konsequenzen einer Fehlentscheidung hoch sind. Dazu gehören häufig Formatvalidierung, Authentifizierung, Berechtigungsprüfungen, harte Budgetgrenzen, unveränderliche Compliance-Regeln, technische Stopbedingungen und irreversible Aktionen.
Auch hier gilt: Deterministisch bedeutet nicht automatisch „ohne KI". Ein Modell kann Inhalte extrahieren, klassifizieren oder einen Vorschlag erzeugen. Der kritische Übergang kann trotzdem durch Code, Regelwerk oder menschliche Freigabe kontrolliert werden.
Ein gutes System nutzt Modellintelligenz dort, wo Interpretation nötig ist, und Softwaredeterminismus dort, wo Vorhersagbarkeit selbst ein Qualitätskriterium ist.
Wo Agentik echten Mehrwert schafft
Agentik gewinnt an Wert, wenn das Ziel hinreichend klar, der Weg aber nicht vollständig vorab beschreibbar ist. Das ist typisch bei Recherche, Analyse, komplexer Dokumentenarbeit, Ausnahmebehandlung, dynamischer Planung oder Aufgaben, bei denen die nächsten Schritte von Zwischenergebnissen abhängen.
Ein Agent ist dann nicht primär ein schnellerer Automationsbaustein. Er ist eine laufzeitgesteuerte Entscheidungsinstanz innerhalb eines kontrollierten Systems.
Ein besonders guter Kandidat ist ein Prozess, der bisher an einem Regelwerk mit immer mehr Sonderfällen erstickt. Wenn Menschen regelmäßig sagen müssen: „Normalerweise gilt A, außer wenn B und C zusammenkommen, aber dann hängt es noch von D ab", kann modellgestützte Interpretation sinnvoller sein als der hundertste If-Else-Block. Trotzdem sollte das System nicht automatisch jede nachgelagerte Aktion selbst übernehmen.
Die Fähigkeit, eine Entscheidung zu interpretieren, und das Recht, ihre Konsequenz auszulösen, sind zwei verschiedene Ebenen.
Ein Agent braucht Ziel, Zustand, Werkzeuge und Ausstieg
Ein agentisches System wird nicht allein dadurch belastbar, dass man ihm „mehr Freiheit" gibt. Handlungsspielraum ohne Struktur ist keine fortgeschrittene Architektur, sondern nur schlecht begrenzte Unsicherheit.
Vier Elemente sind besonders wichtig. Erstens braucht das System ein Ziel, das konkret genug ist, um Fortschritt beurteilen zu können. Zweitens braucht es einen aktuellen Zustand: Welche Informationen liegen vor, welche Schritte wurden bereits ausgeführt, welche Annahmen gelten noch? Drittens braucht es Werkzeuge mit klar definierten Rechten und Rückgabewerten. Viertens braucht es Exit- und Eskalationsbedingungen.
Gerade der letzte Punkt wird oft unterschätzt. Ein Agent muss erkennen können, wann er fertig ist, wann weitere Schritte keinen Nutzen bringen und wann ein Mensch übernehmen muss. Ein System, das bei Unsicherheit einfach weiterarbeitet, ist nicht besonders autonom; es ist schlecht gesteuert.
Deshalb gehören Retry-Limits, Zeitbudgets, Kostenbudgets, erlaubte Toolklassen, reversible Aktionen und menschliche Freigaben von Anfang an in die Architektur.
Proaktivität verändert den Betriebsmodus
Ein weiterer Unterschied wird sichtbar, wenn Systeme nicht nur auf direkte Nutzeranfragen reagieren, sondern kontinuierlich laufen. Ein Agent kann beispielsweise regelmäßig einen Projektstatus prüfen, Blockaden erkennen und selbst entscheiden, ob eine Recherche, Aktualisierung oder Eskalation notwendig ist.
Damit verändert sich der Betriebsmodus grundlegend. Ein reaktives System handelt nur, wenn es ausgelöst wird. Ein proaktives System kann Zustände interpretieren und selbst Aktionen anstoßen. Das erhöht den Nutzen, aber auch die Anforderungen an Rechteverwaltung, Monitoring und Stop-Mechanismen.
Besonders bei kontinuierlichen Systemen muss deshalb klar sein, welche Zustände eine Aktion auslösen dürfen. Sonst entsteht ein agentisches System, das zwar beschäftigt ist, aber nicht zwingend wertschöpfend arbeitet.
Proaktivität ist damit keine Komfortfunktion. Sie erweitert die Entscheidungsoberfläche des Systems – und muss wie eine zusätzliche Berechtigung behandelt werden.
Handlungsspielraum erzeugt eigene Fehlerklassen
Bei einer Automation entstehen Fehler häufig dort, wo Regeln falsch implementiert, Daten unerwartet oder Integrationen gestört sind. Bei agentischen Systemen kommen weitere Fehlerklassen hinzu.
Ein Agent kann eine Aufgabe falsch zerlegen. Er kann ein plausibles, aber ungeeignetes Werkzeug auswählen. Er kann einen lokalen Zwischenerfolg mit dem Gesamtziel verwechseln. Er kann zu früh aufhören, zu lange iterieren oder einen Fehler mit einer falschen Reparatur verschlimmern. Er kann ein Ergebnis überzeugend begründen, obwohl bereits die gewählte Route problematisch war.
Damit verändert sich auch die Qualitätssicherung. Es reicht nicht mehr, nur das Endergebnis anzusehen. Man muss zusätzlich prüfen, ob relevante Entscheidungen auf zulässigen und sinnvollen Wegen zustande kamen.
Das bedeutet nicht, jede interne Modellrepräsentation rekonstruieren zu müssen. Es bedeutet, die operativ wichtigen Entscheidungen sichtbar zu machen: Toolaufrufe, Zustandswechsel, Eskalationen, abgebrochene Versuche, verwendete Evidenz und ausgeführte Aktionen.
Testen heißt bei Agenten: Pfade und Grenzen prüfen
Eine deterministische Automation lässt sich häufig mit festen Eingaben und erwarteten Ausgaben testen. Agentische Systeme benötigen zusätzlich Verhaltens- und Pfadtests.
Ein guter Testkatalog umfasst nicht nur den Normalfall. Er sollte auch prüfen, was geschieht, wenn eine Quelle fehlt, zwei Quellen widersprechen, ein Werkzeug nicht verfügbar ist, ein Budget fast ausgeschöpft ist, eine Aktion nicht reversibel wäre oder das Ziel mehrdeutig wird.
| Testtyp | Kernfrage |
|---|---|
| Normalfall | Erreicht das System das Ziel mit zulässigen Mitteln? |
| Informationslücke | Erkennt es fehlende Evidenz oder erfindet es eine Abkürzung? |
| Toolfehler | Wählt es eine sichere Alternative oder gerät es in eine Schleife? |
| Zielkonflikt | Macht es den Konflikt sichtbar oder optimiert es still auf ein Teilziel? |
| Risikofall | Stoppt bzw. eskaliert es vor einer nicht erlaubten Aktion? |
| Budgetfall | Beendet es sinnvoll, wenn Zeit-, Kosten- oder Retry-Grenzen erreicht sind? |
| Revisionsfall | Kann es nach Feedback neu planen, ohne alte Fehler unsichtbar fortzuschreiben? |
Agentenqualität ist damit nicht nur Outputqualität. Sie umfasst Entscheidungsqualität, Grenztreue und Erholungsfähigkeit.
Die Decision Surface Map macht Agentik prüfbar
Für die Planung kann es hilfreich sein, den Handlungsspielraum nicht nur als abstraktes Budget, sondern als Decision Surface Map zu dokumentieren. Sie beschreibt für jede relevante Entscheidung, wer sie treffen darf, welche Informationen dafür verfügbar sein müssen, welche Auswirkungen die Entscheidung hat und wie sie rückgängig gemacht oder eskaliert werden kann.
| Entscheidung | Deterministisch? | Agent darf entscheiden? | Menschliche Freigabe? | Rückrollbar? |
|---|---|---|---|---|
| Quelle auswählen | teilweise | ja, aus Allowlist | nur bei sensiblen Quellen | ja |
| Suchstrategie ändern | nein | ja | nein | ja |
| Datei löschen | nein | nein | ja | begrenzt |
| Projektpriorität ändern | teilweise | Empfehlung | ja | ja |
| externe Nachricht senden | teilweise | Entwurf | abhängig vom Risiko | begrenzt |
| Lauf abbrechen | ja | ja | nein | nicht nötig |
Diese Karte verändert die Diskussion im Team. Statt darüber zu streiten, ob ein System „autonom genug" oder „zu autonom" sei, wird konkret sichtbar, welche Entscheidungen modellgesteuert sind. Genau dort lassen sich Tests, Guardrails und Freigaben platzieren.
Reversibilität ist eine unterschätzte Autonomiegrenze
Nicht jede Entscheidung braucht denselben Kontrollaufwand. Eine falsche Suchanfrage kann wiederholt werden. Eine versehentlich veröffentlichte Nachricht, gelöschte Datei oder ausgelöste Zahlung kann deutlich schwerer rückgängig zu machen sein.
Deshalb sollte Handlungsspielraum auch nach Reversibilität kalibriert werden. Read-only-Recherche kann häufig großzügiger delegiert werden als schreibende Aktionen. Entwürfe können autonom erzeugt werden, während Veröffentlichung reserviert bleibt. Änderungen in einer isolierten Sandbox sind leichter vertretbar als direkte Änderungen in einem Produktivsystem.
Diese Trennung reduziert nicht nur Risiko. Sie erlaubt häufig sogar mehr Agentik in den ungefährlichen Bereichen, weil die Konsequenzen kontrolliert bleiben.
Kosten, Latenz und Varianz sind Teil des Designs
Agentische Systeme können mehr leisten, weil sie zusätzliche Schritte planen, Werkzeuge ausprobieren, Ergebnisse bewerten und gegebenenfalls wiederholen. Genau diese Mechanismen erzeugen aber zusätzliche Kosten und Latenz.
Auch die Varianz nimmt zu. Ein deterministischer Ablauf versucht, denselben Pfad reproduzierbar auszuführen. Ein Agent kann unter ähnlichen Bedingungen unterschiedliche, aber zulässige Wege wählen. Das kann erwünscht sein – etwa bei Recherche – erschwert jedoch Planung, Test und Kapazitätssteuerung.
Anthropic empfiehlt deshalb ausdrücklich, mit der einfachsten tragfähigen Architektur zu beginnen.[1] OpenAI formuliert ähnlich, dass ein deterministischer Ansatz ausreichen kann, wenn der Use Case keine modellgesteuerte Entscheidungslogik benötigt.[2]
Die professionelle Frage lautet also nicht: „Wie viel Agentik können wir einbauen?" Sondern: „Welcher zusätzliche Entscheidungsspielraum rechtfertigt seinen zusätzlichen Preis?"
Beobachtbarkeit wird mit Handlungsspielraum wichtiger
Je mehr ein System selbst entscheiden darf, desto wichtiger wird nachvollziehbar, welchen operativen Weg es gewählt hat. Bei deterministischen Abläufen ist der Pfad meist aus dem Code ableitbar. Bei agentischen Abläufen entstehen Entscheidungen zur Laufzeit.
Deshalb müssen Agenten nicht nur Ergebnisse liefern. Für produktive Nutzung brauchen sie genügend Telemetrie, um wichtige Zustandswechsel, Toolaufrufe, Fehler, Eskalationen und Abbruchgründe nachvollziehbar zu machen. Das bedeutet nicht, jede interne Modellrepräsentation offenzulegen. Es bedeutet, den operativen Prozess prüfbar zu gestalten.
Ein guter Agent hinterlässt deshalb nicht nur Output, sondern eine verständliche Spur seiner relevanten Aktionen und Zustandsänderungen.
Ein Beispiel: derselbe Prozess, drei Architekturen
Nehmen wir ein Projektteam, das regelmäßig neue Kundenanforderungen aus E-Mails, Gesprächsnotizen und Dokumenten in den Projektstand überführen muss.
In einer reinen Automation erkennt ein Eingangstrigger neue Dateien, legt sie nach Regeln ab, extrahiert Metadaten und erzeugt eine Benachrichtigung. Der Ablauf ist stabil, aber er versteht nicht, ob eine neue Anforderung nur eine Rückfrage, ein echter Scope-Wechsel oder ein widersprüchlicher Wunsch ist.
In einer hybriden Variante bleibt der technische Eingang automatisiert. Erst wenn ein neues Dokument vollständig gespeichert und klassifiziert wurde, übernimmt ein Agent die inhaltliche Interpretation. Er vergleicht die Anforderung mit dem aktuellen Scope, sucht nach Widersprüchen und erstellt eine begründete Empfehlung. Eine Änderung am verbindlichen Projektplan darf er jedoch nicht selbst freigeben. Dafür erzeugt er einen strukturierten Change-Vorschlag und eskaliert an eine verantwortliche Person.
In einer weitreichenderen agentischen Variante könnte dasselbe System zusätzlich Rückfragen formulieren, Quellen nachrecherchieren, Alternativen bewerten, Aufgaben neu priorisieren und Teile des Plans selbst aktualisieren. Das kann leistungsfähig sein, vergrößert aber die zu prüfende Entscheidungsfläche erheblich. Plötzlich muss nicht nur die Textqualität bewertet werden, sondern auch, ob das System die richtige Quelle gewählt, die richtige Annahme verworfen, die richtige Aufgabe verschoben und die richtige Aktion ausgelöst hat.
Der Unterschied zwischen den drei Varianten liegt also nicht primär im verwendeten Modell. Er liegt darin, wo die Entscheidungsgrenze verläuft.
Fünf Anti-Patterns, die Agentik nur imitieren
1. Der Cronjob mit Chatbot-Label
Ein zeitgesteuerter Ablauf, der immer dieselbe Promptkette abarbeitet, bleibt Automation – selbst wenn das Ergebnis sprachlich intelligent wirkt.
2. Der hundertzeilige „autonome" Schritt-für-Schritt-Prompt
Wenn der komplette Ablauf detailliert vorgeschrieben ist, hat das Modell kaum Prozesskontrolle. Das kann ein guter Workflow sein, aber die Architektur ist nicht dadurch agentischer, dass das Wort Agent darübersteht.
3. Der Agent für jeden Handgriff
Wenn eine bekannte Regel zuverlässig in Code ausgedrückt werden kann, erhöht ein Agent häufig nur Kosten, Varianz und Wartungsaufwand.
4. Der Agent ohne Stop-Bedingung
Ein System, das „weiterarbeiten" darf, bis es sich selbst zufriedenstellt, besitzt keinen belastbaren Handlungsspielraum, sondern ein offenes Schleifenrisiko.
5. Das Human Gate auf dem Papier
Eine angebliche menschliche Freigabe schützt nur dann, wenn die technische Architektur die Aktion tatsächlich blockiert, bis die Freigabe vorliegt. Eine Anweisung wie „frage vorher nach" ist kein gleichwertiger Ersatz für ein wirksames Gate.
Diese Anti-Patterns zeigen: Agentik ist kein Etikett, sondern eine überprüfbare Verteilung von Prozesskontrolle.
Der Handlungsspielraum-Canvas
Vor dem Bau eines agentischen Systems reichen sieben Fragen, um die Architektur deutlich klarer zu machen:
| Frage | Designentscheidung |
|---|---|
| Welches Ziel soll erreicht werden? | Ziel- und Erfolgskriterium |
| Welche Teile des Weges sind bereits sicher bekannt? | deterministische Prozessanteile |
| Welche Entscheidungen hängen vom Zwischenzustand ab? | agentische Entscheidungsfläche |
| Welche Werkzeuge darf das System lesen bzw. verändern? | Tool- und Berechtigungsgrenzen |
| Welche Aktionen sind schwer reversibel? | Freigabe- und Isolationsbedarf |
| Wann muss das System stoppen oder eskalieren? | Exit- und Human-Intervention |
| Welche Aktionen und Zustandswechsel müssen sichtbar bleiben? | Observability- und Nachweisanforderungen |
Wer diese sieben Fragen beantworten kann, hat bereits mehr Agentenarchitektur entworfen als mit einem langen Persona-Prompt.
Ein Agent muss nicht sichtbar wie ein Agent aussehen
Agentik wird häufig über Benutzeroberflächen beurteilt. Ein System zeigt eine Fortschrittsliste, mehrere „Gedankenschritte", Werkzeugaufrufe oder einen animierten Arbeitsmodus und wirkt dadurch autonom. Umgekehrt kann ein agentischer Prozess völlig unsichtbar im Hintergrund laufen und nur einen strukturierten Output zurückgeben.
Für die Architektur ist die Oberfläche irrelevant. Entscheidend ist, ob das Modell tatsächlich operative Wahlmöglichkeiten besitzt. Darf es eine Aktion überspringen? Darf es zusätzliche Evidenz beschaffen? Darf es zwischen Werkzeugen wählen? Darf es seinen Plan nach einem Zwischenergebnis ändern? Darf es eine Aufgabe als nicht lösbar markieren?
Diese Perspektive verhindert eine weitere Form von Agenten-Marketing: sichtbare Aktivität wird mit Agency verwechselt. Ein Fortschrittsbalken beweist keine Entscheidungsfreiheit. Genauso wenig beweist eine stille Hintergrundausführung, dass der Prozess deterministisch ist.
Die richtige Bewertung beginnt deshalb immer unterhalb der Oberfläche bei der Frage, welche Zustandsübergänge durch Code und welche durch das Modell bestimmt werden.
Rechte sollten feiner sein als die Fähigkeiten des Modells
Ein leistungsfähiges Modell kann sehr viel mehr, als es in einem konkreten Prozess tun sollte. Genau deshalb darf das technische Rechtemodell nicht einfach den Fähigkeiten des Modells folgen.
Ein Agent kann möglicherweise recherchieren, Code ausführen, Dateien verändern, Nachrichten senden und externe Systeme bedienen. Aus der Tatsache, dass er diese Dinge kann, folgt aber nicht, dass eine einzelne Rolle sie alle dürfen sollte. Professionelle Agentik trennt Capability und Authority.
Capability beschreibt, was das System technisch leisten könnte. Authority beschreibt, was es im aktuellen Prozess tatsächlich ausführen darf. Dazwischen liegen Policies, Toolfreigaben, Datenzonen, Schreibrechte und menschliche Entscheidungen.
Diese Trennung ist besonders wichtig, wenn ein System mehrere Aufgabenarten übernimmt. Ein Recherchemodus kann breiten Lesezugriff benötigen, aber keinen Schreibzugriff. Ein Dateibearbeitungsmodus braucht Schreibrechte in einem Arbeitsverzeichnis, aber nicht zwangsläufig Zugriff auf Kommunikation oder Zahlungssysteme. Ein Agent kann einen riskanten Schritt fachlich empfehlen, ohne die Berechtigung zu besitzen, ihn selbst auszuführen.
Je präziser diese Rechte zugeschnitten sind, desto leichter lässt sich Handlungsspielraum öffnen, ohne den gesamten Wirkungsradius des Modells freizugeben.
Der Übergang von Vorschlag zu Wirkung ist die kritische Schwelle
Viele Diskussionen über Agentic AI konzentrieren sich auf Denken, Planen und Toolnutzung. Für die Praxis ist jedoch eine andere Grenze oft noch wichtiger: Wann verändert ein Modell die Außenwelt?
Ein System, das eine Prioritätsänderung nur vorschlägt, hat einen anderen Risikotyp als ein System, das den Projektplan tatsächlich umschreibt. Ein Agent, der eine E-Mail entwirft, ist anders zu bewerten als einer, der sie versendet. Eine Analyse eines Datenbestands ist weniger invasiv als eine selbstständige Löschung oder Migration.
Damit entsteht eine sinnvolle Trennung zwischen drei Wirkungsstufen:
| Wirkungsstufe | Beispiel | Typische Kontrolle |
|---|---|---|
| Beobachten | lesen, suchen, analysieren | Zugriff und Quellenregeln |
| Vorschlagen | Plan, Entwurf, Änderungsempfehlung | Review und Akzeptanzkriterien |
| Verändern | schreiben, senden, löschen, auslösen | harte Rechte, Reversibilität, Gate |
Diese Stufen sind kein allgemeingültiges Sicherheitsmodell, aber ein hilfreiches Architekturprinzip. Oft kann ein System sehr agentisch beobachten und vorschlagen, während das tatsächliche Verändern stärker begrenzt bleibt.
Agentische Systeme brauchen ein Ende, nicht nur ein Ziel
Ein Ziel beantwortet, wohin gearbeitet werden soll. Es beantwortet noch nicht zuverlässig, wann genug gearbeitet wurde.
Gerade offene Aufgaben können theoretisch immer weiter verbessert werden. Eine Recherche kann noch eine Quelle finden, ein Text noch eine Überarbeitung bekommen, ein Code-Agent noch eine Optimierung versuchen. Ohne explizite Beendigungslogik verwandelt sich Zielorientierung schnell in unkontrollierte Iteration.
Deshalb sollte ein agentischer Lauf neben Erfolgskriterien auch Abbruchkriterien besitzen: maximal zulässige Iterationen, ausreichend erreichte Evidenz, kein sinnvoller Fortschritt über mehrere Schritte, ausgeschöpftes Kostenbudget, wiederholter Toolfehler oder eine Unsicherheit, die nur durch menschliche Entscheidung auflösbar ist.
Ein reifes System kann damit nicht nur sagen: „Ich habe das Ziel erreicht." Es kann ebenso sagen: „Unter den erlaubten Bedingungen kann ich nicht sinnvoll weiterarbeiten." Diese Fähigkeit ist kein Scheitern, sondern ein wesentliches Merkmal kontrollierter Agency.
Die eigentliche Designregel: so wenig Freiheit wie möglich, so viel wie nötig
Die spannendste Agentenarchitektur ist nicht diejenige mit dem größten Handlungsspielraum. Es ist diejenige, deren Handlungsspielraum passend begrenzt ist.
Ein System sollte frei genug sein, um die Variabilität des Problems sinnvoll zu bearbeiten, aber nicht freier als nötig. Es sollte selbst entscheiden dürfen, wo starre Regeln unpraktisch werden, und deterministisch bleiben, wo Vorhersagbarkeit, Kostenkontrolle, Sicherheit oder klare Verantwortung wichtiger sind.
Damit wird Agentic AI zu einer Projektarchitektur statt zu einem Modewort. Automation definiert verlässliche Wege. Agentik öffnet begrenzte Entscheidungsräume. Gute Systeme kombinieren beides bewusst.
Die entscheidende Reife zeigt sich deshalb nicht daran, wie autonom eine KI wirkt. Sie zeigt sich daran, ob ihr Handlungsspielraum begründet, beobachtbar, testbar, rückholbar und jederzeit begrenzbar ist.
Der nächste Schritt ist dann nicht, noch mehr Autonomie hinzuzufügen. Er besteht darin, diesen Handlungsspielraum in klare Rollen zu übersetzen: Wer orchestriert? Wer arbeitet spezialisiert? Wer prüft? Wer dokumentiert? Und welche Entscheidungen bleiben beim Menschen?
Öffentliche Quellen zur Vertiefung
0 Kommentare
● Kommentare werden geladen…