Was sind KI-Agenten? Funktionsweise, Tools und Orchestrierung

Was ist ein KI-Agent?

Ein KI-Agent ist ein KI-gestütztes Softwaresystem, das ein Ziel bzw. eine Aufgabe über mehrere Verarbeitungsschritte verfolgt und dabei – abhängig vom aktuellen Zustand – selbst auswählen kann, welche unterstützten Werkzeuge oder Aktionen als Nächstes verwendet werden. Wie viel Entscheidungsspielraum ein Agent hat, ergibt sich aus seiner Architektur, seinen Berechtigungen und den gesetzten Grenzen.

Wichtig zu wissen: Es gibt keine einzige, weltweit verbindliche Agentendefinition. Begriffe wie „AI Agent", „Agentic AI", „Assistant", „Copilot" oder „autonomous agent" werden in Forschung und Industrie unterschiedlich verwendet. Es existiert kein technischer Schwellenwert der Art „ab X selbstständigen Schritten ist ein System ein Agent". Anthropic etwa grenzt in „Building Effective Agents" Workflows (LLMs und Tools über vordefinierte Code-Pfade orchestriert) von Agents (das Modell steuert Ablauf und Werkzeugnutzung dynamisch selbst) ab – eine nützliche, aber bewusst pragmatische Unterscheidung.

Nicht vorausgesetzt werden darf, dass jeder Agent ein Langzeitgedächtnis besitzt, immer explizit plant, mehrere Tools nutzt, MCP verwendet, unbeaufsichtigt arbeitet oder aus mehreren Modellen besteht. All das sind mögliche Bausteine, keine Definitionsmerkmale.

Autonomie ist ein Spektrum

„Teil-autonom" ist ein guter Einstieg, aber zu grob. Autonomie ist eine Dimension, keine Ja/Nein-Eigenschaft:

Das ist keine offizielle Stufenskala – es gibt keine allgemein anerkannten „Autonomie-Level 1–5". Entscheidend sind der reale Entscheidungsspielraum und die Tragweite der Aktionen.

Chatbot, Workflow oder Agent?

Ein Chatbot führt im Kern „Eingabe → Antwort" aus. Ein Workflow folgt weitgehend vorab festgelegten Schritten. Ein Agent entscheidet innerhalb definierter Grenzen dynamischer, welcher Schritt als Nächstes sinnvoll ist.

Zwei Klarstellungen: Ein Chatprodukt kann intern agentische Funktionen enthalten (Produktoberfläche ≠ Architektur). Und eine Automatisierung ist der Oberbegriff für automatisierte Abläufe – „Jeden Montag 08:00 Bericht erzeugen" ist Automatisierung ohne Agent. Ein Agent kann Teil einer Automatisierung sein, ist aber nicht ihr Synonym.

Ein Agent ist mehr als das Modell

Ein Sprachmodell ist ein Modell. Ein Agent ist ein System bzw. „Harness" um ein Modell herum. Deshalb sind mehrere Begriffe sauber zu trennen:

So funktioniert ein Agent Loop

Das Herzstück vieler Agenten ist eine Schleife: entscheiden, handeln, beobachten, erneut entscheiden. Ein Muster dafür ist das aus der Forschung bekannte ReAct-Prinzip (Reasoning und Acting verschränkt).

Planung und Ausführung

„Planung" ist kein Zauberwort. Sie kann sehr unterschiedlich aussehen: ein vollständiger Plan vorab, nur der nächste Schritt, Zwischenziele oder dynamisches Replanning. Es ist falsch zu behaupten, „ein echter Agent" erstelle immer zuerst einen kompletten Plan.

Sauber getrennt werden sollten Entscheiden und Ausführen. Das Modell kann entscheiden „E-Mail versenden" – die eigentliche Aktion führt aber eine konkrete Software aus (z. B. eine Mail-API oder ein Connector). Das Modell selbst „sendet" technisch nichts; es wählt eine Aktion, die ein deterministisches Werkzeug ausführt.

Tools, Aktionen und Side Effects

Ein Tool kann z. B. Websuche, Taschenrechner, Datenbank, CRM, Kalender, E-Mail, Browser, Codeausführung, Dateisystem oder eine interne API sein. Toolbeschreibungen sind Teil der Architektur: schlecht definierte Tools führen zu falscher Auswahl, falschen Parametern oder unnötigen Aktionen. Für jedes Tool sollten Zweck, Eingabe, Ausgabe, Fehlerfälle, Berechtigungen und Seiteneffekte klar sein.

Ein Side Effect ist eine externe Auswirkung: Ein Agent, der nur liest, hat eine andere Risikoklasse als einer, der E-Mails sendet, Dateien löscht, Geld überweist, Code deployt oder Termine absagt. Diese Unterscheidung ist die Grundlage der Sicherheitsarchitektur.

Human Approval und Reversibilität

„Human in the Loop" ist nicht gleich „Human in the Loop". Entscheidend ist wann und womit der Mensch eingreift:

Human Approval wirkt nur, wenn die Person die relevanten Informationen sieht, die Konsequenzen versteht und realistisch widersprechen kann. Eine überzeugend formulierte Empfehlung kann sonst zu ungeprüften Freigaben verleiten (Automation Bias). Menschliche Freigabe ist deshalb keine automatische Sicherheitsgarantie.

Berechtigungen, Least Privilege und Identität

Agenten sollen nur die Rechte erhalten, die sie für ihre Aufgabe tatsächlich brauchen (Least Privilege). Wer Kalendertermine lesen muss, braucht nicht automatisch das Recht, Kalender zu löschen. Zu unterscheiden sind lesen, erstellen, ändern und löschen.

2026 ist Identität ein zentrales Thema: Handelt der Agent als Nutzer, als Service-Account oder mit delegierten Rechten? Auf welchem Mandanten, mit welchen Rollen? Zu trennen sind Authentifizierung (wer ist der Akteur?) und Autorisierung (was darf er tun?) – bei Agenten besonders wichtig, weil das Modell Aktionen dynamisch wählt. NIST arbeitet hierzu an eigenen Konzepten (Identität, Autorisierung, Auditing, Non-Repudiation für Software- und KI-Agenten). Grundregel: keine Zugangsdaten und keine API-Schlüssel im Modellkontext.

Für die Tool-Anbindung über MCP ist die aktuelle Spezifikation (Revision 2026-07-28) maßgeblich. Sie stützt Autorisierung auf OAuth 2.1 (u. a. PKCE, Resource Indicators) und hält ausdrücklich fest, dass ein MCP-Server keine Tokens akzeptieren darf, die nicht für ihn ausgestellt wurden. Die USB-/Steckdosen-Analogie hilft Einsteigern, darf aber nicht suggerieren, dass Tools automatisch zueinander passen, Berechtigungen automatisch gelöst oder Integrationen automatisch sicher seien.

State und Memory

Ein Agent braucht oft Wissen darüber, was bereits erledigt wurde, welche Daten vorliegen und was noch fehlt. Dieser Zustand (State) kann im aktuellen Kontext, im Session-State, in einem externen Speicher oder in einem Workflow-System liegen. State ist nicht automatisch „Memory".

Wichtig: Wenn sich eine Agentenanwendung einen Kundennamen „merkt", heißt das nicht, dass das Modell damit weitertrainiert wurde. Memory kann vollständig außerhalb des Modells gespeichert sein. Und persistente Memory ist eine Angriffsfläche: Manipulierte oder ungeprüfte Inhalte können später erneut Verhalten beeinflussen (Memory Poisoning – siehe Prompt Injection).

Context Engineering und Long-Running Agents

Der Kontext eines Agenten kann Systemregeln, Ziel, Verlauf, Memory, Dateien, Tooldefinitionen, Toolergebnisse, RAG und Zwischenzustand enthalten. Der Fehler ist, alles ständig in den Kontext zu kopieren: Das Kontextfenster ist begrenzt, und zu viel Kontext kann die Qualität senken. Anthropic beschreibt Kontext als endliche Ressource und empfiehlt, die kleinstmögliche Menge hochrelevanter Informationen bereitzustellen.

Ein Agent kann länger arbeiten als ein einzelner Modellaufruf. Dafür nutzen Systeme Checkpoints, persistierten Zustand, Compaction (Verdichtung älteren Kontexts) und Zusammenfassungen. „Ein Agent arbeitet Stunden" bedeutet also nicht, dass ein Modell stundenlang in einem ununterbrochenen Kontext läuft. Compaction spart Kontext, kann aber Informationen verlieren oder falsch zusammenfassen. Produktive Agenten brauchen zudem Resumability (Wiederaufnahme nach Timeout, Rate-Limit oder Toolausfall statt Neustart) und Idempotenz: Ein Retry bei „Bestellung anlegen" darf nicht versehentlich zwei Bestellungen erzeugen.

Observability und Tracing

Produktive Agenten müssen nachvollziehbar sein. Sinnvoll protokolliert werden: welcher Agent aktiv war, welcher System-/Kontextrahmen galt, welches Tool mit welchen Parametern gewählt wurde, welches Ergebnis zurückkam, welche Freigabe erfolgte sowie Kosten und Dauer je Schritt. Logs dürfen dabei nicht selbst unnötig sensible Daten sammeln.

Tracing zeigt den Ablauf über mehrere Schritte (Nutzer → Agent → Suche → Agent → Datenbank → Approval → E-Mail) und ist zentral für Debugging und Evaluation. Wichtig: Observability ist nicht dasselbe wie das Speichern vollständiger interner „Gedankengänge". Produktive Nachvollziehbarkeit konzentriert sich auf Tool-Aufrufe, Zustandsänderungen, Entscheidungen auf Systemebene, Outputs, Freigaben und Fehler – nicht auf komplette Reasoning-Tokens.

Evaluation von Agenten

Ein Agent darf nicht nur danach bewertet werden, ob die finale Antwort gut klingt. Mehrere Ebenen gehören gemessen:

Für Unternehmen bewährt sich ein Golden Task Set: repräsentative reale Aufgaben mit erwartetem Ergebnis, erlaubten Tools, verbotenen Aktionen, Erfolgskriterium und ggf. erwarteter Freigabe – als Grundlage für Regressionstests. Guardrails (Regeln für erlaubte Eingaben, Outputformate, sensible Inhalte, Toolrechte, Approval-Pflicht) sind eine sinnvolle Schutzschicht, aber keine Sicherheitsgarantie. Allgemeines zur Bewertung: KI-Modelle evaluieren.

Agentic Security

Agenten haben ein besonderes Risiko: Manipulierte Inhalte erzeugen nicht nur eine falsche Antwort, sondern können eine Aktion auslösen. Prompt Injection kann über Webseiten, E-Mails, Dokumente, RAG-Treffer oder Toolergebnisse eingeschleust werden. Die OWASP Top 10 for Agentic Applications (2026) bündeln die typischen Risikoklassen; verkürzt:

Single-Agent vs. Multi-Agent

Ein Multi-Agent-System enthält mehrere Agenten mit getrennten Rollen, Anweisungen, Tools und Zuständen. Mehr Agenten sind aber nicht automatisch besser. Ein Single-Agent genügt oft, wenn die Aufgabe überschaubar ist, die Tools begrenzt sind, ein Kontext ausreicht und klare Erfolgskriterien bestehen – er ist einfacher, günstiger und leichter zu debuggen und zu evaluieren.

Multi-Agent hat einen Preis: mehr Modellaufrufe, mehr Kontext, mehr Kommunikation, mehr Latenz. Laut Anthropics eigener Darstellung verbraucht ein einfacher Agent grob das Mehrfache an Tokens gegenüber einem Chat, ein Multi-Agent-System noch deutlich mehr – solche Zahlen sind Anbieterangaben und je nach Aufgabe verschieden. Dazu kommen neue Fehlerquellen: widersprüchliche Ergebnisse, falsche Delegation, Kommunikationsverlust, Doppelarbeit und Fehlerweitergabe. Multi-Agent lohnt sich nur bei nachweisbarem Nutzen (klar getrennte Rollen, parallele Recherche, getrennte Berechtigungen).

Agentic RAG, Computer Use und Coding-Agenten

Agentic RAG plant mehrere Suchschritte dynamisch: Frage analysieren, Teilfragen bilden, mehrere Quellen durchsuchen, Ergebnisse prüfen, weitere Suche entscheiden. Das ist keine universell standardisierte Architektur – Grundlagen unter RAG. Computer-Use-/Browser-Agenten steuern Oberflächen über Browser-APIs, DOM, Screenshots oder Maus/Tastatur; UI-Automation ist oft fragiler als direkte APIs, daher wo möglich strukturierte Tools bevorzugen. Coding-Agenten können Dateien lesen, suchen, Code ändern und Tests ausführen – Produktivänderungen brauchen aber Tests, Code-Review, Berechtigungsgrenzen und Deployment-Kontrollen (siehe KI für Coding). Praktische Beispiele mit unterschiedlichem Seiteneffekt sind E-Mail-/Kalender-Agenten (lesen vs. senden/löschen) und Rechercheagenten (geringer direkter Seiteneffekt, aber Quellenprüfung und Prompt-Injection-Risiko bleiben).

Deterministische Bausteine bevorzugen

Ein moderner Agent muss nicht alles vom Modell erledigen lassen. Für exakte Aufgaben sind deterministische Komponenten zuverlässiger: eine Berechnung gehört in einen Taschenrechner, ein Datenbankwert in eine SQL-/API-Abfrage, eine Dateivalidierung in klassischen Code, eine Richtlinie in eine regelbasierte Prüfung.

Kosten, Latenz und Reproduzierbarkeit

Agenten verursachen Kosten durch mehrere Modellaufrufe, Tool-Calls, Suche, RAG, Reranking, Codeausführung, Langzeitkontext und Multi-Agent-Kommunikation. „Agenten sind teuer" ist trotzdem zu pauschal – entscheidend ist der Kostenpfad der konkreten Aufgabe; überschlagen lässt er sich mit dem KI-Kostenrechner. Bei der Latenz summieren sich Modell, Tools, Netzwerk, Datenbanken, Approvals und weitere Agenten; Parallelisierung hilft, erhöht aber die Komplexität. Und: Agentische Systeme können bei gleicher Eingabe unterschiedliche Pfade und Ergebnisse wählen – für kritische Prozesse deshalb Grenzen setzen und mit dem Golden Task Set testen.

Agenten im Unternehmen, Datenschutz und lokale Agenten

Geeignete Einsatzfelder können Supporttriage, Recherche, interne Wissenssuche, Dokumentverarbeitung, Coding, Backoffice-Aufgaben oder Monitoring sein (mehr unter KI für Unternehmen). Eine ROI-Garantie gibt es nicht. Beim Datenschutz gilt: An einem Agentenlauf können Modellanbieter, Tools, APIs, Datenbanken, Logs, Memory und MCP-Server beteiligt sein. Die Frage lautet nicht nur „Wo läuft das Modell?", sondern „Wohin fließen die Daten während des gesamten Agentenlaufs?".

Agenten lassen sich teilweise lokal bauen (lokales Modell, lokale Tools, lokaler Vector Store, lokale Runtime). Aber lokal ist nicht automatisch sicher: Berechtigungen, Logs, Toolzugriffe, Updates und Prompt-Injection-Schutz bleiben auch lokal Pflicht.

EU AI Act und Agenten

Ein „KI-Agent" ist keine eigene gesetzliche Risikokategorie des EU AI Act. Welche Pflichten gelten, hängt vom konkreten KI-System, vom Anwendungsfall, von der Rolle (Anbieter/Betreiber) und vom Risikokontext ab. Für die rechtliche Einordnung ist die Fachseite maßgeblich.

Wann ein Agent sinnvoll ist – und wann ein Workflow reicht

Die praktisch wichtigste Frage lautet oft: Braucht diese Aufgabe überhaupt einen Agenten? Häufig nicht. Kein Agent nötig, wenn eine feste Regel reicht („Wenn Rechnung freigegeben → an Buchhaltung"), eine API eine eindeutige Antwort liefert (Kontostand), eine normale Suche genügt (Dokument finden) oder ein einzelner Modellaufruf ausreicht (Text zusammenfassen).

Zusätzlich hilft eine Risiko-Betrachtung aus zwei Dimensionen – Entscheidungsspielraum und Seiteneffekt:

Häufige Missverständnisse

Weiterführende Themen

KI-Agenten verbinden viele BOMOTS-Themen. Von hier aus geht es weiter:

Grundlagen zum Feld: Was ist KI? und Generative KI. Für die Auswahl: der Automatisierungs-Tools-Bereich und der KI-Kostenrechner.