Was ist ein KI-Agent, und wie unterscheidet er sich von einem Chatbot?

Das Wort Agent ist inzwischen so gedehnt, dass es fast alles bezeichnet, in dem ein Sprachmodell steckt. Das ist ein Marketingproblem, kein technisches. Darunter liegt eine konkrete und ziemlich enge Definition, und sie zu kennen lohnt sich, weil dieser Unterschied bestimmt, was schiefgehen kann.

Die Definition: ein Modell in einer Schleife mit Werkzeugen

Ein gewöhnlicher Chatbot tut eines: Er empfängt Text und gibt Text zurück. Was er «weiß», muss bereits im Modell oder im Prompt stehen.

Ein Agent fügt drei Dinge hinzu:

1. Werkzeuge. Gewöhnliche Funktionen, die das Modell aufrufen darf — eine Datenbank abfragen, eine HTTP-Anfrage senden, einen Befehl ausführen, eine Datei schreiben. Das Modell führt sie nicht aus; es gibt eine strukturierte Anfrage aus, euer Code führt sie aus, das Ergebnis kommt zurück.
2. Ein Ziel. Eine Aufgabe oberhalb eines einzelnen Schritts: «gleiche diese Rechnungen ab», nicht «lies Zeile 4».
3. Eine Schleife. Nach jedem Ergebnis entscheidet das Modell, was als Nächstes kommt. Es macht weiter, bis es das Ziel für erreicht hält, ein Schrittlimit trifft oder scheitert.

Diese Schleife ist die ganze Sache. Alles andere — Gedächtnis, Planung, Subagenten, Notizblöcke — ist eine Optimierung darauf.

Was Werkzeuge wirklich sind

Hier sind die meisten überrascht: Werkzeuge sind keine besonderen KI-Bauteile. Ein Werkzeug ist eine Funktion mit Namen, Beschreibung und Argumentschema. Man schreibt es an einem Nachmittag.

name: search_orders
description: Bestellungen nach Kunden-E-Mail oder Bestellnummer finden.
parameters:
  query: string
  limit: integer (Standard 20)

Das Modell sieht diese Beschreibung im Kontext, hält search_orders für passend und gibt einen Aufruf mit Argumenten aus. Eure Laufzeitumgebung führt die echte Funktion aus und liefert das Ergebnis als Text zurück. Das Modell fasst eure Datenbank nie an.

Zwei Folgerungen. Erstens: Ein Agent ist nur so fähig wie die Werkzeuge, die ihr ihm gebt — das Modell steuert das Urteil bei, welches Werkzeug und welche Argumente, mehr nicht. Zweitens: Die Werkzeugbeschreibung ist Teil des Prompts, und vage Beschreibungen erzeugen falsche Aufrufe, genau wie vage Anweisungen falsche Antworten erzeugen.

Das Model Context Protocol (MCP) existiert, damit nicht alle dieselben Werkzeugserver neu bauen. Es standardisiert, wie ein Server ankündigt, was er anbietet, sodass eine Implementierung viele Produkte bedienen kann.

Das Schwierige ist die Zuverlässigkeit

Agenten scheitern auf eine Weise, die in einer Demo leicht untergeht. Angenommen, jeder Schritt gelingt zu 95% — ein respektabler Wert für etwas Nichttriviales.

Am Modell ist nichts falsch. Die Fehler multiplizieren sich einfach. Deshalb sind Agenten, die in Produktion funktionieren, meist unspektakulär: fünf bis fünfzehn Schritte, eng begrenzte Domäne, ein menschlicher Kontrollpunkt an den teuren Stellen.

Das erklärt auch ein Muster, das in Herstellerleitfäden immer wiederkehrt: Nimm die einfachste Architektur, die funktioniert. Ein einzelner, gut formulierter Modellaufruf schlägt eine Kette; eine Kette schlägt eine autonome Schleife; eine autonome Schleife schlägt einen Schwarm. Jede Stufe kauft Flexibilität und bezahlt mit Vorhersagbarkeit.

Wo Agenten sich wirklich lohnen

Passende Aufgaben haben eine gemeinsame Form: Das Ziel ist klar, der Weg nicht, und das Ergebnis ist billig zu prüfen.

• Programmieren. Tests laufen durch oder nicht. Der Agent kann gegen ein objektives Signal iterieren.
• Recherche und Beschaffung. Material aus vielen Quellen sammeln, wo ohnehin ein Mensch das Ergebnis liest.
• Triage. Tickets einordnen und weiterleiten, Auffälligkeiten markieren, Erstentwürfe zur Prüfung schreiben.
• Datenabgleich. Datensätze zwischen Systemen abgleichen, deren Schemata fast — aber nicht ganz — übereinstimmen.

Schlecht passende Aufgaben sind das Spiegelbild: Prüfen ist teuer, Fehler sind unumkehrbar, oder der richtige Weg ist bereits bekannt — dann schreibt das Skript. Für einen nächtlichen Report braucht niemand einen Agenten.

Die Rechtegrenze

Weil ein Agent seine Schritte selbst wählt, lässt sich «was darf er» nicht durch Lesen des Codepfads beantworten. Es muss außerhalb des Modells durchgesetzt werden.

Praktisch heißt das:

• Breit lesen, eng schreiben. Er darf ansehen, was er braucht; jede zustandsändernde Aktion bekommt ein Tor.
• Freigabe bei Unumkehrbarem. Geld, externe Nachrichten, Löschungen, Produktions-Deployments.
• Budgets. Schritte, Laufzeit und Tokenausgaben deckeln. Ein in einer Schleife feststeckender Agent ist ein Abrechnungsvorfall.
• Ein abspielbares Protokoll. Jeder Werkzeugaufruf und jedes Ergebnis, gespeichert. Wenn etwas schiefgeht, muss «was hat er tatsächlich getan» in Sekunden beantwortbar sein.

Prompt Injection verdient eine eigene Zeile. Wenn euer Agent eine Webseite, eine E-Mail oder einen Pull-Request-Kommentar liest, kann eine angreifende Person Anweisungen in diesen Inhalt legen. Das Modell kann eure Anweisungen nicht zuverlässig von denen unterscheiden, die es gerade gelesen hat. Die Abwehr ist kein besserer Prompt — sie besteht darin, dem Agenten die Befugnis erst gar nicht zu geben.

Marketing von Substanz trennen

Bei einem Produkt, das sich «agentisch» nennt, trennen drei Fragen das Echte vom Umetikettierten:

1. Welche Werkzeuge kann es genau aufrufen? Eine lesbare Liste oder Handbewegungen?
2. Was passiert, wenn ein Schritt scheitert? Wiederholen, eskalieren, anhalten — oder stillschweigend eine plausible falsche Antwort liefern?
3. Was darf es ohne zu fragen? Lautet die Antwort «alles», ist das keine Autonomie, sondern unbegrenzte Haftung.

Ein Agent ist kein klügerer Chatbot. Er ist ein Chatbot mit der Hand am Steuer, und die Technik, auf die es ankommt, dreht sich fast ausschließlich um diese Hand.