KI-Agenten unter der Haube: Was macht einen Agent wirklich aus?

Wenn man über Agenten redet, wird wie selbstverständlich davon ausgegangen, dass man sie mit Tools wie LangChain, LangGraph, CrewAI oder AutoGen baut. Das macht auch absolut Sinn.

Wenn man aber gerade erst beginnt, sich mit Agenten zu beschäftigen, dann empfehle ich, zumindest einmal einen Agenten von Hand zu implementieren bzw. seine Komponenten und ihr Zusammenspiel ohne Framework zu betrachten. Ich für meinen Teil habe damit sehr gute Erfahrungen gemacht. Man entwickelt ein tieferes Verständnis davon, was einen Agenten ausmacht und versteht auch die Abstraktionen der Frameworks besser.

Dieser Post beschreibt, was ich dabei gelernt habe.

Was macht einen Agent aus?

Das sind ganze vier Kernkomponenten und eine Konfiguration. Fehlt eines davon, ist es kein Agent.

LLM — das Gehirn

Das LLM ist die Steuerungseinheit. Es plant und entscheidet, welches Tool aufgerufen wird, mit welchen Parametern, und ob das Ergebnis ausreicht oder weitere Schritte nötig sind.

Das ist der zentrale Unterschied zu einem regelbasierten System: Die Entscheidungslogik ist nicht programmiert, sondern wird vom Sprachmodell dynamisch generiert. Das macht den Agenten mächtig — und gleichzeitig nicht-deterministisch. Derselbe Input kann zu unterschiedlichen Pfaden führen. Deshalb sind Evaluation, Guardrails und Tracing bei Agenten nicht optional.

Tools — die Hände

Tools sind die Schnittstelle zwischen dem LLM und der Außenwelt. Ohne Tools kann ein LLM nur Text generieren — es kann nicht handeln.

Der Mechanismus ist ein Protokoll: Das LLM gibt einen strukturierten Tool-Call zurück (Name + Parameter als JSON), dein Code führt die Funktion aus und gibt das Ergebnis als Observation zurück. Das LLM führt nie selbst ein Tool aus — es sagt nur, was es aufrufen möchte.

Ein Detail, das in der Praxis wichtiger ist als erwartet: Die Qualität der Tool-Beschreibungen entscheidet über die Qualität der Tool-Auswahl. Vage Beschreibungen führen zu falschen Tool-Calls. Gute Docstrings sind bei Agenten kein Nice-to-have — sie sind funktionaler Code.

ReAct Loop — das Herzstück

Der Loop ist das definierende Merkmal eines Agenten. Er interagiert mit dem LLM, den Tools und dem State, so lange, bis das LLM die finale Antwort ermittelt hat.

Das Konzept stammt aus dem Paper ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022): Das LLM alterniert zwischen Nachdenken (Reason) und Handeln (Act). Nach jeder Aktion beobachtet es das Ergebnis und entscheidet, ob es weitermachen oder antworten soll.

Als Pseudocode:

for step in range(max_steps):
    response = llm.call(messages, tools)

    if response.stop_reason == "end_turn":
        return response.text          # Fertig

    if response.stop_reason == "tool_use":
        result = execute_tool(response.tool_call)
        messages.append(result)        # Weiter im Loop

Das ist der gesamte Agent-Loop. Kein Framework, keine Magie — eine Schleife, die aufhört, wenn das LLM entscheidet, dass es fertig ist. max_steps ist ein Guardrail gegen Endlosschleifen.

State — das Gedächtnis

Der Agent muss wissen, was in vorherigen Loop-Schritten passiert ist — welche Tools er aufgerufen hat, welche Ergebnisse er bekam, was er bereits versucht hat. Ohne State wäre jeder Loop-Durchlauf ein Neuanfang — das LLM könnte nicht auf Ergebnisse aufbauen und dadurch seine Antwort nicht verfeinern.

In der einfachsten Form ist State eine Python-Liste: messages. Bei jedem Loop-Durchlauf wächst sie um die Assistant-Response und das Tool-Ergebnis. Das ist die gesamte Konversationshistorie — und gleichzeitig der Input für den nächsten LLM-Call.

Das hat eine direkte Konsequenz für Kosten und Latenz: Bei jedem LLM-Call wird die gesamte messages-Liste als Input mitgeschickt. Mehr Schritte bedeuten mehr Input-Tokens. Das LLM ist die teuerste Stelle im Agenten — und die Kosten wachsen mit jedem Loop-Durchlauf.

System Prompt — die Persönlichkeit

Der System Prompt ist keine Architekturkomponente — aber essentielle Konfiguration. Ein Agent ohne System Prompt funktioniert technisch (er loopt, nutzt Tools, hat State), ist aber unspezialisiert.

Der System Prompt macht aus einem generischen LLM-in-a-Loop einen spezialisierten Agenten: Welche Rolle hat er? Wie soll er antworten? Welche Constraints gelten? Welche Tool-Reihenfolge ist bevorzugt?

In der Grafik oben ist er deshalb bewusst anders dargestellt — kleiner, gestrichelt, in einer anderen Farbe. Er gehört dazu, ist aber eine andere Kategorie als die vier Kernkomponenten.

Planning und Reflection — optional, nicht essentiell

Zwei Muster tauchen in fast jeder Agenten-Diskussion auf: Planning und Reflection. Beide sind nützlich, aber keines davon ist eine Kernkomponente.

Planning macht implizites LLM-Verhalten explizit. Jedes hinreichend gute LLM plant ohnehin — es überlegt intern “zuerst X, dann Y”. Explizites Planning erzwingt einen strukturierten Plan als eigenen Schritt, bevor die Ausführung beginnt. Das macht den Plan inspizierbar und kontrollierbar. Aber es ist eine Architekturentscheidung, kein Muss.

Reflection ist eine dedizierte Bewertung des fertigen Ergebnisses. Anders als die Mikro-Bewertung im Loop (“Reicht das oder brauche ich mehr?”) prüft Reflection das Endergebnis gegen definierte Kriterien. Auch das ist eine bewusste Entscheidung — ohne einen expliziten Bewertungsschritt passiert keine systematische Qualitätsprüfung.

Die Entscheidung, ob man Planning und Reflection braucht, hängt vom Use Case ab. Für eine einfache Tool-Abfrage reichen die vier Kernkomponenten. Für eine komplexe Aufgabe mit hohen Qualitätsanforderungen lohnt sich beides.

Einordnung: Agent vs. Workflow vs. Chain

Wenn man die vier Komponenten verstanden hat, wird die Abgrenzung zu einfacheren Mustern klar. Anthropic beschreibt das in Building effective agents so:

Chain:     [Input] → [Schritt A] → [Schritt B] → [Output]
                     (fest verdrahtet)

Workflow:  [Input] → [Router] → [Pfad A] oder [Pfad B] → [Output]
                     (Code entscheidet)

Agent:     [Input] → [Denken → Handeln → Beobachten] ↻ → [Output]
                     (LLM entscheidet, Loop)

Bei einer Chain ist der Ablauf fest verdrahtet. Bei einem Workflow entscheidet Code, welcher Pfad genommen wird. Bei einem Agenten entscheidet das LLM — zur Laufzeit, basierend auf dem, was es sieht. Der ReAct Loop ist die Mechanik, die das ermöglicht.

Und damit eine wichtige Einsicht, die Anthropic selbst formuliert: Nicht jede Aufgabe braucht einen Agenten. Viele Aufgaben sind mit einem gut prompteten LLM oder einem einfachen Workflow besser und günstiger gelöst. Agenten lohnen sich, wenn der Ablauf nicht vorhersagbar ist und das System auf Zwischenergebnisse reagieren muss.

Warum das wichtig ist

Wer diese Mechanik einmal durchdrungen hat, versteht besser, was LangGraph unter der Haube tut. Der Loop wird zum StateGraph, die Python-Liste wird zum TypedDict mit Checkpointing, die Tool-Registrierung wird zum MCP-Standard. Aber die Grundstruktur bleibt dieselbe.

Das ist auch der Grund, warum ich empfehle: Analysiere einen Agenten einmal ohne Framework. Nicht für die Produktion — dafür gibt es bessere Werkzeuge. Sondern um zu verstehen, was diese Werkzeuge abstrahieren.

Zurück zu unserer Frage vom Anfang. Was ist ein Agent? Was macht ihn aus? Das ist gar nicht so leicht zu beschreiben. Das folgende Gleichnis trifft es aus meiner Sicht sehr gut:

Musiker, Dirigent, Instrumente und Partitur kommen zu einer Probe oder einem Konzert zusammen. Sie formieren sich zu einem Orchester. Während dieser Zeit machen sie das, was ein Orchester ausmacht: Musik. Nach dem Konzert geht jeder seiner Wege. Das Orchester löst sich auf. Es existiert nur noch als Konzept.

Genauso ist es mit einem Agenten. Während seine Komponenten interagieren, entstehen die Fähigkeiten, die ihn ausmachen. Davor und danach ist er nur ein Konzept.

Code und Details: Die vollständige Implementierung — vom Konzept über ein isoliertes Tool-Use-Experiment bis zum lauffähigen ReAct-Agenten mit Tests — ist auf GitHub dokumentiert: → agentic-ai / Phase 1: Fundamentals

Ich bin ML Engineer mit Fokus auf Self-Hosted AI und Datensouveränität. Ich helfe Unternehmen im DACH-Raum, ML- und AI-Systeme auf eigener Infrastruktur zu betreiben. Offen für Austausch und spannende Projekte — schreib mir auf LinkedIn.