KI-Agenten arbeiten typischerweise in einer Schleife aus Ziel verstehen, Kontext sammeln, planen, Werkzeuge nutzen, Ergebnis prüfen und den nächsten Schritt wählen. Wie autonom diese Schleife abläuft, hängt vom Produkt und den eingeräumten Rechten ab.
1. Ziel und Kontext
Der Agent erhält eine Aufgabe und zusätzlichen Kontext: etwa Dateien, Webquellen, Unternehmenswissen oder eine Codebasis. Gute Agenten müssen erkennen, welche Informationen fehlen und welche Einschränkungen gelten.
2. Planung
Bei komplexeren Aufgaben zerlegt der Agent ein Ziel in kleinere Schritte. Ein Recherche-Agent kann beispielsweise Suchfragen planen; ein Coding-Agent identifiziert Dateien, Tests und Änderungsschritte.
3. Tool Use
Werkzeuge machen aus einem Sprachmodell einen handlungsfähigeren Agenten. Das können Websuche, Browser, Datenbanken, APIs, Code-Ausführung, E-Mail, Kalender oder Fachsysteme sein.
4. Beobachten und anpassen
Nach einer Aktion wertet der Agent das Ergebnis aus. Schlägt ein Schritt fehl oder fehlen Informationen, kann er die Strategie anpassen und einen weiteren Schritt ausführen.
5. Abschluss und Kontrolle
Der Prozess endet mit einem Bericht, einer Änderung oder einer Aktion. Bei kritischen Vorgängen sollte ein Mensch kontrollieren, bevor irreversible Schritte ausgeführt werden.
Agenten konkret ansehen
Die Theorie wird verständlicher, wenn man reale Produkte vergleicht. AgentenIndex dokumentiert 57 Agenten und Plattformen mit offiziellen Quellen.
Alle Agentenprofile →Die Architektur hinter einem KI-Agenten
Ein moderner Agent lässt sich als Regelkreis verstehen. Er erhält ein Ziel, baut daraus einen aktuellen Arbeitszustand, wählt einen nächsten Schritt, nutzt gegebenenfalls ein Werkzeug und bewertet anschließend das Ergebnis. Dieser Zyklus wiederholt sich, bis das Ziel erreicht, eine Grenze erreicht oder eine menschliche Entscheidung erforderlich wird.
1. Kontext: Was weiß der Agent?
Kontext umfasst mehr als den letzten Nutzerprompt. Dazu können Gesprächsverlauf, Dateien, Datenbanken, Unternehmenswissen, Rollen, Kalender, CRM-Daten oder Ergebnisse früherer Tool-Aufrufe gehören. Ein Agent kann nur so gut entscheiden, wie der relevante Kontext verfügbar und aktuell ist. Zu viel Kontext kann allerdings ebenfalls schaden: irrelevante Informationen erhöhen Kosten und können die Entscheidung verwässern.
2. Planung: Wie entsteht der nächste Schritt?
Manche Systeme erzeugen einen sichtbaren Plan, andere planen implizit. Planung bedeutet nicht zwangsläufig einen langen „Gedankengang“, sondern kann auch eine strukturierte Aufgabenliste, Tool-Auswahl oder Routing-Entscheidung sein. Wichtig ist, dass der Agent seinen Fortschritt anhand beobachtbarer Zustände steuert.
3. Tools: Wie verlässt der Agent den Chat?
Tools machen Agenten handlungsfähig. Eine Websuche liefert aktuelle Informationen, ein Dateitool liest Dokumente, eine API kann CRM-Daten abrufen und ein Coding-Agent kann Terminalbefehle oder Tests ausführen. Tool-Nutzung sollte möglichst eng spezifiziert werden: klare Namen, klarer Zweck, begrenzte Parameter und nur notwendige Rechte.
4. Memory: Was bleibt über mehrere Schritte erhalten?
Kurzzeitkontext hält Informationen innerhalb einer Aufgabe. Persistentes Memory kann Präferenzen, frühere Ergebnisse oder längerfristigen Arbeitskontext speichern. Das kann Agenten nützlicher machen, wirft aber Datenschutz- und Qualitätsfragen auf: Was wird gespeichert? Wie lange? Kann der Nutzer es sehen und korrigieren? Was passiert, wenn eine gespeicherte Annahme falsch ist?
5. Kontrolle: Wer darf was ausführen?
Produktive Agenten brauchen Grenzen. Dazu zählen Rollen und Berechtigungen, erlaubte Tools, Maximalbudgets, Freigaben, Timeout-Regeln, Audit-Logs und Eskalationspfade. Die robusteste Architektur ist häufig nicht „maximal autonom“, sondern so autonom wie nötig und so kontrollierbar wie möglich.
| Kontrollpunkt | Frage |
|---|---|
| Berechtigung | Darf der Agent diese Daten sehen oder verändern? |
| Tool | Ist die Aktion klar begrenzt und protokolliert? |
| Kosten | Wie viele Modell- und Tool-Aufrufe darf eine Aufgabe erzeugen? |
| Freigabe | Welche Aktionen brauchen einen Menschen? |
| Evaluation | Wie wird Qualität regelmäßig gemessen? |
Was passiert, wenn ein Agent scheitert?
Ein guter Agent sollte nicht endlos weiterarbeiten. Fehler können durch fehlende Berechtigungen, schlechte Quellen, widersprüchliche Informationen, Tool-Ausfälle oder falsche Annahmen entstehen. Sinnvolle Systeme erkennen solche Zustände, versuchen begrenzte Alternativen und eskalieren anschließend, statt unkontrolliert weiterzumachen.
Der agentische Regelkreis im Detail
Viele Agenten arbeiten iterativ. Nach jedem Schritt verändert sich der Zustand der Aufgabe: Eine Suche liefert neue Fakten, ein API-Aufruf gibt Daten zurück, ein Test schlägt fehl oder ein Nutzer verweigert eine Freigabe. Der Agent muss diesen neuen Zustand interpretieren und entscheiden, ob er den Plan beibehält, anpasst oder abbricht.
Technisch kann diese Schleife sehr unterschiedlich umgesetzt sein. Manche Systeme lassen das Modell in jeder Runde das nächste Tool wählen. Andere kombinieren feste Workflow-Knoten mit einem agentischen Entscheidungspunkt. Wieder andere benutzen einen separaten Planner und Executor. Für Nutzer ist weniger die interne Architektur als ihre Wirkung relevant: Kann das System flexibel reagieren, ohne unkontrollierbar zu werden?
Wie Tool Calling funktioniert
Ein Tool wird normalerweise über eine definierte Schnittstelle beschrieben: Name, Zweck, erwartete Parameter und mögliche Ausgabe. Das Modell entscheidet anhand des aktuellen Kontexts, ob ein Tool benötigt wird und mit welchen Parametern es aufgerufen werden soll. Die Anwendung führt den Aufruf aus und gibt das Ergebnis zurück. Erst danach entscheidet der Agent über den nächsten Schritt.
Deshalb ist Tool-Design ein Sicherheits- und Qualitätsfaktor. Ein Tool „send_email(to, subject, body)“ ist klarer begrenzt als ein unspezifisches „execute_anything“. Gute Tools sind so klein und eindeutig wie möglich, validieren Eingaben und geben strukturierte Resultate zurück.
Retrieval und Wissenszugriff
Viele Agenten benötigen Wissen, das nicht zuverlässig im Modell enthalten ist. Retrieval-Systeme suchen passende Abschnitte aus Dokumenten, Wissensbasen oder Datenbanken und stellen sie als Kontext bereit. Im Unternehmen müssen dabei bestehende Berechtigungen erhalten bleiben: Ein Agent darf durch die Suche nicht plötzlich Dokumente sehen, auf die der Nutzer selbst keinen Zugriff besitzt.
Identität und Berechtigungen
Bei produktiven Agenten ist die Identität entscheidend. Arbeitet der Agent im Namen des Nutzers, mit einer eigenen Dienstidentität oder mit einem gemeinsamen Systemkonto? Diese Entscheidung bestimmt, welche Daten und Aktionen möglich sind und wie sauber Ausführungen später zugeordnet werden können.
| Modell | Vorteil | Risiko |
|---|---|---|
| Nutzeridentität | Rechte folgen dem Nutzer | Agent kann im Namen des Nutzers handeln |
| Agentenidentität | klar begrenzte, eigene Rechte | zusätzliche Identitätsverwaltung nötig |
| Systemkonto | einfach für zentrale Automation | oft zu breite Rechte und schlechte Zuordnung |
Tracing, Logs und Observability
Ein Agentenlauf besteht aus vielen Einzelereignissen. Für Fehlersuche und Governance sollten zumindest Tool-Aufrufe, ausgewählte Datenquellen, Laufzeit, Kosten, Freigaben, Fehler und Ergebnisstatus sichtbar sein. Ohne Observability ist kaum feststellbar, ob ein schlechtes Ergebnis am Modell, am Tool, am Kontext oder an einer Geschäftsregel lag.
Warum Evals unverzichtbar sind
Ein Agent sollte gegen eine Sammlung realistischer Aufgaben getestet werden. Neben Standardfällen gehören schwierige oder absichtlich problematische Eingaben dazu: fehlende Daten, widersprüchliche Quellen, unzulässige Aktionen oder Tool-Ausfälle. Evals machen Veränderungen messbar, wenn Modell, Prompt, Tool oder Datenquelle aktualisiert werden.
Kosten und Latenz
Mehrstufige Agenten können viele Modellaufrufe und Tools verwenden. Das erhöht Latenz und Kosten. Ein gutes System entscheidet deshalb nicht nur richtig, sondern möglichst effizient. Häufig hilft eine Architektur, in der einfache Fälle deterministisch oder mit kleineren Modellen verarbeitet werden und teure agentische Schleifen nur bei komplexen Aufgaben starten.
Beispiel eines vollständigen Agentenlaufs
Ein Nutzer beauftragt einen Agenten: „Finde drei geeignete CRM-Systeme für ein 20-köpfiges Vertriebsteam und berücksichtige EU-Datenschutz, Preisrahmen und HubSpot-Migration.“ Der Agent extrahiert Kriterien, sucht Anbieter- und Dokumentationsquellen, sammelt Fakten, vergleicht Funktionen und stellt fest, dass bei einem Anbieter eine Preisangabe unklar ist. Er startet eine weitere Suche, markiert die Unsicherheit und erstellt anschließend eine Tabelle mit Quellen.
Wäre derselbe Agent zusätzlich mit einem CRM-Tool verbunden, könnte er nach Freigabe sogar aktuelle Felder oder Prozesse aus dem bestehenden System analysieren. Ab diesem Punkt verändert sich das Risikoprofil deutlich: Aus Recherche wird Systemzugriff.
Fünf Designregeln für robuste Agenten
- Tools klein halten: Ein klar begrenztes Tool ist leichter zu verstehen und sicherer zu verwenden.
- Kontext gezielt auswählen: Relevanz ist wichtiger als maximale Datenmenge.
- Irreversible Aktionen freigeben: Zahlungen, Löschungen oder öffentliche Kommunikation brauchen stärkere Kontrollen.
- Fehler sichtbar machen: Der Agent sollte Unsicherheit und fehlende Daten nicht verstecken.
- Erfolg messen: Ohne Evals bleibt unklar, ob Verbesserungen tatsächlich helfen.
Verwandte Themen
Tool-Anbindung wird unter MCP vertieft. Persistenter Kontext ist Thema von Memory. Für Systeme aus mehreren Agenten siehe Multi-Agent-Systeme. Sicherheits- und Kontrollfragen bündelt KI-Agenten-Sicherheit.