RAG oder AI-Agent? Wann Retrieval reicht und wann es Werkzeuge braucht

Kaum eine Architekturfrage stellt sich bei AI-Projekten so regelmäßig wie diese: Reicht RAG, also Retrieval Augmented Generation, oder braucht es einen AI-Agent mit Werkzeugen. Beide Ansätze nutzen dieselben Modelle, führen aber zu sehr unterschiedlichen Systemen, in Aufwand, Risiko und laufenden Kosten.

Die Entscheidung wird in der Praxis oft falsch herum getroffen. Entweder aus Vorsicht: Man baut RAG, obwohl die Aufgabe Handlungen verlangt, und wundert sich, dass die Nutzer nach der Antwort trotzdem alles selbst erledigen müssen. Oder aus Ambition: Man baut einen Agenten für eine Aufgabe, die eine gute Suche mit Antwortgenerierung vollständig gelöst hätte, und bezahlt dauerhaft für Komplexität ohne Gegenwert.

Was RAG gut kann

RAG beantwortet Fragen auf einer Wissensbasis. Die Anfrage wird in eine Suche übersetzt, die relevantesten Passagen aus Dokumenten, Wikis oder Datenbanken werden geholt, und das Modell formuliert daraus eine Antwort mit Quellenbezug. Für eine ganze Klasse von Aufgaben ist das die richtige Architektur: interne Wissenssuche, Fragen zu Richtlinien und Verträgen, Produktauskünfte, Zusammenfassungen über Dokumentbestände.

Die Stärken sind strukturell. Ein RAG-System ist vorhersehbar: pro Anfrage ein Retrieval und ein oder zwei Modellaufrufe, damit stabile Kosten und stabile Antwortzeiten. Es ist gut prüfbar, weil sich Frage, gefundene Quellen und Antwort direkt gegenüberstellen lassen. Und es ist risikoarm, weil es nur liest. Ein falsches Suchergebnis erzeugt eine schwache Antwort, aber keine falsche Buchung.

Wo Retrieval endet

Die Grenze von RAG verläuft dort, wo eine Antwort nicht mehr genügt. Das betrifft drei wiederkehrende Situationen:

• Mehrstufige Aufgaben: Wenn die Lösung mehrere abhängige Schritte verlangt, etwa erst Daten nachschlagen, dann rechnen, dann das Ergebnis prüfen, reicht ein einzelner Durchlauf aus Suche und Antwort nicht mehr.
• Aktueller Zustand statt Dokumente: Lagerstände, Ticketstatus oder Termine leben in Systemen, nicht in Textsammlungen. Wer sie über einen Dokumentenindex beantwortet, antwortet aus der Vergangenheit.
• Aktionen: Sobald die Aufgabe lautet, etwas anzulegen, zu ändern, zu senden oder zu buchen, ist Retrieval per Definition am Ende. Lesen ersetzt kein Handeln.

Ein Agent adressiert genau das: Er plant Schritte, ruft Werkzeuge auf, bewertet Zwischenergebnisse und arbeitet weiter, bis die Aufgabe erledigt oder ein Abbruchkriterium erreicht ist. Dieser Zugewinn hat seinen Preis, dazu unten mehr.

Entscheidungskriterien

Für die Einordnung hat sich eine kleine Prüfliste bewährt:

Kriterium	Spricht für RAG	Spricht für Agent
Aufgabentyp	Frage beantworten	Vorgang erledigen
Wissensquelle	Dokumente, weitgehend statisch	Live-Zustand in Systemen
Ablauf	ein Durchlauf	mehrere abhängige Schritte
Wirkung	nur lesen	anlegen, ändern, senden
Fehlerfolge	schwache Antwort	falsche Aktion

Die letzte Zeile ist die wichtigste. Wenn ein Fehler nur eine unbefriedigende Antwort bedeutet, darf die Architektur einfach sein. Wenn ein Fehler eine Handlung mit Außenwirkung bedeutet, braucht es die volle Agenten-Disziplin: Berechtigungsgrenzen, Freigaben, Protokollierung. Wer diese Disziplin nicht aufbringen kann oder will, sollte auch keinen Agenten betreiben.

Mischformen sind der Normalfall

Die Frage RAG oder Agent suggeriert eine Entweder-oder-Entscheidung, die es in reifen Systemen selten gibt. Die häufigste produktive Form ist der Agent, der Retrieval als eines von mehreren Werkzeugen nutzt: Er schlägt in der Wissensbasis nach, holt den aktuellen Zustand aus dem Fachsystem und bereitet auf dieser Grundlage eine Aktion vor. Retrieval verschwindet also nicht, es wird vom Gesamtsystem zum Baustein.

Daraus ergibt sich auch ein pragmatischer Einführungspfad. Wer unsicher ist, beginnt mit RAG und beobachtet, was die Nutzer nach der Antwort tun. Wenn sich zeigt, dass auf bestimmte Antworten regelmäßig derselbe manuelle Arbeitsschritt folgt, ist genau dieser Schritt der erste Kandidat für ein Werkzeug. So wächst das System entlang des nachgewiesenen Bedarfs statt entlang einer Vision.

Kostenfolgen der Wahl

Die beiden Architekturen unterscheiden sich nicht nur im Können, sondern auch im Preisschild, und zwar auf drei Ebenen. Bei den Modellkosten ist RAG gutmütig: wenige Aufrufe pro Anfrage, gut planbar. Ein Agent ruft das Modell pro Aufgabe mehrfach auf, mit wachsendem Kontext und schwer vorhersagbarer Schrittzahl, die Kosten pro Vorgang streuen entsprechend. Bei der Latenz gilt dasselbe: Eine RAG-Antwort kommt in Sekunden, ein Agentenlauf kann deutlich länger dauern, was für die Einbettung in Arbeitsabläufe relevant ist.

Die dritte Ebene wird am häufigsten unterschätzt: der Betrieb. Ein Agent braucht Guardrails, Freigabeprozesse, Werkzeugpflege, Protokollauswertung und Evals über mehrstufige Läufe. Das ist laufender Aufwand in Personenzeit, der die reinen Modellkosten leicht übersteigt. Die nüchterne Regel lautet deshalb: die kleinste Architektur wählen, die die Aufgabe tatsächlich löst, und erst erweitern, wenn der Bedarf belegt ist.

Fazit

RAG und AI-Agent sind keine Konkurrenten, sondern Antworten auf verschiedene Aufgaben. Geht es darum, Fragen auf einer Wissensbasis belegt zu beantworten, ist RAG die einfachere, günstigere und risikoärmere Wahl. Geht es darum, mehrstufige Vorgänge zu erledigen und in Systeme einzugreifen, führt am Agenten kein Weg vorbei, samt der Sicherheits- und Betriebsdisziplin, die dazugehört. Wer die Entscheidung an der Fehlerfolge und am tatsächlichen Aufgabentyp ausrichtet statt an der Attraktivität der Technologie, trifft sie fast immer richtig.