Wenn Kunden 2026 nach RAG fragen: Der Entscheidungsbaum (und warum der Weg selten dort beginnt)

RAG-Pipelines werden für Kunden gebaut, die eine anfragen, aber 2026 ist das selten die erste Empfehlung. Der Agent-Tooling-Stack von 2024, der Retrieval Augmented Generation zur Standardantwort auf jede Wissensfrage gemacht hat, wurde zwischen Januar und April dieses Jahres weitgehend obsolet. Dieser Beitrag zeigt den Entscheidungsbaum, den jeder Interessent durchläuft, und den Stack, der geliefert wird, wenn der Baum von RAG wegzeigt.

Viele Agenturen pitchen RAG nach wie vor als Standard, was eine Architektur von 2024 widerspiegelt statt der aktuellen Praxis. Sie haben wahrscheinlich bereits ein solches Angebot erhalten: eine Vektordatenbank als Posten, eine Chunking-Strategie, einen Re-Indexierungs-Cron, eine Sechsmonats-Roadmap, bevor das System die erste Frage beantwortet. Liegt ein Angebot auf Ihrem Schreibtisch, schicken Sie es vor der Unterschrift und der Entscheidungsbaum wird gemeinsam durchlaufen. Hier ist, warum sich die Art, wissensbasierte Agenten zu bauen, verändert hat, und was stattdessen geliefert wird.

Entscheidungsregeln

• RAG wird gebaut, wenn Kunden darauf bestehen. 2026 ist das selten die erste Empfehlung. Der Tooling-Shift ist real, und die Aufgabe besteht darin, ihn zu benennen, bevor Sie unterschreiben.
• Sam Hogan argumentierte Ende 2025, dass wesentliche Teile des LLM-Tooling-Stacks von 2024 heute obsolet sind (18. April 2026). RAG, Multi-Agent-Orchestrierung, ReAct-Frameworks, Prompt-Management, LLMOps, Eval-Tools, Gateways, Finetuning-Bibliotheken. Die Konzepte sind weiterhin gültig. Die populären Implementierungen haben den Modellsprung nicht mitgemacht.
• Zep hat sich von Memory zu Context Engineering umpositioniert. Wenn ein finanziertes Unternehmen seine eigene Kategorie umbenennt, ist das ein aussagekräftiges Marktsignal für die Richtung der Agent-Infrastruktur.
• Skill Graphs haben Vektorsuche als bevorzugtes Substrat abgelöst. Ein Ordner mit Markdown-Dateien und fünf Shell-Befehlen erledigt mehr Kundenaufgaben als jede RAG-Pipeline.
• RAG verdient seinen Platz bei vier spezifischen Aufgaben. Multimodale Korpora, Millionen von Dokumenten mit hoher Aktualisierungsfrequenz, strikte Metadatenfilter zur Abrufzeit und nicht vertrauenswürdige, adversarielle Inhalte. Alles andere ist ein Skill Graph.

Der Entscheidungsbaum vor jedem Projektstart

Jedes Kundenengagement beginnt mit denselben vier Fragen, und in neun von zehn Fällen zeigen die Antworten von RAG weg. Dieser Baum entstand aus einer Analyse von 450 Repositories zu Agent-Memory- und Context-Management-Tools auf GitHub, veröffentlicht am 15. April 2026. Kaum jemand zieht die Linie zwischen den beiden explizit. Hier wird sie gezogen, weil die Linie die Rechnung bestimmt.

Die meisten Kundenkorpora sind interne Wikis, Sales-Playbooks, Onboarding-Materialien, Produktdokumentation und SOPs. Klein, stabil, gepflegt von wenigen Personen. Jeder dieser Fälle ist ein Skill-Graph-Job. Das Kleinkorpus-Argument mit konkreten Zahlen und die vollständige Knowledge-Layer-Anleitung liefern die Praktiker-Perspektive.

Was zwischen Januar und April 2026 tatsächlich obsolet wurde

Sam Hogan veröffentlichte am 18. April 2026 die schärfste Diagnose des Wandels. Seine These: Der größte Teil der LLM-Tooling-Kategorie wurde für eine Welt gebaut, die weitgehend nicht mehr existiert, und vieles davon wurde in den vorangegangenen drei Monaten obsolet. Seine Liste:

• RAG und GraphRAG. Der Retrieval-Ansatz, der für Kontextfenster unter 32K Token entwickelt wurde.
• Multi-Agent-Orchestrierungs-Frameworks. Frühe handcodierte Koordinationsschichten, verdrängt durch Koordination auf Runtime-Ebene.
• ReAct-Frameworks. Strukturierte Reasoning-Gerüste, die neuere Modelle ohne Scaffolding produzieren.
• Prompt-Management- und Versionierungstools. Gebaut für eine Welt, in der Prompts das Asset waren. Skills und Context-Substrate sind heute das Asset.
• LLMOps-Stacks. Heute stärker auf Agent-Tracing als auf Einzelturn-Prompt-Management ausgerichtet.
• Eval-Tools, Gateways, Finetuning-Bibliotheken. Jeweils gebaut für ein Modellverhalten, das sich verändert hat.

Wichtige Einschränkung von Hogan selbst: Die Konzepte behalten ihren Wert. Was obsolet wurde, sind die aktuell populären Implementierungen. Einige Tools, er nannte CrewAI explizit, haben weiterhin Bestand. Seine tiefere These ist die relevante für Kunden: Aktuelle Frontier-Modelle mit sehr langen Kontextfenstern haben das Faktenabfrageproblem, für das RAG entwickelt wurde, weitgehend gelöst.

Das stärkste Marktsignal kam von Zep, einem finanzierten Unternehmen im Bereich Agent-Memory. Die gesamte Positionierung wurde von Memory zu Context Engineering geändert. MemSearch, vom Vektordatenbank-Unternehmen Zilliz, lieferte ein System, in dem die eigene Vektordatenbank nachgelagert von einfachen Markdown-Dateien ist. Wenn ein Vektordatenbank-Anbieter einräumt, dass Dateien das Wissen beherbergen und der Index nur die Zugriffsschicht ist, lässt sich das in einer Pressemitteilung erst nach Jahren erkennen und in einem Produkt-Update nach Wochen.

Was RAG für den Großteil der Agent-Arbeit abgelöst hat

Die Analyse von 450 Repositories teilte Agent-Memory in zwei Lager. Lager eins sind Memory-Backends: Fakten aus Gesprächen extrahieren, in Vektordatenbanken speichern, auf Anfrage abrufen. Mem0 (53.100 GitHub-Sterne), MemPalace (46.200), Honcho, Cognee. Optimiert auf Recall.

Lager zwei sind Context-Substrate: strukturierter, menschenlesbarer Kontext, der sich über Sitzungen aufbaut. Zep ist heute hier positioniert. OpenClaw (250.000 Sterne) ist die Referenzimplementierung. Das Vault, aus dem dieser Beitrag stammt, ist ein System des zweiten Lagers.

Der typische Loop für Lager zwei: Der Agent liest strukturierten Kontext, arbeitet darin, schreibt zurück, und in der nächsten Sitzung ist der Kontext reicher. Keine Chunking-Strategie, kein Embedding-Modell zum Warten, kein Re-Indexierungs-Batch-Job, keine Retrieval-Evaluationsreihe. Ein Ordner Markdown-Dateien mit Wikilinks, eine Index-Datei im Stammverzeichnis und eine Handvoll Lese- und Schreibbefehle. Das ist das Substrat.

Shiv Sakhuja veröffentlichte das Kompositionsmodell für dieses Substrat am 23. April 2026 als Skill Graphs 2.0. Drei Ebenen: Atome (einzelzweckgebundene Primitive, nahezu deterministisch), Moleküle (abgegrenzte Aufgaben, die 2 bis 10 Atome mit explizitem Chaining kombinieren), Verbindungen (Multi-Molekül-Orchestratoren mit echter Agenten-Autonomie, heute noch menschengesteuert). Das Framework begrenzt die Tiefe des Abhängigkeitsgraphen, was die Zuverlässigkeit sichert, wo flache Skill Graphs ab drei oder vier Hops unbemerkt driften. Für Kunden ergibt sich daraus eine klare Kostenstruktur: Atome sind günstig und deterministisch, Moleküle sind der Schwerpunkt der Engineering-Arbeit, Verbindungen erfordern einen menschlichen Operator im Budget.

Die Ausnahmen, bei denen RAG seinen Platz verdient

webvise liefert, was der Auftrag erfordert. RAG schlägt einen Skill Graph bei vier spezifischen Aufgabenklassen, und dort wird es auch empfohlen:

• Multimodale Korpora. PDFs mit Tabellen, gescannte Dokumente, Audiotranskripte, bildintensive Berichte. Ein Markdown-Graph setzt voraus, dass alles auf Text reduzierbar ist. Wo das nicht gilt, ist Retrieval mit multimodalem Embedding die sauberere Lösung.
• Hochfrequente Aktualisierungen in großem Maßstab. Millionen von Dokumenten, die sich minütlich ändern und innerhalb von Sekunden nach Veröffentlichung abfragbar sein müssen. Die Re-Indexierungskosten einer Vektordatenbank sind geringer als die Personalkosten für die Pflege einer Index-Datei bei diesem Volumen.
• Strikte Metadatenfilter zur Abrufzeit. Wenn Abfragen nach Datumsbereichen, Dokumenttyp oder Autor filtern müssen, bevor die semantische Suche greift, erledigen metadatenbewusste Vektordatenbanken wie Pinecone und Qdrant die Komposition sauber.
• Nicht vertrauenswürdige oder adversarielle Inhalte. Wenn das Korpus von vielen Verfassern mit widersprüchlichen Absichten stammt und kein einzelner Mensch eine kuratierte Index-Datei pflegen kann, ist Retrieval ohne Annahme redaktioneller Aufsicht die richtige Wahl.

Fällt Ihr Projekt in eine dieser vier Klassen, ist RAG das richtige Werkzeug und wird entsprechend gebaut. Andernfalls ist der Skill Graph günstiger zu liefern, günstiger zu betreiben und leichter zu warten. Nehmen Sie vor der Beauftragung Kontakt auf und der Entscheidungsbaum wird auf Ihr spezifisches Korpus angewendet.

Was intern eingesetzt wird und was für Kunden geliefert wurde

Das interne Wiki umfasst 22 Seiten strukturierten Wissens, gepflegt mit fünf Shell-Befehlen. Keine Vektordatenbank, keine Embeddings, kein Re-Indexierungs-Cron. Das vollständige Setup ist in einem früheren Beitrag beschrieben.

Dasselbe Substrat produziert den webvise-Blog, den Sie gerade lesen: 76 Beiträge, in 7 Sprachen übersetzt, über einen einzigen Content-Skill-Graph, ohne dediziertes Content-Team. Ein Skill, sieben Ausgaben pro Beitrag, geliefert aus demselben Ordner wie die Engineering-Dokumentation.

Auf Kundenseite basiert die Produktionsarbeit mit Agenten auf derselben Architektur. Hermes, die selbstoptimierende Agent-Plattform aus dem vergangenen Monat, läuft auf fetten Skills und einem schlanken Runtime. Paperclip, das unternehmensweite KI-Orchestrierungssystem, komponiert Moleküle über eine Markdown-Wissensbasis. Keine der beiden Plattformen hat eine Vektordatenbank im Produktionsstack, und keine hat eine benötigt.

Garry Tan erzählt dieselbe Geschichte aus YC. Sein persönliches CLAUDE.md begann mit 20.000 Zeilen, mit jeder Eigenheit, jedem Muster, jeder Erkenntnis, die er je gesammelt hatte. Die Aufmerksamkeit des Modells degradierte unter dem Gewicht, und Claude Code selbst empfahl eine Reduktion.

Die Lösung: 200 Zeilen Verweise auf Dokumente, die bei Bedarf geladen werden. Die vollen 20.000 Zeilen existieren weiterhin, das Modell liest sie nur dann, wenn sie relevant sind. gstack erreichte 23.000 GitHub-Sterne in der ersten Woche und lieferte in rund 60 Tagen ein hohes Volumen an Produktionscode. Sterne und Zeilenzahlen messen Sichtbarkeit und Durchsatz, nicht die Produktionsreife. Das Substrat skaliert, weil das Substrat Dateien sind, keine Infrastruktur.

Fragen an einen Anbieter vor der Unterzeichnung eines RAG-Vertrags 2026

Liegt ein RAG-Angebot auf dem Schreibtisch, prüfen Sie es mit diesen fünf Fragen vor der Unterschrift:

• Wie groß ist das Korpus heute und in 24 Monaten? Unter 1.000 Dokumenten in beiden Szenarien bedeutet: Die Vektordatenbank ist ein Posten, den Sie nicht benötigen.
• Wer erstellt die Inhalte? Wenige interne Personen, denen Genauigkeit wichtig ist, erzielen mit einer gepflegten Index-Datei bessere Retrieval-Qualität als mit Embeddings. Tausende adversarieller oder anonymer Autoren begünstigen RAG.
• Wie hoch ist die Aktualisierungsfrequenz? Einmal wöchentliche Änderungen erfordern keine Re-Indexierungs-Pipeline. Minütliche Änderungen in großem Maßstab schon.
• Erfordert die Abfrage strikte Metadatenfilter zur Abrufzeit? Wenn ja, verdient eine metadatenbewusste Vektordatenbank ihren Platz. Wenn nein, ist die Filterlogik in der Skill-Schicht günstiger.
• Wie sieht das Angebot des Anbieters in 18 Monaten aus? Vektordatenbank-Kosten wachsen mit dem Dokumentvolumen. Skill-Graph-Kosten nicht. Der Unterschied fällt bei der Vertragsverlängerung ins Gewicht.

Zeigen die Antworten auf RAG, wird RAG gebaut. Zeigen sie auf einen Skill Graph, liegt die Herausforderung im Ablegen des Playbooks von 2024. webvise durchläuft den Entscheidungsbaum anhand Ihres tatsächlichen Korpus, liefert die Architektur, auf die der Baum zeigt, und setzt die Ersparnis für die Arbeit ein, die das Budget wirklich benötigt. Nehmen Sie Kontakt auf, bevor Sie sich auf ein Anbieterangebot festlegen.