KIGenAI & LLMs

Was ein KI-Agent wirklich ist und wo der Hype endet

Der Begriff „KI-Agent" wird auf alles angewendet, vom einfachen Chatbot bis zur autonomen Software, die Flüge bucht und Code schreibt. Dieser Artikel räumt mit dem Lärm auf und erklärt, was Agenten tatsächlich sind, wie sie technisch funktionieren und wann ihr Einsatz sich lohnt.

🎙️

Podcast anhören

4 min

Das Wort „Agent" wurde in den letzten zwei Jahren an so viele Produkte geklebt, dass es kaum noch Bedeutung hat. Salesforce nennt seine Plattform Agentforce eine Suite autonomer Agenten. Microsoft baut „Copilot-Agenten" in Teams und SharePoint ein. OpenAI vermarktet Agenten im Operator-Stil über seine API. Zieht man das Branding ab, liegt darunter ein echtes technisches Konzept, das sich tatsächlich von einem gewöhnlichen Chatbot unterscheidet und tatsächlich schwerer gut zu betreiben ist.

Das Konzept, das man verstehen sollte, lautet: Ein KI-Agent ist ein Softwaresystem, das mit einem Sprachmodell in einer Schleife entscheidet, welche Aktion als nächste kommt, diese Aktion gegen echte Tools oder Daten ausführt, das Ergebnis beobachtet und dann erneut entscheidet. Die Schleife läuft, bis die Aufgabe erledigt ist oder der Agent aufgibt. Das ist alles. Alles andere ist Marketing obendrauf.

Warum das für Führungskräfte und Entscheider relevant ist

Die meisten Interaktionen mit KI im Arbeitsalltag bestehen aus einem einzigen Durchgang: Sie tippen einen Prompt, bekommen eine Antwort, kopieren sie in ein Dokument. Dieses Modell funktioniert gut für Zusammenfassungen, Textentwürfe und schnelle Analysen. Es bricht zusammen, sobald eine Aufgabe mehrere Schritte, bedingte Logik oder Zugriff auf laufende Systeme verlangt.

Stellen Sie sich vor, Sie bitten eine KI, den Customer Churn Ihres Unternehmens für Q3 zu analysieren, die relevanten Salesforce-Datensätze zu ziehen, sie mit dem Volumen der Support-Tickets in Zendesk abzugleichen und ein einseitiges Memo mit Empfehlungen zu entwerfen. Ein Chatbot kann das nicht. Er hat keinen Zugriff auf diese Systeme und keine Möglichkeit zu entscheiden, was zu tun ist, wenn die Salesforce-API einen Fehler zurückgibt. Ein sauber gebauter Agent kann jeden dieser Schritte nacheinander abarbeiten und sich unterwegs anpassen.

Das ist relevant, weil die Produktivitätsgrenze von Single-Turn-KI real ist. Unternehmen, die Agenten für strukturierte Workflows eingesetzt haben, darunter JP Morgan für die Dokumentenprüfung und Klarna für das Routing im Kundenservice, berichten, dass der Wert genau aus der Automatisierung über mehrere verbundene Schritte entsteht, nicht daraus, dass eine einzelne KI-Antwort besser wäre. Die Unterscheidung zwischen „KI, die Fragen beantwortet" und „KI, die Prozesse abschließt" ist die Grenze zwischen Tool und Agent.

Wie es tatsächlich funktioniert: die Mechanik

Im Zentrum jedes Agenten steht eine Reasoning-Schleife. Das Sprachmodell erhält ein Ziel und eine Beschreibung der verfügbaren Tools. Es erzeugt einen Plan, oft nur einen unmittelbaren Schritt. Die umgebende Software führt diesen Schritt aus, sei es eine Websuche, eine Datenbankabfrage oder ein API-Call. Das Ergebnis geht zurück an das Modell. Das Modell entscheidet, was als Nächstes passiert.

Ein konkretes Beispiel: Sie bitten einen Agenten, die drei aktuellsten Analystenberichte zur Halbleiternachfrage zu finden und die zentralen Widersprüche zusammenzufassen. Der Agent ruft ein Websuche-Tool auf, liest die zurückgegebenen URLs, entscheidet, welche glaubwürdig wirken, ruft für jede ein Tool zum Lesen von Dokumenten auf, verdichtet die Inhalte und erzeugt eine strukturierte Ausgabe. Läuft eine URL in einen Timeout, versucht er es erneut oder überspringt sie. Sie sehen nur das fertige Memo.

Die Tools, die einem Agenten zur Verfügung stehen, können fast alles sein, was eine API hat: Kalender, Umgebungen zur Codeausführung, interne Datenbanken, E-Mail, Browsersteuerung. Das Modell muss auf diese Tools nicht speziell trainiert sein; es braucht eine klare schriftliche Beschreibung, was jedes Tool tut und welche Eingaben es erwartet. Deshalb ist die Qualität der Tool-Beschreibungen in der Praxis so wichtig und genau daran scheitern reale Deployments häufig.

Dann gibt es noch die Frage nach dem Gedächtnis. Standardmäßig haben Sprachmodelle zwischen Sessions kein Gedächtnis. Agenten kann man ein Kurzzeitgedächtnis geben (die laufende Konversation), ein längerfristiges Gedächtnis in einer Vektordatenbank und Zugriff auf strukturierte Datensätze. Zu steuern, was der Agent behält und was er vergisst, ist eine Designentscheidung mit echten Folgen für Genauigkeit und Datenschutz.

Die spezielle Rolle von Reasoning-Modellen

Standard-Sprachmodelle erzeugen eine Antwort in einem einzigen Forward Pass. Reasoning-Modelle wie die o-Serie von OpenAI oder Gemini 2.0 Flash Thinking von Google DeepMind erzeugen eine interne Gedankenkette, bevor sie eine Ausgabe produzieren. Bei Agentenaufgaben, die mehrstufige Planung oder Fehlerkorrektur verlangen, macht das einen Unterschied. Ein Reasoning-Modell erkennt eigene Fehler mitten in der Schleife eher und korrigiert nach. Bei einfachen Aufgaben rechtfertigen die zusätzlichen Compute-Kosten das nicht. Modelltyp und Aufgabenkomplexität aufeinander abzustimmen ist eine echte Engineering-Entscheidung, keine Voreinstellung.

Wann Agenten sinnvoll sind und wann nicht

Agenten sind eine Überlegung wert, wenn die Aufgabe mehrstufig ist, wenn sie Echtzeitdaten braucht, die das Modell nicht gespeichert haben kann, und wenn die Kosten einer falschen Aktion reversibel sind. Dokumentenrecherche, Wettbewerbsbeobachtung, strukturierte Datenerhebung und Pipelines zur Codegenerierung sind gute Kandidaten. Auch die Ökonomie kann aufgehen: Ein Agent, der über Nacht eine vierstündige Recherche zu API-Kosten durchführt, ersetzt womöglich mehrere Stunden Analystenzeit.

Agenten passen schlecht, wenn die Aufgabe wirklich einfach ist, wenn Fehler kaum rückgängig zu machen sind oder wenn das System an jedem Entscheidungspunkt prüfbar sein muss. Ein Agent, der entscheidet, E-Mails an Kunden zu senden, Datenbankeinträge zu löschen oder Finanztransaktionen auszuführen, ist ein Agent, bei dem ein einzelner Denkfehler Folgen hat, die sich aufschaukeln. In diesen Bereichen ist die richtige Architektur ein Mensch, der vorgeschlagene Aktionen vor der Ausführung prüft, manchmal „Human in the Loop" genannt, und das ist weniger eine Einschränkung als eine sinnvolle Begrenzung.

Der Fehlermodus, auf den man achten sollte, ist das, was Praktiker „Agent Drift" nennen: Das Modell verfolgt einen plausibel aussehenden Pfad, der vom eigentlichen Ziel abweicht, und verbrennt Compute und API-Calls für Aktionen, die nichts zum Ergebnis beitragen. Das passiert häufiger bei vagen Zielen und bei langen Aufgabenhorizonten. Die Lösung: Ziele enger zerlegen und explizite Checkpoints setzen, an denen ein Mensch oder ein zweites Modell den Fortschritt prüft.

Noch ein ehrlicher Punkt zum aktuellen Stand: In den meisten Anbieter-Demos erledigen Agenten ihre Aufgaben sauber. In der Produktion ist es unordentlicher. Tool-Calls scheitern, APIs ändern sich, Modelle halluzinieren Tool-Syntax. Teams, die Agenten ernsthaft bauen, etwa bei Palantir oder in den KI-Bereichen von Accenture, berichten, dass die Engineering-Arbeit rund um Zuverlässigkeit, Retry-Logik und Fehlerbehandlung oft größer ist als die Arbeit am Modell selbst.

Agenten sind eine reale und nützliche Kategorie von KI-Systemen. Sie sind auch anspruchsvoll, wenn man sie gut betreiben will, und die Lücke zwischen einer polierten Demo und einem verlässlichen Produktions-Workflow ist größer, als die meisten Anbietermaterialien vermuten lassen. Die praktische Frage ist nicht, ob Agenten beeindruckend sind, sondern ob ein bestimmter Workflow die Struktur, das Tooling und die Fehlertoleranz mitbringt, damit sich der Bau eines Agenten lohnt.

Mehr dazu

Die Lektionen, die diesen Artikel weiterführen, frei zugänglich.

  1. 1Was ein KI-Agent wirklich ist: der Loop aus perceive, plan, act, observeAI Agents: Design, Aufbau und Betrieb
  2. 2Agents vs. Workflows vs. Automations: das richtige Maß an AutonomieAI Agents: Design, Aufbau und Betrieb
  3. 3Tools und Function Calling: Ihrem Agenten Hände gebenAI Agents: Design, Aufbau und Betrieb
  4. 4Guardrails, Permissions und Human-in-the-LoopAI Agents: Design, Aufbau und Betrieb
  5. 5Kosten, Latenz und Zuverlässigkeit: Agents in Produktion bringenAI Agents: Design, Aufbau und Betrieb

Artikel gelesen?

Bestätigen Sie Ihre Lektüre, um XP zu sammeln und Ihr Radar zu füttern.