Agentische KI erklärt: Wenn ein KI-System planen, Werkzeuge nutzen und handeln kann

Agentische KI ist ein KI-System, in dem ein Modell ein Ziel über mehrere Schritte hinweg verfolgen kann, indem es entscheidet, was als Nächstes zu tun ist, Werkzeuge oder andere Fähigkeiten nutzt, die Ergebnisse beobachtet, seinen Arbeitszustand aktualisiert und fortfährt, bis es eine Abbruchbedingung erreicht. Das Modell allein ist nicht der Agent. Ein nutzbarer Agent benötigt außerdem eine Laufzeitumgebung oder ein Harness, das Kontext, Werkzeugausführung, Zustand, Berechtigungen, Genehmigungen, Fehler und die Schleife zwischen Entscheidungen und Beobachtungen verwaltet.

Was agentische KI wirklich bedeutet

Der wichtige Wandel von gewöhnlicher generativer KI zu agentischer KI ist die Kontrolle über den Prozess. Ein normaler Assistent kann eine Frage mit dem ihm übergebenen Kontext beantworten. Ein Agent kann entscheiden, dass die Beantwortung zusätzliche Schritte erfordert: eine Datei prüfen, ein Repository durchsuchen, eine API abfragen, um Klärung bitten, einen Test ausführen, ein Ticket aktualisieren, eine Teilaufgabe delegieren oder nach einer fehlgeschlagenen Aktion erneut versuchen.

Dies erfordert keine unbegrenzte Autonomie. Ein Agent kann in einer engen Sandbox, unter strengen Berechtigungen und mit erforderlicher Genehmigung vor jeder folgenreichen Aktion arbeiten. Das System ist weiterhin agentisch, wenn das Modell dynamisch unter erlaubten nächsten Schritten wählt.

Die Architektur ist daher wichtiger als das Etikett. „Agent“ sollte ein Systemverhalten beschreiben: iterative, modellgesteuerte Entscheidungsfindung über Werkzeuge, Zustand und Rückmeldung — nicht bloß einen Chatbot mit einem größeren Prompt.

Das einfachste Beispiel

Angenommen, ein Entwickler fragt ein KI-System: „Finde heraus, warum die Testsuite fehlschlägt, und behebe den Fehler.“ Ein einzelner Modellaufruf könnte nur wahrscheinliche Ursachen aus dem ihm gegebenen Text vorschlagen.

Ein agentisches Codierungssystem kann das Repository prüfen, nach dem fehlschlagenden Test suchen, relevante Dateien lesen, eine Änderung vorschlagen, den Code bearbeiten, den Test ausführen, den Fehler beobachten, die Implementierung überarbeiten und den Test erneut ausführen.

Der agentische Teil besteht nicht einfach darin, dass Shell- und Dateiwerkzeuge existieren. Er besteht darin, dass das Modell Umgebungsrückmeldungen nutzen kann, um den nächsten Schritt zu wählen, anstatt einer vollständig vordefinierten Sequenz zu folgen.

Wo das einfache Beispiel endet

Nicht jedes mehrstufige KI-System ist gleichermaßen agentisch. Ein Workflow kann mehrere LLM-Aufrufe und Werkzeuge verwenden, während jeder Schritt im Code vorbestimmt ist. Ein anderes System kann das Modell entscheiden lassen, welches Werkzeug in welcher Reihenfolge, wie oft und wann es stoppen soll.

Beides kann nützlich sein. Der Unterschied liegt darin, wo die Kontrolle liegt. Vordefinierte Workflows verlagern mehr Kontrolle in den Anwendungscode. Agenten verlagern mehr taktische Prozessentscheidungen in die Modell-/Laufzeitschleife.

Agent vs. Workflow

Anthropic trennt diese beiden Muster ausdrücklich: Workflows orchestrieren Modelle und Werkzeuge über vordefinierte Codepfade, während Agenten Modelle ihre eigenen Prozesse und Werkzeugnutzung dynamisch steuern lassen. Dies ist nicht die einzig mögliche Terminologie, aber es ist eine nützliche Architekturgrenze.

Agentisches Verhalten ist ein Spektrum, keine binäre Bezeichnung

Jedes der oben genannten Systeme als „Agent“ zu bezeichnen, kann wichtige betriebliche Unterschiede verschleiern. Je stärker die Kontrolle des Modells über Reihenfolge, Dauer und Aktionen ist, desto wichtiger werden Laufzeitisolierung, Berechtigungen, Nachverfolgung, Abbruchbedingungen und Trajektorienbewertung.

Die minimale Architektur eines agentischen Systems

Ein Modell ist kein Agent

Ein Sprachmodell erzeugt Ausgaben aus Eingaben. Es besitzt nicht von sich aus ein Dateisystem, führt keinen Shell-Befehl aus, pflegt keinen dauerhaften Aufgabenstatus, erzwingt keine Berechtigungen und ruft sich nicht automatisch erneut auf.

Diese Fähigkeiten stammen aus der umgebenden Laufzeit. Dasselbe Modell kann sich in einer Anwendung wie ein einfaches Chat-Modell verhalten und in einer anderen als Entscheidungsengine innerhalb einer Agentenschleife.

Werkzeugnutzung ist zentral – aber Werkzeugnutzung allein macht noch keinen Agenten

Werkzeuge ermöglichen es dem Modell, Informationen zu erlangen und externe Systeme zu beeinflussen. Beispiele sind Datenbanklesevorgänge, Dateioperationen, Shell-Ausführung, Websuche, Browsersteuerung, API-Aufrufe, Ticket-Aktualisierungen oder delegierte Spezialagenten.

Ein einzelner Modellaufruf kann ein Werkzeug verwenden und bleibt dennoch eine begrenzte werkzeugunterstützte Antwort statt eines lang laufenden Agenten. Agentisches Verhalten entsteht, wenn Werkzeugbeobachtungen eine adaptive Schleife speisen, in der das Modell wählt, was als Nächstes zu tun ist.

Das Werkzeugdesign ist wichtig, weil Werkzeuge der Vertrag zwischen Modellschlussfolgerung und externer Realität sind. Mehrdeutige oder überlappende Werkzeuge erzeugen Routingfehler; große unstrukturierte Ausgaben verschmutzen den Kontext; breite Werkzeuge mit Nebenwirkungen vergrößern den Wirkungsradius.

Werkzeugfähigkeit, Berechtigung und Befugnis sind unterschiedlich

Diese Schichten werden in Prototypen häufig zusammengefasst. Ein Modell sieht ein Rückerstattungswerkzeug und scheint daher in der Lage zu sein, Rückerstattungen auszugeben. In der Produktion sollte das Werkzeug dennoch Konto, Benutzer, Transaktion, Betrag, Richtlinie und Genehmigungsbedingungen unabhängig von der Anfrage des Modells validieren.

Die Laufzeitumgebung oder das Harness ist das eigentliche Ausführungssystem

Die aktuelle Agentendokumentation von OpenAI macht die Unterscheidung der Laufzeitumgebung explizit. Verschiedene Laufzeitumgebungen können Orchestrierung, Zustand, Tools, Sandboxes und Ausführung an unterschiedlichen Stellen verwalten, während das Modell nur ein Teil des Systems bleibt.

Das Agents SDK beschreibt eine Schleife, die wiederholt das aktuelle Modell aufruft, die Ausgabe prüft, angeforderte Tools oder Übergaben ausführt und fortfährt, bis das Modell eine endgültige Antwort oder einen anderen echten Haltepunkt zurückgibt.

Das bedeutet, dass Architekturentscheidungen für Agenten auch umfassen, wo die Orchestrierung läuft, wo der Zustand lebt, wer Tools ausführt, welche Sandbox Seiteneffekte enthält und wer Wiederholungen, Timeouts und Wiederaufnahmefähigkeit verantwortet.

Planung ist nützlich, aber ein expliziter Plan ist nicht erforderlich

Agenten werden oft als Systeme beschrieben, die „planen“. In der Praxis kann Planung explizit oder implizit sein. Ein Agent kann zuerst einen sichtbaren mehrstufigen Plan erstellen oder jeweils eine nächste Aktion wählen und nach jeder Beobachtung überarbeiten.

Bei hochgradig unsicheren Aufgaben kann kurzfristige Planung sicherer sein, weil die Umgebung einen langen Plan ungültig machen kann. Die architektonische Anforderung ist die Fähigkeit, Aktionen basierend auf dem Ziel, dem aktuellen Zustand und neuen Erkenntnissen auszuwählen und zu überarbeiten.

Umgebungsfeedback macht die Schleife nützlich

Ein Agent wird operativ bedeutsam, wenn er beobachten kann, ob seine Aktion funktioniert hat. Tool-Ausgaben, Testergebnisse, API-Antworten, Dateisystemzustand, Browserzustand und Anwendungsdatensätze liefern externe Belege, die das System zur Überarbeitung seiner nächsten Entscheidung nutzen kann.

Die Agentenrichtlinien von Anthropic betonen diese Feedbackschleife: Agenten nutzen Tools, erhalten Ground Truth aus der Umgebung, bewerten den Fortschritt und fahren fort oder fordern menschliche Eingaben an.

Der Agentenzustand ist nicht dasselbe wie der Modellkontext

Eine lang laufende Aufgabe kann einen Zustand benötigen, der nicht im Modellkontext bleiben kann oder sollte: Aufgaben-IDs, Checkpoints, Artefakte, Genehmigungen, externe Objektkennungen, Wiederholungszähler und Workflow-Status.

Die Laufzeitumgebung kann diesen dauerhaften Zustand außerhalb des Modellfensters bewahren und den für den nächsten Schritt erforderlichen Kontext rekonstruieren. Dadurch bleibt der für das Modell sichtbare Kontext fokussiert, während Kontinuität und Wiederaufnahmefähigkeit erhalten bleiben.

Speicher ist optional, nicht die Definition eines Agenten

Ein Agent kann erfolgreich ohne Langzeitspeicher arbeiten, wenn die vollständige Aufgabe in einen begrenzten Lauf passt. Speicher wird nützlich, wenn Informationen über Sitzungen, Aufgaben oder lange Ausführungshorizonte hinweg bestehen bleiben müssen.

RAG, Speicher, Zustand und Kontext lösen unterschiedliche Probleme. Eine Vektordatenbank als „den Agentenspeicher“ oder den Gesprächsverlauf als „die Zustandsmaschine“ zu behandeln, verbirgt normalerweise wichtige Lebenszyklus- und Autoritätsgrenzen.

Context Engineering wird in Agenten dynamisch

Jeder Tool-Aufruf kann neuen Kontext erzeugen. Jeder Schritt kann auch frühere Informationen obsolet machen. Eine leistungsfähige Agenten-Laufzeitumgebung baut daher den Kontext während der Ausführung neu auf oder kuratiert ihn, anstatt alles endlos wiederzugeben.

Tool-Definitionen, Aufgabenstatus, abgerufene Belege, Beobachtungen und Gedächtnis konkurrieren alle um die Aufmerksamkeit des Modells. Lang laufende Agenten benötigen Kürzung, Kompaktierung oder Just-in-Time-Laden, damit der Kontext für die aktuelle Entscheidung relevant bleibt.

Lesetools und Seiteneffekt-Tools haben unterschiedliche Risiken

Human-in-the-Loop ist ein Kontrollmechanismus, nicht das Gegenteil von agentischer KI

Ein Agent hört nicht auf, agentisch zu sein, nur weil ein Mensch folgenreiche Schritte genehmigt. Das Modell kann weiterhin autonom prüfen, schlussfolgern, suchen und eine Aktion vorbereiten, während die Laufzeitumgebung vor der Ausführung eine menschliche Bestätigung verlangt.

OpenAIs aktuelle Sicherheitsrichtlinien für Agenten empfehlen ausdrücklich Genehmigungen für Tool-Operationen in risikoreicheren Arbeitsabläufen. Anthropic betont ebenfalls Checkpoints und menschliches Urteilsvermögen, wenn Agenten auf Hindernisse oder folgenreiche Entscheidungen stoßen.

Die nützliche Architekturfrage ist nicht „Mensch oder autonom?“, sondern welche Entscheidungen delegiert werden können, welche überprüft werden müssen und welche deterministisch bleiben müssen?

Agenten benötigen explizite Abbruchbedingungen

Wiederherstellung ist Teil des Agentenverhaltens

Agenten arbeiten in Umgebungen, die fehlschlagen: APIs laufen in Timeouts, Dateien ändern sich, Anmeldedaten laufen ab, Webseiten verschieben sich und Tools liefern fehlerhafte Ausgaben. Ein nützliches agentisches System benötigt daher Wiederherstellungsverhalten, nicht nur eine Tool-Schleife für den Idealfall.

Wiederherstellung kann Wiederholungsversuche mit Grenzen, die Wahl eines anderen Tools, erneutes Lesen des aktuellen Zustands, Nachfragen beim Benutzer, Zurückrollen einer teilweisen Aktion oder Eskalation an einen Menschen umfassen.

Wiederholungsversuche erfordern auch Idempotenz-Bewusstsein. Das Wiederholen eines Lesevorgangs ist normalerweise risikoarm; das Wiederholen einer Zahlung oder das erneute Senden einer Nachricht kann doppelte Seiteneffekte erzeugen.

Agentische KI erfordert nicht mehrere Agenten

Ein einzelner Agent mit einem klaren Tool-Set ist oft einfacher und leichter zu bewerten als eine Multi-Agenten-Architektur. Mehrere Agenten sind nützlich, wenn Spezialisierung die Tool-Isolation, Richtlinien-Isolation, Prompt-Klarheit, Verantwortlichkeit oder Trace-Lesbarkeit wesentlich verbessert.

OpenAIs aktuelle Orchestrierungsrichtlinien empfehlen ausdrücklich, wo möglich mit einem Agenten zu beginnen und Spezialisten nur dann hinzuzufügen, wenn sich der Vertrag oder die Verantwortlichkeitsgrenze wesentlich ändert.

Multi-Agenten-Systeme bringen neue Probleme mit sich: Delegationsqualität, duplizierter Kontext, widersprüchlicher Zustand, Übergabesemantik, Identität, Kosten und verteilte Fehlerbehandlung.

Agentenprotokolle sind Interoperabilitätsschichten, nicht der Agent selbst

Protokolle wie MCP und A2A können eine Agentenarchitektur interoperabel machen, aber sie erzeugen nicht selbst die Agentenschleife. MCP kann Werkzeuge und Ressourcen bereitstellen. A2A kann unabhängig implementierte Agenten verbinden. Die Anwendung benötigt weiterhin Laufzeit, Autorisierung, Zustand, Evaluierung und Domänenlogik.

Deshalb muss die Protokollfähigkeit von der Geschäftsbefugnis getrennt bleiben. Die Entdeckung eines Werkzeugs über MCP beweist nicht, dass der aktuelle Prinzipal es verwenden darf. Der Empfang einer Aufgabe über A2A beweist nicht, dass der entfernte Agent jede angeforderte Aktion ausführen darf.

Die Trajektorie ist Teil der Agentenzuverlässigkeit

Eine endgültige Antwort ist kein ausreichender Beweis für ein agentisches System, da ein Agent das richtige Ergebnis über einen unsicheren oder ungültigen Pfad erreichen kann. Er kann ein nicht autorisiertes Werkzeug verwenden, eine erforderliche Prüfung überspringen, einen Seiteneffekt wiederholen, sich auf veralteten Zustand verlassen oder versehentlich erfolgreich sein.

Die Evaluierung benötigt daher Ausführungsverfolgungen: Entscheidungen, Werkzeugaufrufe, Genehmigungen, Beobachtungen, Zustandsänderungen und Endergebnis. Die aktuelle OpenAI-Sicherheitsrichtlinie empfiehlt Trace-Grader und Evals; die Anthropic-Agenten-Evaluierungsrichtlinie von 2026 behandelt mehrstufige Werkzeugtrajektorien ebenfalls als erstklassige Evaluierungsobjekte.

Die stärkere Zuverlässigkeitsfrage lautet: Hat der Agent ein akzeptables Ergebnis über eine akzeptable, wiederherstellbare und prüfbare Trajektorie erreicht?

Agentische Systeme vergrößern die Sicherheitsoberfläche

Agentenbeobachtbarkeit muss der Schleife folgen

Traditionelle Dienstbeobachtbarkeit zeichnet Anfragen, Latenz und Fehler auf. Agentenbeobachtbarkeit benötigt ein zusätzliches Ausführungsmodell: welcher Agent aktiv war, welche Modellversion die Entscheidung getroffen hat, welcher Kontext verfügbar war, welches Werkzeug ausgewählt wurde, welche Argumente gesendet wurden, welches Ergebnis zurückkam und warum die Ausführung gestoppt wurde.

Für sensible Systeme benötigen die Traces selbst Zugriffskontrolle und Aufbewahrungsrichtlinien, da Prompts, Werkzeugausgaben und Artefakte vertrauliche Daten enthalten können.

Wie man ein agentisches System evaluiert

Wann ein Agent angemessen ist

Eine gute Standardeinstellung ist, mit der einfachsten funktionierenden Lösung zu beginnen und die agentische Komplexität nur dann zu erhöhen, wenn Flexibilität einen messbaren Mehrwert bringt. Agenten tauschen Vorhersagbarkeit, Latenz und Kosten gegen adaptive Ausführung.

Belege aus der ursprünglichen Implementierung

Aaasaasa AI Client: Modell, Laufzeitumgebung und Berechtigung sind getrennt

Der Aaasaasa AI Client trennt ausdrücklich Agent/Client, Anbieter, Modell, Laufzeitumgebung und Berechtigungen. Seine Architekturdokumentation behandelt Berechtigungen als zentrale Tool-/Workspace-Richtlinie und nicht als Modelleigenschaft.

Dieselbe Anwendung kann einen Direct Chat ohne Dateisystem- oder Shell-Tools bereitstellen, während eine Codex-Laufzeitumgebung unter einem ausgewählten Workspace- und Berechtigungsprofil arbeitet. Dies zeigt eine zentrale agentische Architekturgrenze: Eine Änderung der Laufzeitumgebung/Tool-Oberfläche ändert, was das System tun kann, selbst wenn der Modellzugriff verfügbar bleibt.

Das Repository unterscheidet außerdem eine lokale Codex-Laufzeitumgebung vom Modellstandort: Eine lokale Laufzeitumgebung kann ein Cloud-Modell aufrufen. Dies verhindert den häufigen Fehler, „Agent läuft lokal“ mit „Inferenz ist lokal“ gleichzusetzen.

Die Implementierung deaktiviert eingebettete Ausführungspfade, deren Genehmigungssemantik das erforderliche Berechtigungsmodell nicht erfüllt. Dies unterstützt das Prinzip, dass Agentenfähigkeiten die Laufzeitautorisierung nicht allein deshalb umgehen sollten, weil ein zugrunde liegendes Framework Tools ausführen kann.

Source of Truth Research Engine: begrenzte agentische Recherchephasen

Die Source of Truth Research Engine verwendet eine begrenzte Recherche-Pipeline: entdecken → beschaffen → extrahieren → verifizieren → widersprechen → synthetisieren. Rechercheaufträge können über eine KI-Laufzeitumgebung ausgeführt werden, während Belege, Quellen, Aussagen und Widersprüche in einem externen persistenten Speicher verbleiben.

Dies ist absichtlich kontrollierter als ein uneingeschränkter autonomer Rechercheagent. Die Phasen bieten Leitplanken dafür, welche Art von Arbeit als Nächstes erfolgen sollte, während sie innerhalb jeder begrenzten Aufgabe weiterhin modellgesteuerte Recherche ermöglichen.

Diese Unterscheidung ist ein nützlicher Beleg für Agentendesign: Autonomie kann in einen strukturierten Lieferrahmen gesetzt werden, anstatt gleichmäßig auf den gesamten Prozess angewendet zu werden.

Häufige Fehlermodi agentischer KI

Häufige Missverständnisse

Eine praktische Abfolge für das Agentendesign

Checkliste für agentische KI-Architektur

Randfälle und Einschränkungen

Manche Systeme sind nur im engen Routing-Sinne „agentisch“: Das Modell wählt einen Spezialisten oder ein Werkzeug aus, und der Rest des Workflows ist deterministisch. Das kann trotzdem nützlich sein, sollte aber nicht als gleichwertig mit einem lang laufenden autonomen Agenten beschrieben werden.

In hochgradig folgenreichen Domänen kann die Autonomie von Agenten absichtlich eingeschränkt werden. Ein KI-System kann Belege prüfen, Empfehlungen vorbereiten und strukturierte Formulare ausfüllen, während ein Mensch der einzige Akteur bleibt, der die endgültige Transaktion ausführen darf.

Manche Umgebungen eignen sich gut für Agenten, weil das Feedback objektiv ist. Coding-Agenten können Tests ausführen; Infrastruktur-Agenten können Metriken prüfen; Daten-Agenten können Abfrageergebnisse validieren. Offene Domänen mit schwachem Feedback erfordern eine vorsichtigere Bewertung.

Ein Agent kann vollständig lokal, vollständig über verwaltete Cloud-Dienste oder in einer hybriden Architektur betrieben werden. Agentisches Verhalten beschreibt den Kontrollfluss, nicht den Hosting-Standort.

Der Begriff „Reasoning“ sollte nicht als Beweis dafür verwendet werden, dass der interne Prozess des Agenten korrekt ist. Die Produktionssicherung sollte sich auf beobachtbare Eingaben, Aktionen, Ausgaben, Zustände und Bewertungen stützen und nicht auf nicht überprüfbare Behauptungen über verborgenes Reasoning.

Was würde diese Antwort ändern?

Hersteller-APIs und Agenten-Frameworks werden sich weiterentwickeln, aber die Architekturgrenze ist stabil: Ein Modell schlägt Entscheidungen vor, eine Laufzeit verwaltet die Schleife, Werkzeuge verbinden mit der Umgebung, Berechtigungen beschränken Aktionen und externe Beobachtungen bestimmen, was tatsächlich passiert ist.

Wenn Modelle zuverlässiger werden, können Systeme sicher längere Horizonte oder komplexeres Wiederherstellungsverhalten delegieren. Wenn Laufzeitverifikation und Autorisierung besser werden, können einige Genehmigungsschritte automatisiert werden. Das sind Änderungen des Autonomiegrades, nicht der grundlegenden Verantwortungsschichten.

Die empfohlene Architektur ändert sich auch je nach Folgen. Ein Recherche-Agent, der nur öffentliche Quellen liest, kann andere Kontrollen tolerieren als ein Agent, der Produktionskonfiguration schreibt oder Geld bewegt.

Verwandtes kanonisches Wissen

Agentische KI steht über mehreren vorausgesetzten Schichten: Kontext-Engineering bestimmt, was das Modell sieht; Source-of-Truth-Architektur bestimmt, welche Informationen autoritativ sind; Retrieval liefert externe Belege; Laufzeitarchitektur bestimmt, was ausgeführt werden kann.

Nachgelagerte Knoten umfassen Tool Calling, MCP, A2A, Agentenidentität, Berechtigungen, Auditierbarkeit, Human-in-the-Loop, Orchestrierung, Speicher und Multi-Agenten-Systeme.

Der Artikel zum Protokollstapel sollte daher nach dem grundlegenden Agentenkonzept gelesen werden: Protokolle standardisieren Grenzen um Agenten; sie definieren nicht das agentische Verhalten selbst.

Häufig gestellte Fragen

Glossar

Fazit

Agentische KI ist nicht einfach ein klügeres Modell oder ein Chatbot mit mehr Werkzeugen. Es ist eine Systemarchitektur, in der ein Modell an einer iterativen Kontrollschleife teilnimmt: entscheiden, handeln, beobachten, aktualisieren und fortfahren.

Das Modell bietet flexible Entscheidungsfindung, aber die umgebende Laufzeitumgebung muss die Ausführungsrealität besitzen: Berechtigungen, Werkzeugzugriff, Zustand, Genehmigungen, Wiederholungen, Budgets, Abbruchbedingungen, Nachverfolgung und Verifizierung.

Das nützlichste Designprinzip ist daher: taktische Wahl nur innerhalb expliziter technischer und geschäftlicher Grenzen an das Modell delegieren. Agentische Fähigkeit wird erst dann zur Produktionsfähigkeit, wenn Autonomie, Autorität und Evidenz trennbar bleiben.

Primärquellen und aktuelle Leitlinien

Die folgenden Quellen stützen die aktuellen architektonischen Unterscheidungen rund um Agenten, Workflows, Schleifen, Werkzeuge, Orchestrierung, Sicherheit und Evaluierung. Projektabschnitte sind originale Implementierungsnachweise und ausdrücklich auf das beschränkt, was die Repositories demonstrieren.