Etwas Interessantes geschieht im Bereich der agentischen Infrastruktur, und es ist nicht das, was die meisten erwartet haben. In den vergangenen zwei Jahren war das dominante Paradigma, um Agenten Wissenszugang zu verschaffen, Retrieval-Augmented Generation: Dokumente einbetten, in einer Vektordatenbank speichern und das Modell zur Inferenzzeit abfragen lassen. RAG hat funktioniert. Es war gut genug. Aber „gut genug“ hat ein Haltbarkeitsdatum, und im Jahr 2026 läuft dieses ab.
\n\nEin neues Muster zeichnet sich in der Branche ab, und es konvergiert aus mehreren Richtungen gleichzeitig. Mintlify ersetzte seine gesamte RAG-Pipeline durch ein virtuelles Dateisystem und sah die Sitzungserstellung von 46 Sekunden auf 100 Millisekunden sinken [1]. Turso baute AgentFS, ein SQLite-gestütztes Dateisystem, das jedem Agenten seine eigene Copy-on-Write-Sandbox gibt [2]. Box, der Enterprise-Content-Riese, kündigte an, dass er seine gesamte Plattform als virtuelle Dateisystem-Schicht für KI-Agenten neu positioniert [3]. Und ByteDance hat OpenViking als Open Source veröffentlicht, eine Kontextdatenbank, die den gesamten Agentenspeicher, Ressourcen und Fähigkeiten als hierarchisches Dateisystem organisiert [4].
\n\nDas sind keine Nischenexperimente. Sie sind Signale eines fundamentalen Wandels. Das Dateisystem wird zur universellen Schnittstelle für die Agenten-Kognition, und die Datenbank wird stillschweigend zu seinem Substrat.
\n\nRAG war die richtige Antwort für 2023. Man hatte einen Stapel Dokumente, ein Modell mit begrenztem Kontextfenster und brauchte eine Möglichkeit, zur Abfragezeit relevante Chunks zuoberst zu bringen. Vektor-Embeddings und Ähnlichkeitssuche lösten dieses Problem elegant.
\n\nAber Agenten sind keine Chatbots. Ein Agent stellt nicht eine Frage und geht. Er erkundet. Er liest eine Datei, entdeckt eine Referenz, folgt ihr, liest eine andere Datei, führt einen Befehl aus, schreibt eine Ausgabe. Das ist kein Retrieval-Problem. Es ist ein Navigationsproblem.
\n\nRAG-Pipelines haben damit aus drei Gründen zu kämpfen. Erstens sind sie von Natur aus zustandslos. Jede Abfrage ist unabhängig; es gibt kein Konzept von „Ich habe gerade in dieses Verzeichnis geschaut, zeige mir jetzt die benachbarte Datei.“ Zweitens verflachen sie Strukturen. Eine Dokumentationsseite mit einer klaren Hierarchie aus Abschnitten, Seiten und Code-Beispielen wird in anonyme 512-Token-Chunks zerrissen, die ihren organisatorischen Kontext verlieren. Drittens sind sie im großen Maßstab teuer. Embedding-Berechnung, Vektorindex-Wartung und Re-Ranking fügen Latenz und Kosten hinzu, die mit wachsendem Korpus zunehmen.
\n\nDas Dateisystem löst alle drei Probleme. Es ist von Natur aus zustandsbehaftet (der Agent hat ein Arbeitsverzeichnis). Es bewahrt Strukturen (Verzeichnisse, Unterverzeichnisse, Dateien). Und es ist schnell, weil die Operationen einfach sind: ls, cat, grep, find. Das sind keine neuartigen Abstraktionen. Es ist die am besten erprobte Schnittstelle in der Informatik.
Was diesen Moment bedeutsam macht, ist, dass das Dateisystem-Muster unabhängig in sehr unterschiedlichen Kontexten entsteht.
\n\nMintlifys ChromaFs ist vielleicht das lehrreichste Beispiel. Mintlify betreibt Dokumentationsassistenten für Tausende von Unternehmen. Ihre ursprüngliche Architektur war RAG im Lehrbuch: die Dokumente in Chunks aufteilen, einbetten und zur Abfragezeit abrufen. Als sie diese durch ChromaFs ersetzten, ein virtuelles Dateisystem, das UNIX-Befehle abfängt und in Chroma-Datenbankabfragen übersetzt, waren die Ergebnisse dramatisch. Die Sitzungserstellung ging von 46 Sekunden auf 100 Millisekunden zurück, eine 460-fache Verbesserung. Die Grenzkosten pro Konversation fielen von 0,0137 $ auf effektiv null [1]. Die entscheidende Erkenntnis: Der Agent weiß bereits, wie man in einem Dateisystem navigiert. Ihm beizubringen, cat /auth/oauth.mdx zu verwenden, ist trivial im Vergleich dazu, ihm beizubringen, die richtige Vektorabfrage zu formulieren.
Turso's AgentFS greift ein anderes Problem an: Agenten-Isolation und Auditierbarkeit. Jeder Agent erhält sein eigenes SQLite-gestütztes Dateisystem mit Copy-on-Write-Semantik. Das Host-Dateisystem ist eine schreibgeschützte Basisschicht; der Agent schreibt in eine SQLite-Delta-Schicht. Jede Dateioperation, jeder Tool-Aufruf und jede Zustandsänderung wird aufgezeichnet. Die gesamte Agenten-Laufzeit, Dateien, Zustand, Verlauf passen in eine einzige portable SQLite-Datei [2]. Das ist nicht nur ein Dateisystem. Es ist eine auditierbare, reproduzierbare Ausführungsumgebung.
\n\nBox' Enterprise-VFS ist strategisch am bedeutsamsten. Box-CEO Aaron Levie hat sich unmissverständlich geäußert: Agenten brauchen ein Dateisystem, um Wissensarbeit im Unternehmen zu erledigen [3]. Aber Box verkauft kein wörtliches Dateisystem. Sie verkaufen einen „dynamischen Datenliefervertrag“, der durch Objektspeicher, relationale Datenbanken oder ihre eigene Content-Plattform unterstützt werden kann. Das Dateisystem ist die Schnittstelle; der Backing-Store ist das, was für die Daten sinnvoll ist. Was Box' Vorstoß interessant macht, ist die Governance-Schicht: Berechtigungen, Audit-Trails und Compliance-Grenzen, die automatisch von der Content-Plattform auf den Agenten übertragen werden.
\n\nByteDances OpenViking treibt das Muster am weitesten. Es organisiert den gesamten Agentenkontext, Erinnerungen, Ressourcen, Fähigkeiten, Wissen unter einem viking://-Protokoll mit standardmäßigen Dateisystem-Semantiken. Agenten navigieren mit ls und find. Aber der clevere Teil ist das gestufte Zugriffsmodell: Jedes Stück Kontext wird in drei Schichten aufbereitet. L0 ist eine Ein-Satz-Zusammenfassung für schnelles Abrufen. L1 ist ein Überblick mit Kerninformationen für die Planung. L2 ist der vollständige Inhalt für vertieftes Lesen [4]. Der Agent beginnt mit L0, bohrt in L1 hinein, wenn er mehr braucht, und lädt L2 nur, wenn er detaillierte Arbeit verrichtet. Im LoCoMo-Benchmark reduzierte dies den Token-Verbrauch von 24,6 Millionen auf 4,2 Millionen und erhöhte gleichzeitig die Task-Abschlussraten auf 52 % [4].
Das Muster, das alle vier verbindet, ist das, was ich die VFS-Dualität nennen würde: Das Dateisystem gewinnt als Schnittstelle, und die Datenbank gewinnt als Substrat. Das ist keine Entweder-oder-Entscheidung. Es ist eine geschichtete Architektur.
\n\nWarum das Dateisystem als Schnittstelle gewinnt, ist einfach. LLMs werden mit dem Internet trainiert, und das Internet wird von Entwicklern gebaut, die in Begriffen von Dateien, Verzeichnissen, Pfaden und Kommandozeilen-Tools denken. Modelle sind mit diesen Primitiven ungewöhnlich kompetent, weil sie Milliarden von Beispielen gesehen haben, wie Entwickler in Codebases navigieren, Dateien lesen und Shell-Befehle ausführen. Wenn Sie einem Agenten ein Dateisystem geben, kommen Sie ihm dort entgegen, wo seine Trainingsdaten leben.
\n\nWarum die Datenbank als Substrat gewinnt, ist ebenso klar. In dem Moment, in dem der Agentenspeicher geteilt, auditiert, von mehreren Agenten abgefragt oder unter Nebenläufigkeit zuverlässig gemacht werden muss, brauchen Sie Datenbank-Garantien. ACID-Transaktionen, Zugriffskontrolle, semantische Suche, Versionshistorie: Das sind schwierige Probleme, die Datenbanken Jahrzehnte lang gelöst haben. Sie auf einem wörtlichen Dateisystem neu zu implementieren, ist ein Weg in den Schmerz.
\n\nDas VFS-Muster gibt Ihnen beides. Der Agent sieht Dateien und Verzeichnisse. Das System sieht Tabellen, Indizes und Zugriffssteuerungslisten. ChromaFs speichert alles in Chroma, stellt es aber als Dateien dar. AgentFS speichert alles in SQLite, stellt es aber als POSIX-Dateisystem dar. OpenViking verwendet seine eigene Storage-Engine, stellt sie aber als viking://-Pfade dar. Box verwendet seine Enterprise-Content-Plattform, stellt sie aber als navigierbaren Baum dar.
Der naheliegende Einwand gegen all das ist: Warum nicht einfach das echte Dateisystem verwenden? POSIX ist direkt da. Jedes Betriebssystem liefert es mit. Warum eine Abstraktionsschicht hinzufügen?
\n\nIch wollte diese Frage empirisch beantworten, also habe ich markdownfs gebaut, ein Virtual Filesystem in Rust von Grund auf, das speziell für Agenten-Workloads entwickelt wurde [6]. Es unterstützt den vollen Satz UNIX-artiger Befehle (ls, cat, grep, find, chmod, chown), Git-artige Versionierung mit content-addressable storage, Multi-User-Berechtigungen und stellt drei Zugriffsmethoden bereit: eine CLI/REPL, eine HTTP/REST-API und einen MCP-Server, mit dem sich Agenten wie Claude und Cursor direkt verbinden können.
Die Architektur ist einfach: eine In-Memory-Inode-Tabelle, unterstützt durch einen content-addressable Blob-Store mit SHA-256-Hashing, mit tokio::RwLock für sicheren gleichzeitigen Zugriff. Dateien werden automatisch dedupliziert. Die Versionskontrolle verwendet dasselbe Commit/Revert-Modell wie Git, aber auf Dateisystemebene. Die Persistenz wird durch atomare bincode-Snapshots gehandhabt.
Als ich markdownfs gegen das native Dateisystem über die Standard-Agentenoperationen hinweg benchmarkt habe (Dateierstellung, Lesen, Schreiben, Verzeichnisauflistung, grep, find, Verschieben, Kopieren, Löschen), war markdownfs durchschnittlich rund 130-mal schneller in allen Bereichen. Die Gründe sind struktureller Natur, nicht zufällig. In-Memory-Operationen eliminieren Disk-I/O vollständig. Content-addressable storage bedeutet, dass doppelte Dateien nur einmal gespeichert werden. Zero-Copy-Reads bedeuten, dass der Agent Daten ohne Serialisierungs-Overhead erhält. Und weil der gesamte Dateisystemzustand in einem einzigen Prozess lebt, gibt es keine Systemaufruf-Grenzen zu überqueren.
\n\nDer Vergleich ist besonders deutlich bei den Operationen, die Agenten am häufigsten ausführen:
\n\n| Operation | \nWarum das VFS gewinnt | \n
|---|---|
| Wiederholtes Lesen (Agent liest Kontext erneut) | \nIn-Memory, Zero-Copy. Keine Disk-Seeks, keine Page-Cache-Misses. | \n
| grep über Dateien (Agent sucht nach Mustern) | \nDer gesamte Inhalt ist im Speicher. Keine Verzeichnis-Traversierung, kein Datei-Handle-Management. | \n
| Schnelle Dateierstellung (Agent erzeugt Arbeitsartefakte) | \nKein Dateisystem-Journaling, keine Inode-Zuweisung auf der Disk, kein fsync. | \n
| Verzeichnisauflistung (Agent erkundet Struktur) | \nBTreeMap-Lookup vs. readdir-Syscalls. | \n
Aber Performance ist nicht das eigentliche Argument. Das eigentliche Argument ist, was das native Dateisystem nicht kann. Ein POSIX-Dateisystem hat kein Konzept von semantischer Suche. Es hat keine eingebaute Versionierung (dafür braucht man Git). Es hat kein gestuftes Zugriffsmodell (man bekommt die ganze Datei oder nichts). Es hat keine Content-Deduplizierung. Es hat keinen Audit-Trail von Agentenoperationen. Und entscheidend: Es hat keine MCP-Schnittstelle, was bedeutet, dass Agenten nicht über das Standardprotokoll darauf zugreifen können, auf das das Ökosystem konvergiert.
\n\nDas VFS ist nicht nur schneller. Es ist eine reichhaltigere Primitive. Es gibt Ihnen die vertraute Schnittstelle von ls und cat und fügt gleichzeitig die Fähigkeiten hinzu, die Agenten tatsächlich brauchen: Versionierung, Berechtigungen, Suche, Deduplizierung und protokollnativen Zugriff via MCP oder HTTP.
Um das klarzustellen: RAG ist nicht tot. Vektor-Suche bleibt wertvoll für unscharfe, semantische Abfragen, bei denen der Agent wirklich nicht weiß, wonach er sucht. Aber die ehrliche Einschätzung ist, dass RAG übermäßig angewendet wurde. Viele der Anwendungsfälle, in denen Teams RAG-Pipelines eingesetzt haben, Dokumentenretrieval, Codebase-Navigation, Enterprise-Knowledge-Management, werden durch eine Dateisystem-Schnittstelle besser bedient.
\n\nDie Beweise sind eindrucksvoll. Mintlifys 460-fache Beschleunigung kam durch den Ersatz von RAG durch ein Dateisystem, nicht durch dessen Erweiterung [1]. Forschung von Letta zeigt, dass Agenten, die einfache Dateisystemoperationen verwenden, 74 % Genauigkeit bei Speicher-Benchmarks erreichen, was mit spezialisierten Retrieval-Tools konkurriert. Und agentische Keyword-Search-Ansätze können über 90 % der RAG-Performance erreichen, ganz ohne Vektordatenbanken [5].
\n\nDie Zukunft ist wahrscheinlich hybrid. RAG für offene semantische Suche. Dateisystem für strukturierte Navigation und Task-Ausführung. Aber der Schwerpunkt verschiebt sich in Richtung Dateisystem, und die strategischen Implikationen sind erheblich.
\n\nWenn Sie agentische Infrastruktur aufbauen, brauchen Sie eine VFS-Strategie. Hier ist der Grund.
\n\nFür SaaS-Unternehmen: Die Lehre von Box ist, dass das Dateisystem zur Integrationsoberfläche für Agenten wird. Wenn der Content Ihrer Plattform nicht als Dateisystem navigierbar ist, werden Agenten Sie umgehen. Die SaaS-Unternehmen, die ihre Daten durch dateisystemähnliche Schnittstellen exponieren, werden Teil des agentischen Workflows. Diejenigen, die das nicht tun, werden für Agenten unsichtbar, was bedeutet, dass sie für Nutzer unsichtbar werden.
\n\nFür Infrastruktur-Anbieter: Die Datenbank verschwindet nicht. Sie rückt unter das Dateisystem. Das ist eigentlich gute Nachricht für Datenbankunternehmen. Turso hat das verstanden und AgentFS auf Basis von SQLite gebaut. Jeder Agent, der hochfährt, erstellt eine neue Datenbank. Je mehr Agenten die Welt betreibt, desto mehr Datenbanken braucht die Welt. Aber die Datenbank muss hinter einer Dateisystem-Abstraktion verschwinden.
\n\nFür Unternehmen: Die Governance-Geschichte ist das, was zählt. Box' Pitch dreht sich eigentlich nicht um Dateisysteme. Es geht darum, dass ihr Berechtigungsmodell, ihr Audit-Trail und ihre Compliance-Infrastruktur automatisch auf Agenten ausgedehnt werden, wenn Content über die VFS-Schicht abgerufen wird [3]. Das ist die Antwort auf die Frage, die jeder CISO stellt: „Wie lassen wir Agenten auf unseren Content zugreifen, ohne einen Sicherheitsalbtraum zu schaffen?“
\n\nDer agentische Infrastruktur-Stack hat sich in klaren Phasen entwickelt: Tools (MCP), Skills und Kontext-Graphen. Das virtuelle Dateisystem fügt sich in diesen Bogen als Bereitstellungsmechanismus für alle drei ein. MCP-Tools werden über das Dateisystem aufgerufen. Skills werden als Dateien gespeichert. Kontext-Graphen werden als Verzeichnisbäume navigiert. Das Dateisystem ersetzt diese Schichten nicht. Es vereinheitlicht sie hinter einer einzigen, vertrauten Schnittstelle.
\n\nDas ist die eigentliche Erkenntnis. Das Dateisystem ist keine neue Idee. Es ist die älteste Abstraktion in der Informatik. Aber genau deshalb funktioniert es für Agenten. In einer Welt, in der wir jedes Quartal neue Paradigmen erfinden, könnte der mächtigste Schritt darin bestehen, zu der erprobtesten Schnittstelle zurückzugreifen, die wir haben, und eine moderne Datenbank dahinterzusetzen.
\n\nDie Unternehmen, die das verstehen, Mintlify, Turso, Box, ByteDance, bauen nichts Neues. Sie erkennen etwas Altes und geben ihm einen neuen Auftrag.
\n\nReferenzen:
\n[1] Mintlify. (2026, April 2). How we built a virtual filesystem for our Assistant. Mintlify Blog.
\n[2] Turso. (2026). The Missing Abstraction for AI Agents: The Agent Filesystem. Turso Blog.
\n\n[4] Volcengine. (2026). OpenViking: An open-source context database for AI Agents. GitHub.
\n\n", "source_hash": "sha256:b576661fe0d14759bc1b074608bc4208873bd898abf89987b9d7e9a126ba21b9", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-08-07T07:33:23.634514+00:00" }