KI-Agenten verstehen: Was hinter AI Agents wirklich steckt

Vom Sprachmodell zum Agenten

Ein Large Language Model erzeugt zunächst nur Ausgaben auf Basis seiner Eingaben.

Vereinfacht:

Das Modell kann beispielsweise erklären, wie man einen Termin im Kalender anlegt. Es kann den Termin dadurch aber noch nicht tatsächlich anlegen.

Dafür benötigt die Anwendung Zugriff auf ein Werkzeug.

Das Tool bildet dabei die kontrollierte Verbindung zwischen dem Sprachmodell und einem externen System.

Das ist die Grundlage vieler agentischer Systeme.

Tool Calling verstehen

Beim Tool Calling führt das Sprachmodell normalerweise nicht selbst beliebigen Programmcode aus.

Die Anwendung stellt dem Modell vielmehr eine Beschreibung der verfügbaren Funktionen zur Verfügung.

Vereinfacht könnte ein Tool so aussehen:

def get_customer(customer_id: int) -> dict:
    """Return customer information for a given customer ID."""
    ...

Dem Modell wird mitgeteilt, dass ein Tool get_customer existiert und eine customer_id erwartet.

Bei einer entsprechenden Anfrage kann das Modell anschließend entscheiden:

Tool:
get_customer

Arguments:
customer_id = 4711

Die eigentliche Anwendung führt den Funktionsaufruf aus und gibt das Ergebnis wieder an das Modell zurück.

Das Prinzip sieht damit so aus:

Das Sprachmodell entscheidet also, welches Werkzeug mit welchen Argumenten verwendet werden soll. Die Anwendung behält die Kontrolle über dessen tatsächliche Ausführung.

Was macht daraus einen Agenten?

Ein einzelner Tool-Aufruf macht noch nicht automatisch ein komplexes Agentensystem.

Interessanter wird es, wenn das Modell abhängig von Zwischenergebnissen weitere Schritte auswählen kann.

Angenommen, ein Mitarbeiter fragt:

Welche offenen Rechnungen hat Kunde 4711 und wurde er bereits per E-Mail erinnert?

Das System könnte nun:

1. Kundendaten abrufen
2. offene Rechnungen suchen
3. E-Mails durchsuchen
4. Ergebnisse bewerten
5. eine Antwort erzeugen

Dabei kann erst während der Bearbeitung entschieden werden, welcher nächste Schritt notwendig ist.

Das Modell befindet sich damit in einer Schleife aus Entscheiden, Handeln und Beobachten.

Diese Schleife ist ein wesentliches Merkmal agentischer Systeme.

Agent und Workflow sind nicht dasselbe

Ein klassischer Workflow besitzt einen weitgehend vorgegebenen Ablauf.

Die Reihenfolge ist durch die Software definiert.

Bei einem Agenten kann dagegen das Modell entscheiden, welche Aktion als Nächstes sinnvoll ist.

Workflow

A → B → C → D → E
Ablauf vorgegeben


Agent

Aufgabe
   ↓
LLM entscheidet
   ↓
Tool
   ↓
Ergebnis
   ↓
LLM entscheidet erneut
   ↓
...

Das bringt Flexibilität, reduziert aber gleichzeitig die Vorhersagbarkeit.

Wann ist ein Workflow besser?

Der Begriff „Agent“ klingt zunächst nach der moderneren Lösung. Technisch ist ein deterministischer Workflow jedoch häufig überlegen.

Wenn beispielsweise jede eingehende Rechnung immer nach denselben Regeln verarbeitet werden muss, gibt es wenig Grund, ein Sprachmodell über den nächsten Schritt entscheiden zu lassen.

Ein Agent wird interessanter, wenn der Lösungsweg nicht vollständig im Voraus bekannt ist.

Agentische Systeme sind häufig hybride Systeme

In produktiven Anwendungen findet man deshalb häufig weder einen vollständig deterministischen Workflow noch einen völlig autonomen Agenten.

Stattdessen werden beide Ansätze kombiniert.

Die Software legt beispielsweise fest:

• welche Tools verfügbar sind
• welche Daten verwendet werden dürfen
• welche Aktionen eine Bestätigung benötigen
• wie Ergebnisse validiert werden
• wann der Prozess beendet wird

Innerhalb dieser Grenzen kann das Modell Entscheidungen treffen.

Das ist für Unternehmensanwendungen meist wesentlich realistischer als die Vorstellung eines vollständig autonomen KI-Agenten.

Ein minimales Agentenprinzip in Python

Ohne ein konkretes Agenten-Framework lässt sich das Grundprinzip ungefähr so darstellen:

while True:
    result = llm.generate(
        messages=messages,
        tools=available_tools,
    )

    if result.tool_call is None:
        return result.text

    tool_result = execute_tool(
        result.tool_call.name,
        result.tool_call.arguments,
    )

    messages.append(result.tool_call)
    messages.append(tool_result)

Das Entscheidende ist die Schleife.

Das Modell erhält die Aufgabe und die verfügbaren Werkzeuge. Entscheidet es sich für einen Tool-Aufruf, führt die Anwendung diesen aus und gibt das Ergebnis zurück.

Anschließend entscheidet das Modell erneut.

Frameworks abstrahieren diesen Ablauf, das grundlegende Architekturprinzip bleibt jedoch ähnlich.

Wo kommen Frameworks wie Pydantic AI ins Spiel?

Für solche Systeme existieren inzwischen zahlreiche Frameworks.

Im Python-Umfeld gehören beispielsweise Pydantic AI, LangGraph oder die SDKs verschiedener Modellanbieter zu den möglichen Bausteinen.

Sie können Aufgaben übernehmen wie:

• Tool-Definitionen
• strukturierte Ein- und Ausgaben
• Agentenschleifen
• Validierung
• Modellkommunikation
• Zustandsverwaltung
• Fehlerbehandlung

Wichtig ist aber die Reihenfolge des Verständnisses:

LLM
 ↓
Tool Calling
 ↓
Agent Loop
 ↓
Orchestrierung
 ↓
Framework

Ein Framework ist nicht der Agent. Es hilft lediglich dabei, die benötigte Architektur umzusetzen.

Wo passt MCP hinein?

Das Model Context Protocol, kurz MCP, taucht inzwischen häufig im Zusammenhang mit Agenten auf.

MCP löst jedoch ein anderes Problem.

Wenn jede KI-Anwendung jede Datenquelle und jedes Tool individuell integrieren muss, entstehen zahlreiche proprietäre Verbindungen.

Vereinfacht:

KI-Anwendung → GitHub API
KI-Anwendung → Datenbank
KI-Anwendung → Dateisystem
KI-Anwendung → CRM
KI-Anwendung → internes Tool

MCP definiert eine standardisierte Möglichkeit, solche Fähigkeiten für KI-Anwendungen bereitzustellen.

Es ersetzt damit weder das Sprachmodell noch die Agentenlogik.

Auf MCP gehen wir deshalb in einem eigenen Artikel genauer ein.

Sicherheit wird bei Agenten wichtiger

Sobald ein Sprachmodell nicht mehr nur Text erzeugt, sondern Aktionen auslösen kann, verändert sich das Risikoprofil erheblich.

Ein Chatbot mit einer falschen Antwort ist problematisch.

Ein Agent mit Zugriff auf E-Mail, CRM, Datenbanken oder produktive Systeme kann dagegen tatsächlich Veränderungen durchführen.

Deshalb sollten Tools möglichst eng begrenzte Fähigkeiten besitzen.

Nicht:

execute_arbitrary_sql(query)

sondern beispielsweise:

get_customer(customer_id)
get_open_invoices(customer_id)

Je klarer die erlaubten Aktionen definiert sind, desto besser lässt sich das System kontrollieren.

Besonders kritische Aktionen können zusätzlich eine explizite menschliche Freigabe verlangen.

Fazit

KI-Agenten sind keine neue Form von Sprachmodell.

Sie entstehen, wenn ein Sprachmodell in eine Softwarearchitektur eingebettet wird, in der es Werkzeuge auswählen, Ergebnisse beobachten und darauf basierend weitere Entscheidungen treffen kann.

Das wichtigste Prinzip ist deshalb nicht „Autonomie“, sondern kontrollierte Entscheidungsfreiheit.

LLM
  ↓
Entscheidung
  ↓
Tool
  ↓
Ergebnis
  ↓
neue Entscheidung

Und genau deshalb ist nicht jeder Prozess ein guter Kandidat für einen Agenten.

Wo der Ablauf bekannt und zuverlässig definierbar ist, bleibt ein klassischer Workflow häufig die bessere Architektur. Agentische Ansätze werden dort interessant, wo Aufgaben variabel sind und der Lösungsweg erst während der Bearbeitung entsteht.

Sie möchten diese Themen systematisch verstehen und für den Einsatz im Unternehmen einordnen? Im dreitägigen Seminar KI im Unternehmen: Von ChatGPT zu RAG, Workflows und KI-Agenten werden die wichtigsten Konzepte und Architekturen praxisnah vermittelt.