Agentic AI: Warum KI-Systeme plötzlich eigenständig handeln können – Grundlagen, die zuwenig erklärt werden

Montagmorgen. Eine KI erhält die Aufgabe: „Analysiere alle Kundenbeschwerden der letzten Woche,
prüfe ob die häufigsten Probleme in den Systemlogs auftauchen, und schreibe eine
Zusammenfassung für das Management.“ Zwei Stunden später liegt der Bericht vor – strukturiert,
vollständig, mit Quellenverweisen aus dem Ticketsystem.
Kein Mensch hat dabei geklickt, kopiert oder überwacht.
Das ist Agentic AI – und viele staunen, als wäre das Magie. Es ist keine Magie. Es sind drei konkrete
Fähigkeiten, die moderne Large Language Models (LLMs) mitbringen. Wer diese Grundlagen versteht,
versteht auch, warum der aktuelle Hype technisch berechtigt ist – und wo die Grenzen liegen.

Was ein LLM wirklich ist – und was das mit Agency zu
tun hat

Ein LLM ist, vereinfacht gesagt, eine Maschine, die auf Basis eines riesigen Trainingsdatensatzes
lernt, welches Wort (genauer: welches „Token“) in einem gegebenen Kontext am wahrscheinlichsten
als Nächstes kommt. Aus diesem scheinbar simplen Mechanismus entstehen bei ausreichend
Modellgröße und Trainingsdaten überraschende Fähigkeiten, die niemand explizit einprogrammiert
hat: Schlussfolgern, Planung, Reflexion.
Man nennt das emergente Fähigkeiten, d.h. Eigenschaften, die ab einem bestimmten
Schwellenwert „auftauchen“, ohne direkt trainiert worden zu sein.

Was bis vor wenigen Jahren noch fehlte: die Hände. Das Modell konnte denken – aber nicht handeln.

Die drei Säulen von Agentic AI

Agentic AI entsteht, wenn ein LLM mit drei Fähigkeiten ausgestattet wird: Werkzeuge, Planung und
Gedächtnis. Keine dieser Fähigkeiten allein macht einen Agenten. Zusammen ergeben sie ein
System, das eigenständig mehrstufige Aufgaben lösen kann.

Säule 1: Werkzeuge – die Hände des Agenten

Werkzeuge oder Tool Use (auch „Function Calling“ genannt) ist der technische Kernmechanismus,
der LLMs von Chatbots zu Agenten verwandelt. Das Prinzip ist überraschend einfach – und lässt sich
in drei Fragen aufschlüsseln:

• Wie weiß das Modell von den verfügbaren Werkzeugen?
• Wie wählt es das richtige Werkzeug für eine Aufgabe aus?
• Wie benutzt es das Werkzeug (als Tool) korrekt?

Die ersten Tools war die einfache Suche im Internet über Suchmaschinen. Nachdem LLMs aber auch
sehr gut Source Code schreiben können, war bald klar, dass man auch Werkzeuge zur Manipulation
von Files und anderen Datenquellen haben möchte.
Die Kombination hat sich als wirkungsvoller herausgestellt, als dies zunächst ausgesehen hat.

Die Speisekarte: Wie das LLM seine Tools kennt

Dem LLM wird zu Beginn einer Aufgabe eine Liste verfügbarer Werkzeuge mitgegeben – aber nicht
als rein technische API-Dokumentation, sondern als lesbare Beschreibung in natürlicher Sprache.
Jedes Tool bekommt einen Namen, eine Erklärung wofür es da ist, und eine Beschreibung der
Parameter, die es erwartet. Das sieht konzeptuell z.B. so aus:

Tool-Name	Beschreibung	Parameter
lade_tickets	Lädt Support-Tickets aus dem CRM-System	Zeitraum, Typ (Beschwerde/Anfrage), Status
durchsuche_logs	Durchsucht Systemlogs nach einem Suchbegriff	Suchbegriff, Zeitraum, LogLevel
sende_email	Sendet eine E-Mail über den Unternehmensverteiler	Empfänger, Betreff, Inhalt
erstelle_dokument	Erstellt ein formatiertes Dokument und speichert es	Titel, Inhalt, Speicherort

Das LLM liest diese Beschreibungen wie eine Speisekarte – und entscheidet anhand der Aufgabe und
der Tool-Beschreibungen, ob eines der verfügbaren Werkzeuge in der aktuellen Situation passt. Die
Qualität dieser Beschreibungen ist dabei entscheidend: Ein Tool mit einer vagen Beschreibung wird
das Modell falsch oder gar nicht einsetzen.

Die Entscheidung: Wie das LLM das richtige Tool wählt

Das Modell trifft die Tool-Auswahl nicht durch eine separate Logik oder ein Regelwerk – es ist reines
Sprachverständnis. Das LLM liest gleichzeitig die Aufgabe und die Tool-Beschreibungen und schreibt
sich einen Plan auf um zu entscheiden, welches Tool am besten zur aktuellen Situation passt. Dabei
berücksichtigt es:

• Passt das Tool zur Aufgabe? – „Ich brauche aktuelle Daten“ → kein Rückgriff auf
  Trainingswissen, sondern Tool-Aufruf
• Welche Parameter braucht das Tool? – Das Modell extrahiert die benötigten Werte aus der
  Aufgabenbeschreibung oder dem bisherigen Kontext
• Ist das Tool gerade sinnvoll? – Das Modell kann auch entscheiden, kein Tool aufzurufen und
  direkt zu antworten, wenn es bereits alle nötigen Informationen hat

Wichtig: Das Modell kann aus einer Liste von zehn oder zwanzig Tools das jeweils passende
auswählen – aber es wählt immer nur unter den Tools, die ihm tatsächlich mitgegeben wurden.

Der Aufruf: Wie das LLM ein Tool aktiviert

Wenn das Modell ein Tool aufrufen möchte, gibt es keine Antwort in natürlicher Sprache zurück,
sondern eine strukturierte Anfrage: Tool-Name und die konkreten Parameter als klar
maschinenlesbares Format. Konzeptuell:

Tool = lade_tickets
Parameter = Zeitraum = „letzte 7 Tage“
Typ = „Beschwerde“
Status = „offen“

Die umgebende Anwendung empfängt diesen Aufruf, führt ihn aus – also fragt wirklich das CRMSystem ab – und gibt das Ergebnis ans LLM zurück. Das Modell verarbeitet das Ergebnis und
entscheidet dann: Reicht das? Brauche ich noch ein weiteres Tool? Oder kann ich jetzt die Aufgabe
abschließen?
Dieser Kreislauf – Aufgabe → Tool-Aufruf → Ergebnis → nächste Entscheidung – kann sich
mehrfach wiederholen, bis die Aufgabe vollständig erledigt ist.
Ein wichtiges Detail für sicherheitsbewusste Leser: Das LLM führt Tools nicht selbst aus. Es
schreibt einen strukturierten Aufrufauftrag – die Ausführung übernimmt die Anwendung, die das LLM
aufgerufen hat. Diese entscheidet, ob und wie die Anfrage tatsächlich umgesetzt wird. Dieser
Mechanismus ist keine technische Einschränkung, sondern bewusste Architektur: So behält man die
vollständige Kontrolle darüber, welche Aktionen überhaupt möglich sind, welche Systeme erreichbar
sind und wofür man welche Berechtigungen einsetzt.

Säule 2: Planung – das Denken des Agenten

Tool Use allein reicht nicht. Eine komplexe Aufgabe besteht aus mehreren Schritten, die in der
richtigen Reihenfolge ausgeführt werden müssen, voneinander abhängen und sich gegenseitig
beeinflussen. Dafür braucht ein Agent Planung.

Moderne LLMs können durch eine einfache Technik – das explizite „Schritt für Schritt denken“ oder
auch als Chain of Thought bezeichnet – bei komplexen Aufgaben messbar besser werden. Das
Modell wird nicht nur nach der Antwort gefragt, sondern auch nach dem Weg zur Antwort. Das klingt
banal, verdoppelt aber in Benchmarks die Qualität bei mehrstufigen Problemen.

Das wichtigste Architekturmuster für Agenten baut auf das ReAct-Muster (Reasoning + Acting). Es
beschreibt einen Denk-Handlungs-Kreislauf:

Gedanke: Was brauche ich als nächstes?
Aktion: [Tool-Aufruf mit Parametern]
Beobachtung: [Ergebnis des Tools]
Gedanke: Was bedeutet dieses Ergebnis? Was ist der nächste Schritt?
…
Ein konkretes Beispiel für unser Einstiegsszenario:

Gedanke: Ich brauche die Kundenbeschwerden der letzten Woche.
Aktion: [Tool: lade_tickets, Zeitraum: letzte 7 Tage, Typ: Beschwerde]
Beobachtung: [247 Tickets, häufigste Kategorie: „Login-Probleme“ (38%)]

Gedanke: Login-Probleme sind die häufigste Kategorie.
Ich prüfe, ob es dazu Einträge in den Systemlogs gibt.
Aktion: [Tool: durchsuche_logs, Suchbegriff: „authentication error“, Zeitraum: 7 T
Beobachtung: [3.240 Fehlereinträge – deutlicher Anstieg ab Dienstag]

Gedanke: Zusammenhang gefunden. Ich kann jetzt den Bericht schreiben.
Aktion: [Tool: erstelle_dokument, Inhalt: …]

Der Agent „denkt laut“ – und das ist kein Gimmick. Es ist technisch entscheidend, weil das Modell so
Zwischenschritte explizit machen und darauf aufbauen kann, anstatt bei einem komplexen Problem
direkt eine (schlecht durchdachte) Antwort zu generieren.

Säule 3: Gedächtnis – das Wissen des Agenten

LLMs haben von Natur aus kein dauerhaftes Gedächtnis. Mit dem Ende einer Sitzung ist alles
vergessen. Agenten-Systeme bauen deshalb künstliches Gedächtnis auf verschiedenen Ebenen auf.

Das Context Window ist dabei das Arbeitsgedächtnis eines Agenten: alles, was das Modell im
aktuellen „Auftrag“ sieht – die ursprüngliche Aufgabe, alle bisherigen Tool-Ergebnisse, alle
Zwischengedanken. Je größer dieses Fenster, desto komplexere Aufgaben kann ein Agent
theoretisch bearbeiten. Aktuelle Spitzenmodelle verfügen über Context Windows von mehreren
hunderttausend bis zu einer Million Tokens – genug für ganze Bücher an Text. Das war vor drei
Jahren noch undenkbar.

Das Langzeitgedächtnis über Datenbanken (RAG) oder durch den Zugriff auf einen Filestorage etc.
erlaubt Agenten, auf Wissensbasen zuzugreifen, die weit größer sind als das Arbeitsgedächtnis:
interne Dokumente, Handbücher, historische Projektdaten. Der Agent sucht gezielt, was er gerade
braucht – ähnlich wie ein Mensch, der nicht alles auswendig weiß, aber weiß, wo er nachschaut.
Neben Wissen können dort auch Regeln für die Verarbeitung des Wissens abgelegt sein.

Fazit: Oder – Warum geht das erst jetzt?

Das ist keine Selbstverständlichkeit. Noch vor drei bis vier Jahren hätten dieselben Mechanismen bei
schwächeren Modellen überwiegend nicht funktioniert. Was hat sich verändert?

• Skalierung: Mehr Parameter, mehr Trainingsdaten – ab einem bestimmten Schwellenwert
  entstehen emergente Fähigkeiten wie zuverlässiges Instruction Following.
  
• RLHF: Modelle wurden durch menschliches Feedback trainiert, nützliche und präzise Antworten
  zu priorisieren – das verbessert die Zuverlässigkeit bei Tool-Aufrufen.
  
• Tool-Use-Training: Aktuelle Topmodelle wurden explizit darauf trainiert, strukturierte Aufrufe
  zuverlässig zu generieren und die Ergebnisse korrekt zu verarbeiten.
  
• Größere Context Windows: Erst mit ausreichend Arbeitsgedächtnis können mehrstufige
  Agenten-Aufgaben überhaupt sinnvoll bearbeitet werden.

Der Durchbruch war kein einzelner Moment. Es war ein graduelles Überschreiten mehrerer Schwellen
gleichzeitig – bei Modellgröße, Trainingsqualität und Kontextlänge.