KI-Agenten verstehen: Aufbau, Verhalten und Grenzziehung

Manche verwechseln LLMs mit KI-Agenten. Klären wir das jetzt. Zwar erweitern einige Chatbots zur Ausführung von Tools und nennen sie KI-Agenten, doch dieser Ansatz reicht nicht aus, wenn Sie Agenten für intelligente Automatisierung einsetzen wollen. Das wollen Sie natürlich, denn Sie wissen, wie wertvoll dieser Anwendungsfall ist, um der wachsenden operativen Belastung durch hybride Multi-Cloud-Komplexität entgegenzuwirken.

Ein KI-Agent sollte ein an eine Softwareeinheit (eine Application) gebundenes System sein, das Ziele interpretiert, den Kontext aufrechterhält und Aktionen durch Aufrufen von Tools ausführt. Es kann ein großes Sprachmodell (LLM) verwenden , um zu überlegen, was geschehen muss, aber das LLM ist nur ein Teil der Maschinerie. Der Agent ist das System.

Ein KI-Agent erhält eine Aufgabe (explizit oder abgeleitet), bewertet sie im jeweiligen Kontext und entscheidet, wie er handelt. Zu seinen Aktionen gehören der Einsatz von Tools, Abfragen von Systemen oder das Starten von Workflows.

Sie brauchen nicht viele Agenten, um mit einem einzigen bereits Mehrwert zu schaffen. Ein klar fokussierter Agent, eingebettet in eine präzise Toolkette, kann heute schon nützlich sein. Er automatisiert Zusammenfassungen, erstellt Berichte, klassifiziert Tickets oder leitet Warnungen in die passenden Warteschlangen. Solange er Umfang und Regeln beachtet, liefert er schon echten Nutzen.

Sie können KI-Agenten nutzen, ohne Agentic AI umzusetzen. Wenn Agenten jedoch zusammenarbeiten, setzen Sie Agentic AI ein, auch wenn Ihre Architektur noch nicht darauf ausgelegt ist.

Basierend auf unserer aktuellsten Forschung gehe ich davon aus, dass Sie entweder schon mit agentischem Verhalten arbeiten (9 % der Befragten) oder bald damit konfrontiert werden (79 % der Befragten). Agentische KI erfordert ein Framework, das eine kontrollierte Ausführung erlaubt, bei der mehrere Agenten (ja, „Minions“, weil das die Abgrenzung zur agentischen KI erleichtert) mit gemeinsamen Werkzeugen, kontextbezogenen Zielen und Durchsetzungsebenen wie MCP zusammenarbeiten.

Ein Agent ist ein Softwarekonstrukt, das innerhalb klar definierter Grenzen selbstständig oder teilweise selbstständig arbeitet. Er setzt Aufgaben um, verwaltet den Kontext, nutzt Tools und trifft Entscheidungen für Sie oder ein übergeordnetes System. In MCP-konformen Architekturen folgen Agenten einem klar strukturierten Protokoll, das das Zusammenspiel von Aufgaben, Status und Richtlinien steuert.

Agenten können entscheiden, Aufgaben delegieren und handeln – jedoch nur innerhalb der ihnen zugewiesenen Sandbox. Sie rufen keine Systemaufrufe spontan auf. Sie erschaffen keinen eigenen Werkzeugzugriff. Alle Aktionen laufen über eine deklarierte Schnittstelle, die Sie absichern, überwachen und bei Bedarf widerrufen können.

Ein Agent besitzt mindestens:

1. Kontext-Handler – Verfolgt Zustand, Ziele und Speicher (kurzfristig oder dauerhaft)
2. Schlussfolgerungsmechanismus – Wir nutzen meist ein LLM oder symbolischen Planer, der Aufgaben versteht und die Ausführung plant
3. Tool-Schnittstelle – Ordnet Absichten Aktionen zu und steuert, welche Vorgänge der Agent ausführen darf
4. Sicherheitsgrenze – Legt fest, was der Agent darf und in welchem Umfang
5. Transportschicht – Überträgt Nachrichten und Kontext, meist mithilfe von MCP, HTTP oder einem Ereignisbus

Ein LLM denkt. Ein Agent handelt. Die Plattform steuert.

Es gibt zwei verbreitete Modelle, von denen eines eine Falle darstellt.

Das ist heute bei den meisten Frameworks Standard: LangChain, AutoGen, CrewAI und weitere. Der Agent ist im Grunde eine Chat-Eingabe mit integrierten Tools und optionalem Gedächtnis – eingebettet in eine einzelne LLM-Sitzung.

• Schnelles Prototyping
• Einfach vorzuführen
• Unsicher in der Skalierung

Einschränkungen:

• Keine dauerhafte Architektur
• Keine native Richtliniendurchsetzung
• Das Modell neigt dazu, Tool-Aufrufe zu erfinden oder Einschränkungen zu übersehen
• Keine Einsicht außerhalb der Token-Protokolle, sofern Sie sie nicht erweitern

Kurz gesagt: ein cleverer Praktikant mit Root-Zugriff und ohne Kontrolle. Funktioniert einwandfrei – bis es das nicht mehr tut.

Dieses Modell empfehlen wir für den produktiven Einsatz.

Hier handelt es sich bei dem Agenten um einen vollständigen Softwaredienst, der auf einem Framework basiert, das ein LLM nutzt, sich für die Ausführung jedoch nicht darauf verlässt.

• Der Status liegt extern vor (Redis, Vektor-Datenbanken, Richtlinien-Engines)
• Sie steuern die Tool-Nutzung klar und über eine Kontrollschicht (MCP-Server, Gateway-Proxy).
• Sicherheit und Beobachtbarkeit haben bei uns oberste Priorität – nicht erst nachträglich
• Der Agent ist ein bereitgestellter Dienst, keine Eingabeaufforderung

Mit diesem Ansatz erhalten Sie Versionskontrolle, Zugriffprotokolle, Governance auf Tool-Ebene und Laufzeitisolierung. So setzen Sie Agenten als echte Infrastruktur ein, statt als Spielzeuge.

Wenn man Agenten entwirft, als wären sie intelligente Persönlichkeiten, greift man automatisch zu menschlichen Zugriffsmodellen: rollenbasierte Zugriffskontrolle (RBAC), Anmeldetoken, Benutzerattribute, Identitätsbereiche. Diese sind sinnvoll, wenn Sie innerhalb einer Sitzung mit einer durchgehenden menschlichen Identität arbeiten. Agenten verhalten sich jedoch anders. Sie sind keine Benutzer. Sie sind Ausführende. Und das verändert alles.

Agenten übernehmen während ihrer Arbeit verschiedene Rollen. Ein einzelner Agent kann im Verlauf derselben Sitzung und unter derselben Aufgabe als Datenabrufer, Planer und Auslöser für Automatisierung agieren. Er meldet sich nicht statisch an, holt keinen festen Token und arbeitet nicht nur in einer festen Rolle.

Hier versagt die traditionelle Zugriffskontrolle. RBAC arbeitet mit statischen Rollen. Attributbasierte Zugriffskontrolle (ABAC) setzt auf feste Attribute. Sitzungstoken gehen von einem konsistenten Anwendungsbereich aus. Das gilt nicht, wenn Agenten dynamisch sind. Identität in agentischen Systemen funktioniert funktional, nicht persönlich.

Darum müssen Sie die Steuerung von Agenten von identitätsbasierten Richtlinien auf ausführungsbasierte Richtlinien umstellen. Jeden Tool-Aufruf validieren wir in Echtzeit anhand der aktuellen Aufgabenrolle, des Kontextzustands und des erlaubten Umfangs des Agenten. Richtlinien gelten auf der Tool-Ebene, nicht auf der Authentifizierungsebene. Kontextblöcke tragen die erforderlichen Metadaten zur Durchsetzung der Richtlinien, nicht Anmeldesitzungen. Daher nennen wir diesen Paradigmenwechsel „Policy in Payload“, weil die Richtlinie buchstäblich in der Nutzlast steckt.

Behandle Agenten wie Agenten. Verwalte sie wie Software. Und vergiss nie: Der LLM denkt, der Agent handelt, und die Plattform regelt. Wenn du diese Rollen vermischst, erschaffst du eine Persönlichkeit mit Admin-Rechten und ohne Erinnerung an ihre letzte Fehlentscheidung.

Das LLM denkt. Der Agent handelt. Die Plattform steuert.

Halten Sie sich daran, und Sie schaffen eine Agenteninfrastruktur, die mitwächst, Sicherheit bietet und Herausforderungen in der Realität problemlos meistert.