Kurzfassung: Agentic RAG ist keine bessere Chatbot-Oberfläche. Es lohnt sich, wenn ein Wissensassistent entscheiden muss, welche Quelle abgefragt wird, Geschäftstools aufruft, Workflow State hält, Freigaben einholt und mit fehlender Evidenz umgehen kann. Wenn eine einfache Richtlinienfrage aus einem indexierten Dokumentbestand beantwortet wird, ist klassisches RAG meistens günstiger, schneller und leichter zu evaluieren.
Die praktische Architekturfrage für deutsche B2B-Teams lautet daher nicht „Sollen wir Agents zu RAG hinzufügen?“, sondern „Welche Teile des Wissensprozesses brauchen kontrolliertes Handeln?“ In produktiven Systemen ist die Antwort meist enger als in vielen Demos: Multi-Hop-Retrieval, Tool-Auswahl, berechtigungsbewusste Suche, Ticket- oder CRM-Aktualisierungen und menschliche Freigaben für zustandsändernde Schritte.
Wo klassisches RAG weiterhin richtig ist
Klassisches RAG funktioniert gut, wenn die Nutzerfrage klar begrenzt ist, die Antwort in einer kuratierten Wissensbasis liegt und relevante Chunks in einem Retrieval-Pass gefunden werden können. Ein Support-Bot für Garantiebestimmungen, ein Sales Assistant mit Produktdokumentation oder ein interner Policy-Assistent kann oft bei konventionellem Retrieval, Re-Ranking, Grounded Prompting und sauberen Quellenangaben bleiben.
Die RAG-Erläuterung von Google Cloud ist dafür eine gute Basis: Das Qualitätsproblem liegt vor allem bei Retrieval-Qualität, Chunking, Hybrid Search, Re-Ranking, Grounded Generation und Messgrößen wie Groundedness, Safety, Instruction Following und Antwortqualität. Diese Kontrollen bleiben Pflicht, auch wenn das System agentisch wird.
Wann ein Wissensbot Tools und Workflow State braucht
Der Wechsel von klassischem RAG zu Agentic RAG ist sinnvoll, wenn mindestens eine dieser Bedingungen zutrifft: Die Frage muss in mehrere Retrieval-Schritte zerlegt werden; der Bot muss zwischen Dokumentensuche, SQL, Ticketsuche, Inventar-APIs oder externen Systemen wählen; die Antwort hängt vom Gesprächs- oder Fallstatus ab; der Nutzer erwartet eine Aktion statt nur eine Antwort; oder das System muss vor Änderungen an Geschäftsdaten eine Freigabe einholen.
AWS beschreibt Agentic RAG in Amazon Q Business als koordinierten Ablauf, der Nutzerfrage und Gesprächshistorie analysiert, Retrieval-Tools auswählt, komplexe Fragen zerlegt, mehrere Retrieval-Operationen auslöst, Rückfragen stellt, Antwortqualität prüft und Berechtigungen sowie Quellen beibehält. Das ist der operative Unterschied: Retrieval ist ein Werkzeug in einem gesteuerten Workflow, nicht die gesamte Anwendung.
Entscheidungsmatrix: klassisches RAG vs. Agentic RAG
| Use Case | Besserer Fit | Begründung |
|---|---|---|
| Einzelne Policy-Antwort mit Quellen | Klassisches RAG | Ein Retrieval-Pass mit Re-Ranking reicht häufig aus und ist günstiger. |
| „Vergleichen Sie SLA, offene Tickets und Vertragsbedingungen dieses Kunden“ | Agentic RAG | Das System braucht Dokumenten-Retrieval, Ticketsuche, CRM-Abfrage und Synthese. |
| „Erstellen Sie eine Antwortvorlage und leiten Sie sie zur Support-Lead-Freigabe weiter“ | Agentic RAG | Der Ablauf hat State, rollenbasierte Freigabe und eine nachgelagerte Aktion. |
| Regulierte oder risikoreiche Entscheidungsunterstützung | Agentic RAG mit strengen Kontrollen | Tool-Nutzung muss protokolliert, Evidenz aufbewahrt und ggf. menschlich freigegeben werden. Die rechtliche Einordnung gehört separat geprüft. |
| FAQ-Bot auf öffentlicher Dokumentation | Klassisches RAG | Agenten-Orchestrierung erhöht Latenz und Fehlerquellen ohne ausreichend Nutzen. |
Referenzarchitektur: ein kontrollierter Agentic-RAG-Loop
Ein produktionsfähiges Agentic-RAG-System sollte fünf Verantwortlichkeiten trennen: Retrieval, Reasoning, Tool-Ausführung, Workflow State und Oversight. Verstecken Sie diese fünf Bereiche nicht in einem einzigen Prompt. Je stärker ein System Kunden, Rechnungen, Service-Tickets oder Compliance-Artefakte beeinflusst, desto expliziter müssen die Grenzen sein.
Textdiagramm: Nutzeranfrage → Intent-Klassifikation → Retrieval Planner → berechtigungsbewusste Retriever → Evidence Pack → Antwortentwurf → Critic/Evaluator → Tool-Entscheidung → Freigabe-Gate bei Zustandsänderung → Ausführung → Audit Log → Nutzerantwort.
Der Retrieval Planner entscheidet, ob Vector Search, Keyword Search, SQL, eine Ticketing-API, eine Produktdatenbank oder Long-Context-Dokumentlesen genutzt wird. Das Evidence Pack speichert Passagen, IDs, Scores, Zeitpunkte, Nutzerberechtigungen und fehlgeschlagene Suchen. Der Critic prüft, ob die Evidenz die Antwort tatsächlich trägt. Die Workflow Engine hält Aufgabenstatus, Wiederholungen, Freigaben und Ausführungsergebnis.
Warum Workflow State entscheidend ist
Zustandslose Wissensbots scheitern leise. Sie beantworten den aktuellen Prompt, verlieren aber die Spur: welche Vertragsversion verwendet wurde, ob der Kundendatensatz aktualisiert wurde, ob der Reviewer den Entwurf geändert hat und ob für denselben Vorfall bereits ein Ticket offen ist. Workflow State ist der Unterschied zwischen einer überzeugenden Demo und einem System, dem ein Operations-Team vertrauen kann.
LangGraph ist ein Beispiel für eine Runtime für solche Systeme. Die Dokumentation fokussiert auf Durable Execution, Persistence, Human-in-the-Loop, Memory, Tracing und Evaluation. Wichtiger als das konkrete Framework ist das Prinzip: State muss explizit, wiederherstellbar, prüfbar und testbar sein.
Implementierungs-Checkliste für B2B-Teams
1. Definieren Sie den kleinsten wertvollen Workflow. Starten Sie mit einem Prozess wie Support-Triage, technischer Sales-Unterstützung, Compliance-Evidenzsuche oder Incident-Postmortem-Entwurf. Vermeiden Sie den zu breiten Scope „Company Knowledge Bot“.
2. Trennen Sie Leseaktionen von Schreibaktionen. Eine Richtlinie zu lesen und einen Kundendatensatz zu ändern haben unterschiedliche Risikoprofile. Die zweite Kategorie braucht stärkere Berechtigungen, Freigaben, Audit Logs und Rollback-Verhalten.
3. Bauen Sie zuerst die Retrieval-Basis. Messen Sie Chunk-Qualität, Hybrid Search, Re-Ranking, Groundedness, Quellenqualität und „keine Antwort“-Verhalten, bevor Sie Tools ergänzen.
4. Ergänzen Sie Tools nur dort, wo sie manuelle Arbeit reduzieren. Gute Tools sind eng geschnitten: Tickets nach Kunden-ID suchen, Vertragsmetadaten abrufen, Ticketentwurf erstellen, Freigabe anstoßen oder nach menschlicher Bestätigung eine Notiz schreiben.
5. Speichern Sie State außerhalb des Prompts. Workflow-Status, Evidence IDs, Tool Inputs, Tool Outputs, Freigabeentscheidungen, Kosten, Latenz und Fehler gehören in eine Datenbank oder eine robuste Orchestrierungsschicht.
6. Evaluieren Sie vollständige Aufgaben, nicht nur Antworten. Messen Sie Task Success Rate, Groundedness, Zitationskorrektheit, Tool-Call-Accuracy, Eskalationsrate, Kosten pro erledigtem Fall, Latenz und menschliche Korrekturrate.
Fehlermodi, für die Sie entwerfen sollten
Agentic RAG bringt neue Fehlermodi: Der Planner kann das falsche Tool wählen, Retrieval kann plausible, aber irrelevante Evidenz finden, ein Tool kann mit veraltetem State aufgerufen werden, eine Berechtigungsgrenze kann versehentlich überschritten werden oder das System wiederholt Schritte, bis Latenz und Kosten nicht mehr akzeptabel sind. Mehr Autonomie bedeutet mehr Observability, nicht weniger.
Der sicherste Default ist begrenzte Autonomie: Das System darf recherchieren, entwerfen, vergleichen, klassifizieren und Aktionen vorbereiten. Niedrigrisiko-Aktionen kann es erst dann automatisch ausführen, wenn Evaluationen stabile Leistung zeigen. Vor kunden sichtbaren, finanziellen, vertraglichen oder compliance-relevanten Änderungen sollte es menschliche Freigabe einholen.
Kosten- und Latenz-Trade-offs
Agentic RAG kann bei komplexen Fragen die Vollständigkeit verbessern, verändert aber das Kostenprofil. Mehrere Retrieval-Pässe, Re-Ranking, Critics, Tool Calls und Wiederholungen erhöhen die Latenz. AWS weist ausdrücklich darauf hin, dass Agentic-RAG-Antworten länger dauern können, weil mehrere Retrieval-Operationen notwendig sein können. Für interne Operations-Prozesse kann das akzeptabel sein. Für kundenseitigen Chat braucht es eventuell progressive Antworten, Hintergrundaufgaben oder einen Fallback auf klassisches RAG.
Ein realistischer 30-Tage-Rollout
Woche 1: einen Workflow auswählen, Datenquellen kartieren, Lese-/Schreibgrenzen definieren und einen Golden Dataset mit 50–100 realen Fragen oder Fällen erstellen. Woche 2: klassisches RAG mit Quellen und Baseline-Metriken implementieren. Woche 3: ein oder zwei Tools, expliziten Workflow State und menschliche Freigabe ergänzen. Woche 4: Offline-Evals, betreute Live-Tests, Kostenanalyse und Architekturentscheidung durchführen, bevor der Scope erweitert wird.
Was ich zuerst bauen würde
Für die meisten deutschen B2B-Teams ist das erste sinnvolle Agentic-RAG-Projekt kein allgemeiner Wissensbot. Es ist ein kontrollierter Assistent für einen wiederholbaren operativen Workflow: Support-Triage, technische Ausschreibungsantwort, Service-Incident-Recherche oder Compliance-Evidenzvorbereitung. Das System sollte Evidenz abrufen, eine Empfehlung entwerfen, Confidence und fehlende Daten zeigen und die finale Aktion an einen Menschen weiterleiten.
Quellen
AWS beschreibt Agentic RAG als Ablauf, der komplexe Fragen zerlegt, Retrieval-Tools auswählt, Gesprächskontext hält, Antwortqualität prüft, erneut sucht oder Rückfragen stellt und Berechtigungen sowie Quellen beibehält: https://docs.aws.amazon.com/amazonq/latest/qbusiness-ug/agentic-rag.html
Google Cloud beschreibt RAG als Grounded Generation mit Retrieval-Systemen und LLMs und betont Hybrid Search, Re-Ranking, Groundedness-Bewertung, Safety, Instruction Following und RAG-Ops-Metriken: https://cloud.google.com/use-cases/retrieval-augmented-generation
LangGraph dokumentiert die operativen Bausteine für zustandsbehaftete Agenten: Durable Execution, Persistence, Human-in-the-Loop-Interrupts, Memory, Tracing und Evaluation: https://docs.langchain.com/oss/python/langgraph/overview
Dong et al., RAG-Critic (ACL 2025), zeigt die Forschungsrichtung hin zu kritikgeleiteten, iterativen Agentic-RAG-Workflows statt einmaliger Retrieval-Pässe: https://aclanthology.org/2025.acl-long.179/
Brauchen Sie Hilfe bei der Architekturentscheidung?
Ade Christanto unterstützt B2B-Teams beim Entwurf von KI-Automatisierung, die Produktionsbedingungen standhält: Retrieval-Qualität, Tool-Grenzen, Workflow State, Evaluation, menschliche Freigabe und Kostenkontrolle. Wenn Ihr Wissensbot Tools, Freigaben oder zuverlässigen State braucht, sollte die Architektur geprüft werden, bevor der Prototyp zu operativer Schuld wird.
