Kein Thema entwickelt sich derzeit schneller als agentenbasierte KI. Anders als herkömmliche Chatbots arbeiten KI-Agenten eigenständig im Auftrag ihrer Nutzer. Sie erledigen Onlineeinkäufe, entwickeln Software, analysieren Märkte oder buchen Reisen. Damit verlässt generative KI den geschützten Raum der Chatoberfläche und wirkt direkt auf die reale Welt ein.

Die Entwicklung verläuft rasant: Das Model Context Protocol (MCP) zum Beispiel, einer der zentralen Bausteine heutiger Agenten, ist gerade einmal ein Jahr alt. Grund genug, einen Blick auf die technischen Grundlagen zu werfen: Welche Kernkomponenten benötigt ein agentenbasiertes KI-System und wie greifen diese ineinander? Denn es gibt in diesem Bereich weiterhin viele Debatten, Missverständnisse und Behauptungen.

Definition und Funktionsweise

Der britische Programmierer Simon Willison hat eine prägnante Definition für Agenten formuliert, die auch Grundlage für diesen Artikel ist: Ein Agent führt KI-Modelle und Tools in einer Schleife aus, um ein Ziel zu erreichen. Das bedeutet, der Nutzer gibt einem Large Language Model (LLM) eine Aufgabe – etwa einen Restauranttisch in Kinonähe zu buchen. Das Modell erhält zusätzlich eine Liste verfügbarer Tools wie eine Datenbank mit Restaurantstandorten oder gespeicherte Nutzerpräferenzen.

Nun plant das Modell, wie es dieses Ziel erreichen kann, und startet mit einem ersten Schritt: Es ruft eines der Tools auf. Dieses antwortet, und auf Basis dieser Antwort wählt das Modell das nächste Werkzeug. Durch diese wiederholte Abfolge arbeitet sich der Agent Schritt für Schritt zur Zielerreichung vor. Manchmal unterstützt zusätzlicher imperativer Code die Orchestrierungsentscheidungen des Modells.

Die Kernkomponenten

Ein agentenbasiertes System besteht aus mehreren Komponenten, die nahtlos zusammenspielen müssen. Zunächst braucht es eine Entwicklungsumgebung, mit der sich Agenten bauen lassen, ohne bei null anzufangen. Entsprechende Frameworks nehmen Entwicklern viel Arbeit ab. Ebenso wichtig ist eine Laufzeitumgebung für das KI-Modell selbst. Open-Weight-LLMs herunterzuladen und betriebsbereit zu machen erfordert nicht nur erhebliche Expertise, sondern auch teure Hardware, die bei durchschnittlicher Nutzung meist schlecht ausgelastet ist.

Darüber hinaus braucht es eine Runtime-Umgebung für den agentenbasierten Code. Die meisten Agenten laufen in der Cloud. Schließlich sollen sie auch dann arbeiten, wenn Laptops geschlossen sind, und müssen bei Bedarf skalieren können. Ein weiterer Baustein übersetzt zwischen dem textbasierten LLM und konkreten Tool-Aufrufen. Hinzu kommen zwei Speichertypen: ein Kurzzeitspeicher für die laufende Interaktion und ein Langzeitspeicher, in dem Nutzerpräferenzen und neu gelernte Fakten über mehrere Sessions hinweg aufbewahrt werden. Und schließlich braucht es ein System zur Überwachung und Nachverfolgung der ausgeführten Schritte, um die Leistung des Agenten zu evaluieren und zu optimieren.

Agenten-Entwicklung und das ReAct-Modell

LLMs arbeiten besser, wenn sie zunächst erklären, wie sie eine Aufgabe angehen wollen. Dieses "Chain-of-Thought-Reasoning" ist mittlerweile Standard. Bei agentenbasierten Systemen heißt das Pendant ReAct-Modell ("Reasoning and Action"): Der Agent formuliert einen Gedanken, führt eine passende Aktion aus und beobachtet das Ergebnis. Beispielsweise könnte der Gedanke lauten, eine Kartenfunktion zu nutzen, um Restaurants in der Nähe zu finden. Die Aktion ist der API-Aufruf dieser Karte. Die Beobachtung zeigt dann, welche Restaurants konkret in der Nähe liegen.

Das ReAct-Modell ist zwar eines der erfolgreichsten, aber nicht die einzige Arbeitsweise moderner Agenten. Doch typischerweise durchlaufen heutige Modelle Schleifen über die Thought-Action-Observation-Sequenz. Die verfügbaren Tools reichen von lokalen Werkzeugen bis zu externen Ressourcen wie Datenbanken, Microservices oder Software-as-a-Service. Für jedes Tool braucht es dann eine Spezifikation, bestehend aus einer natürlichsprachlichen Erklärung, wofür dieses Werkzeug genutzt werden kann, und der Syntax der API-Aufrufe, um das Werkzeug konkret aufrufen zu können. Entwickler können Agenten zudem anweisen, bei Bedarf eigene Tools zu erstellen.

Ein Beispiel: Ein Tool ruft eine Tabelle ab, die als kommaseparierter Text vorliegt, und der Agent muss sie sortieren. Die Tabelle zum Sortieren an das LLM zu übergeben, wäre Ressourcen- und Zeitverschwendung. Stattdessen weist der Entwickler den Agenten an, für solche einfachen, repetitiven Aufgaben eigenen Python-Code zu generieren. Diese Code-Schnipsel laufen dann lokal oder in einem dedizierten Code-Interpreter-Tool.

Runtime und Isolation

Es gibt zwei Wege, Code auf gemeinsam genutzten Servern zu isolieren: Containerisierung ist effizient, bietet aber weniger Sicherheit, weil einzelne Container nicht streng voneinander abgeschirmt sind. Virtuelle Maschinen sind in dieser Hinsicht sicherer, verursachen aber hohen Rechenaufwand. Moderne Technologien verbinden beide Vorteile. Sie schaffen MicroVMs mit Hardware-Isolation und eigenen Linux-Kernels, benötigen aber nur wenige Megabyte Overhead und starten in Millisekunden. 

Da ein Agent ein LLM samt Speicherressourcen benötigt, setzen moderne Systeme auf sitzungsbasierte Isolation. Jede Sitzung erhält ihre eigene MicroVM. Am Ende der Sitzung werden die Zustandsinformationen des LLM zusammengefasst und in den Langzeitspeicher übertragen, die MicroVM wird zerstört. So lassen sich zahlreiche Agenten sicher und effizient betreiben.

Toolkommunikation und Protokolle

Für die Kommunikation zwischen Agenten und Tools existieren mehrere Standards. Am weitesten verbreitet ist das oben erwähnte Model Context Protocol. Das MCP definiert ein Standardformat für die Datenübertragung zwischen einem LLM und einem Server, der Tools bereitstellt und legt fest, wie der Server dem Agenten mitteilen kann, welche Werkzeuge angeboten werden und welche Daten verfügbar sind.

Manchmal fehlt dem benötigten Tool aber eine öffentliche API. Dann bleibt nur der Weg über die Benutzeroberfläche: Der Agent klickt sich durch die Website. Diese Computer Use-Funktionen machen Websites zu potenziellen Werkzeugen und erschließen Jahrzehnte an Inhalten, die bisher nicht per API zugänglich sind. 

Kurzzeit- und Langzeitspeicher

LLMs sagen das nächste Wort vorher basierend auf langen Wortsequenzen, die sie bereits kennen: dem Kontext. Dabei handelt es sich um eine Art Gedächtnis, aber nicht das einzige, das ein agentenbasiertes System braucht. Angenommen, ein Agent hat von einem Kartentool einige Dutzend Restaurants abgerufen. Alle Informationen in den Kontext zu laden, wäre ineffizient. Stattdessen legt er die Liste im Kurzzeitspeicher ab und ruft nur ein oder zwei Datensätze gleichzeitig ab – gefiltert nach Nutzerpräferenzen. Passen diese Restaurants nicht, greift der Agent erneut auf den Kurzzeitspeicher zu, statt einen neuen Toolaufruf zu starten.

Agenten müssen sich auch an frühere Interaktionen erinnern. Hat ein Nutzer letzte Woche seine Essenspräferenzen mitgeteilt, sollte er das diese Woche nicht wiederholen müssen. Der Langzeitspeicher bewahrt solche Informationen aus früheren Gesprächen. Agenten erstellen diese Langzeitgedächtnisse meist nicht selbst. Nach Abschluss einer Session analysiert ein separates KI-Modell das gesamte Gespräch und erzeugt neue Einträge oder aktualisiert bestehende. Dabei kommen LLM-Zusammenfassungen und Chunking zum Einsatz, das heißt, Dokumente werden in thematisch gruppierte Abschnitte aufgeteilt, um sie später effizienter abrufen zu können.

Observability und Monitoring

Agenten sind innovative Software-Systeme mit komplexem, zum Teil nicht-deterministischem Verhalten, was neue Ansätze beim Beobachten, Überwachen und Audit verlangt (Observability). Einige Fragen sind aus der klassischen IT bekannt: Laufen die Agenten schnell genug? Was kosten sie? Wie viele Tool-Aufrufe führen sie durch? Sind die Nutzer zufrieden? Doch bei Agenten kommen weitere Fragen hinzu, die sich heute noch nicht vollständig absehen lassen.

Sogenannte Traces können hier etwa eine Ende-zu-Ende-Ansicht jeder Session liefern und Schritt für Schritt zeigen, welche Aktionen der Agent durchgeführt hat und warum. Für Entwickler sind diese Informationen unverzichtbar: Sie zeigen, wie gut Agenten arbeiten und liefern die Grundlage für Verbesserungen.

Fazit

Agentenbasierte KI-Systeme bestehen aus sieben Kernkomponenten, die nahtlos zusammenspielen müssen: Entwicklungsframework, Modell-Ausführungsumgebung, Runtime für agentenbasierten Code, Tool-Kommunikation, Kurz- und Langzeitspeicher sowie Observability. Wer diese technischen Grundlagen versteht, schafft die Basis für eine erfolgreiche Implementierung und den zuverlässigen Betrieb von Agenten.

Über den Autor: Michael Hanisch ist Head of Technology bei AWS Deutschland.