{
  "title": "फाइलसिस्टम ही डेटाबेस है: एजेंट्स को एक नए स्टोरेज प्रिमिटिव की जरूरत क्यों है",
  "excerpt": "RAG पाइपलाइन्स ने एजेंट्स को मेमोरी दी। लेकिन एजेंटिक इन्फ्रास्ट्रक्चर की अगली लहर एक बिल्कुल अलग प्रिमिटिव पर केंद्रित हो रही है: वर्चुअल फाइलसिस्टम। Mintlify के ChromaFs से लेकर Turso के AgentFS और Box के एंटरप्राइज VFS लेयर तक, यह पैटर्न साफ दिखता है। फाइलसिस्टम एजेंट कॉग्निशन का यूनिवर्सल इंटरफेस बनता जा रहा है, और डेटाबेस चुपचाप इसका सब्सट्रेट बन रहा है।",
  "content_html": "<p>एजेंटिक इन्फ्रास्ट्रक्चर की दुनिया में कुछ दिलचस्प हो रहा है, और यह वह नहीं है जिसकी ज्यादातर लोगों को उम्मीद थी। पिछले दो सालों में, एजेंट्स को ज्ञान तक पहुंच देने का प्रमुख तरीका Retrieval-Augmented Generation रहा है: अपने दस्तावेज़ों को embed करो, उन्हें एक vector database में स्टोर करो, और मॉडल को inference के समय उन्हें query करने दो। RAG काम किया। यह काफी अच्छा था। लेकिन \"काफी अच्छा\" की एक समय-सीमा होती है, और 2026 में वह समय-सीमा खत्म हो रही है।</p>\n\n<p>इंडस्ट्री में एक नया पैटर्न उभर रहा है, और यह एक साथ कई दिशाओं से आ रहा है। Mintlify ने अपनी पूरी RAG पाइपलाइन को एक वर्चुअल फाइलसिस्टम से बदल दिया और session creation 46 सेकंड से घटकर 100 मिलीसेकंड हो गई [1]। Turso ने AgentFS बनाया, एक SQLite-backed फाइलसिस्टम जो हर एजेंट को अपना copy-on-write sandbox देता है [2]। Box, एंटरप्राइज कंटेंट की दिग्गज कंपनी, ने घोषणा की कि वह अपने पूरे प्लेटफॉर्म को AI एजेंट्स के लिए एक वर्चुअल फाइलसिस्टम लेयर के रूप में पुनर्स्थापित कर रही है [3]। और ByteDance ने OpenViking को open-source किया, एक context database जो सभी एजेंट मेमोरी, रिसोर्स और स्किल्स को एक hierarchical फाइलसिस्टम के रूप में व्यवस्थित करता है [4]।</p>\n\n<p>ये कोई छोटे-मोटे प्रयोग नहीं हैं। ये एक बुनियादी बदलाव के संकेत हैं। <strong>फाइलसिस्टम एजेंट कॉग्निशन का यूनिवर्सल इंटरफेस बनता जा रहा है, और डेटाबेस चुपचाप इसका सब्सट्रेट बन रहा है।</strong></p>\n\n<h2>RAG क्यों दीवार से टकराया</h2>\n\n<p>RAG 2023 के लिए सही जवाब था। आपके पास दस्तावेज़ों का ढेर था, एक सीमित context window वाला मॉडल था, और आपको query के समय प्रासंगिक chunks सामने लाने का तरीका चाहिए था। Vector embeddings और similarity search ने उस समस्या को बड़े सुंदर तरीके से हल किया।</p>\n\n<p>लेकिन एजेंट्स chatbots नहीं हैं। एक एजेंट एक सवाल पूछकर नहीं चला जाता। वह explore करता है। एक फाइल पढ़ता है, एक reference खोजता है, उसे follow करता है, दूसरी फाइल पढ़ता है, एक command चलाता है, एक output लिखता है। यह retrieval की समस्या नहीं है। यह navigation की समस्या है।</p>\n\n<p>RAG पाइपलाइन्स इसके लिए तीन कारणों से संघर्ष करती हैं। पहला, वे डिज़ाइन से stateless हैं। हर query स्वतंत्र है; \"मैं अभी इस directory को देख रहा था, अब मुझे adjacent फाइल दिखाओ\" जैसी कोई अवधारणा नहीं है। दूसरा, वे structure को flatten कर देती हैं। sections, pages और code examples की स्पष्ट hierarchy वाली एक documentation site 512-token के anonymous chunks में टुकड़े-टुकड़े हो जाती है जो अपना organizational context खो देती है। तीसरा, वे scale पर महंगी हैं। Embedding computation, vector index maintenance, और re-ranking सब मिलकर latency और cost बढ़ाते हैं जो corpus के बढ़ने के साथ और बढ़ते जाते हैं।</p>\n\n<p>फाइलसिस्टम तीनों को हल करता है। यह स्वाभाविक रूप से stateful है (एजेंट के पास एक working directory है)। यह structure को preserve करता है (directories, subdirectories, files)। और यह तेज़ है क्योंकि operations सरल हैं: <code>ls</code>, <code>cat</code>, <code>grep</code>, <code>find</code>। ये कोई नई abstractions नहीं हैं। ये computing में सबसे battle-tested interface हैं।</p>\n\n<h2>अभिसरण: चार दृष्टिकोण, एक पैटर्न</h2>\n\n<p>इस पल को महत्वपूर्ण बनाने वाली बात यह है कि फाइलसिस्टम पैटर्न बहुत अलग-अलग संदर्भों में स्वतंत्र रूप से उभर रहा है।</p>\n\n<p><strong>Mintlify का ChromaFs</strong> शायद सबसे instructive उदाहरण है। Mintlify हजारों कंपनियों के लिए documentation assistants चलाता है। उनका मूल architecture textbook RAG था: docs को chunk करो, embed करो, query के समय retrieve करो। जब उन्होंने इसे ChromaFs से बदला — एक वर्चुअल फाइलसिस्टम जो UNIX commands को intercept करता है और उन्हें Chroma database queries में translate करता है — तो परिणाम नाटकीय थे। Session creation 46 सेकंड से 100 मिलीसेकंड हो गई, यानी 460x सुधार। प्रति conversation marginal cost $0.0137 से effectively शून्य हो गई [1]। मुख्य insight: एजेंट पहले से जानता है कि फाइलसिस्टम को कैसे navigate करना है। उसे <code>cat /auth/oauth.mdx</code> इस्तेमाल करना सिखाना, सही vector query बनाना सिखाने की तुलना में बेहद आसान है।</p>\n\n<p><strong>Turso का AgentFS</strong> एक अलग समस्या पर हमला करता है: एजेंट isolation और auditability। हर एजेंट को copy-on-write semantics के साथ अपना SQLite-backed फाइलसिस्टम मिलता है। Host फाइलसिस्टम एक read-only base layer है; एजेंट एक SQLite delta layer पर लिखता है। हर file operation, tool call, और state change रिकॉर्ड होता है। पूरा एजेंट runtime — files, state, history — एक single portable SQLite फाइल में फिट हो जाता है [2]। यह सिर्फ एक फाइलसिस्टम नहीं है। यह एक auditable, reproducible execution environment है।</p>\n\n<p><strong>Box का enterprise VFS</strong> सबसे रणनीतिक रूप से महत्वपूर्ण है। Box के CEO Aaron Levie स्पष्ट रहे हैं: एजेंट्स को enterprise में knowledge work करने के लिए एक फाइलसिस्टम चाहिए [3]। लेकिन Box एक literal फाइलसिस्टम नहीं बेच रहा। वे एक \"dynamic data delivery contract\" बेच रहे हैं जो object storage, relational databases, या उनके अपने content platform द्वारा backed हो सकता है। फाइलसिस्टम interface है; backing store वह है जो data के लिए उचित हो। Box के play को दिलचस्प बनाने वाली बात governance layer है: permissions, audit trails, और compliance boundaries जो content platform से एजेंट तक automatically carry over होती हैं।</p>\n\n<p><strong>ByteDance का OpenViking</strong> इस पैटर्न को सबसे आगे ले जाता है। यह सभी एजेंट context — memories, resources, skills, knowledge — को standard फाइलसिस्टम semantics का उपयोग करते हुए एक <code>viking://</code> protocol के तहत व्यवस्थित करता है। एजेंट <code>ls</code> और <code>find</code> से navigate करते हैं। लेकिन चतुर हिस्सा tiered access model है: हर piece of context को तीन layers में process किया जाता है। L0 त्वरित retrieval के लिए एक-वाक्य का सारांश है। L1 planning के लिए core information के साथ एक overview है। L2 गहरे पढ़ने के लिए पूरा content है [4]। एजेंट L0 से शुरू करता है, जब अधिक की जरूरत हो तो L1 में जाता है, और केवल तब L2 लोड करता है जब वह विस्तृत काम कर रहा हो। LoCoMo benchmark पर, इसने token consumption को 24.6 मिलियन से 4.2 मिलियन तक कम किया जबकि task completion rates 52% तक बढ़ गई [4]।</p>\n\n<h2>फाइलसिस्टम बतौर Interface, डेटाबेस बतौर Substrate</h2>\n\n<p>चारों को जोड़ने वाला पैटर्न वह है जिसे मैं <strong>VFS duality</strong> कहूंगा: फाइलसिस्टम interface के रूप में जीतता है, और डेटाबेस substrate के रूप में जीतता है। यह either-or का चुनाव नहीं है। यह एक layered architecture है।</p>\n\n<p>फाइलसिस्टम interface के रूप में क्यों जीतता है, यह सीधा है। LLMs को internet पर train किया गया है, और internet उन developers द्वारा बनाया गया है जो files, directories, paths, और command-line tools के संदर्भ में सोचते हैं। Models इन primitives के साथ असाधारण रूप से सक्षम हैं क्योंकि उन्होंने developers के codebases navigate करने, files पढ़ने, और shell commands चलाने के अरबों उदाहरण देखे हैं। जब आप एक एजेंट को फाइलसिस्टम देते हैं, तो आप उसे वहां मिल रहे हैं जहां उसका training data रहता है।</p>\n\n<p>डेटाबेस substrate के रूप में क्यों जीतता है, यह भी उतना ही स्पष्ट है। जिस क्षण एजेंट मेमोरी को share, audit, multiple एजेंट्स द्वारा query, या concurrency के तहत reliable बनाने की जरूरत होती है, आपको database guarantees चाहिए। ACID transactions, access control, semantic search, version history: ये कठिन समस्याएं हैं जिन्हें databases ने दशकों में हल किया है। इन्हें एक literal फाइलसिस्टम के ऊपर फिर से implement करना दर्द का रास्ता है।</p>\n\n<p>VFS pattern आपको दोनों देता है। एजेंट files और directories देखता है। System tables, indexes, और access control lists देखता है। ChromaFs सब कुछ Chroma में store करता है लेकिन files के रूप में expose करता है। AgentFS सब कुछ SQLite में store करता है लेकिन POSIX फाइलसिस्टम के रूप में expose करता है। OpenViking अपने storage engine का उपयोग करता है लेकिन <code>viking://</code> paths के रूप में expose करता है। Box अपने enterprise content platform का उपयोग करता है लेकिन एक navigable tree के रूप में expose करता है।</p>\n\n<h2>क्या VFS वास्तव में Native Filesystem को हरा सकता है?</h2>\n\n<p>इस सब पर स्वाभाविक आपत्ति है: real फाइलसिस्टम का उपयोग क्यों न करें? POSIX वहीं है। हर operating system इसके साथ आता है। एक abstraction layer क्यों जोड़ें?</p>\n\n<p>मैं इस सवाल का empirically जवाब देना चाहता था, इसलिए मैंने <a href=\"https://github.com/subramanya1997/markdownfs\">markdownfs</a> बनाया, Rust में एक from-scratch वर्चुअल फाइलसिस्टम जो विशेष रूप से agent workloads के लिए designed है [6]। यह UNIX-like commands का पूरा set support करता है (<code>ls</code>, <code>cat</code>, <code>grep</code>, <code>find</code>, <code>chmod</code>, <code>chown</code>), content-addressable storage के साथ Git-style versioning, multi-user permissioning, और तीन access methods expose करता है: एक CLI/REPL, एक HTTP/REST API, और एक MCP server जिससे Claude और Cursor जैसे एजेंट सीधे connect कर सकते हैं।</p>\n\n<p>Architecture सरल है: SHA-256 hashing का उपयोग करते हुए content-addressable blob store द्वारा backed एक in-memory inode table, safe concurrent access के लिए <code>tokio::RwLock</code> के साथ। Files automatically deduplicate होती हैं। Version control Git जैसा commit/revert model उपयोग करता है, लेकिन फाइलसिस्टम level पर। Persistence atomic bincode snapshots के माध्यम से handle होती है।</p>\n\n<p>जब मैंने standard agent operations (file creation, reads, writes, directory listing, grep, find, move, copy, deletion) में markdownfs को native फाइलसिस्टम के खिलाफ benchmark किया, तो markdownfs औसतन <strong>130x तेज़</strong> रहा। कारण structural हैं, आकस्मिक नहीं। In-memory operations disk I/O को पूरी तरह खत्म करते हैं। Content-addressable storage का मतलब है duplicate files एक बार store होती हैं। Zero-copy reads का मतलब है एजेंट को serialization overhead के बिना data मिलता है। और क्योंकि पूरी फाइलसिस्टम state एक single process में रहती है, कोई system call boundaries cross नहीं करनी पड़तीं।</p>\n\n<p>तुलना उन operations के लिए विशेष रूप से stark है जो एजेंट सबसे अधिक बार करते हैं:</p>\n\n<table>\n<thead>\n<tr><th>Operation</th><th>VFS क्यों जीतता है</th></tr>\n</thead>\n<tbody>\n<tr><td><strong>Repeated reads</strong> (एजेंट context दोबारा पढ़ना)</td><td>In-memory, zero-copy। कोई disk seeks नहीं, कोई page cache misses नहीं।</td></tr>\n<tr><td><strong>grep across files</strong> (एजेंट patterns खोजना)</td><td>सारा content in-memory है। कोई directory traversal नहीं, कोई file handle management नहीं।</td></tr>\n<tr><td><strong>Rapid file creation</strong> (एजेंट work artifacts बनाना)</td><td>कोई filesystem journaling नहीं, disk पर कोई inode allocation नहीं, कोई fsync नहीं।</td></tr>\n<tr><td><strong>Directory listing</strong> (एजेंट structure explore करना)</td><td>BTreeMap lookup बनाम readdir syscalls।</td></tr>\n</tbody>\n</table>\n\n<p>लेकिन performance असली तर्क नहीं है। असली तर्क वह है जो native फाइलसिस्टम <em>नहीं कर सकता</em>। एक POSIX फाइलसिस्टम में semantic search की कोई अवधारणा नहीं है। इसमें built-in versioning नहीं है (उसके लिए आपको Git चाहिए)। इसमें tiered access model नहीं है (आपको पूरी फाइल मिलती है या कुछ नहीं)। इसमें content deduplication नहीं है। इसमें एजेंट operations का कोई audit trail नहीं है। और critically, इसमें कोई MCP interface नहीं है, जिसका मतलब है एजेंट उस standard protocol के माध्यम से इसे access नहीं कर सकते जिस पर ecosystem converge हो रहा है।</p>\n\n<p>VFS सिर्फ तेज़ नहीं है। यह एक richer primitive है। यह आपको <code>ls</code> और <code>cat</code> का परिचित interface देता है जबकि वे capabilities जोड़ता है जिनकी एजेंट्स को वास्तव में जरूरत है: versioning, permissions, search, deduplication, और MCP या HTTP के माध्यम से protocol-native access।</p>\n\n<h2>RAG के लिए इसका क्या मतलब है</h2>\n\n<p>स्पष्ट रहें, RAG मरा नहीं है। Vector search fuzzy, semantic queries के लिए मूल्यवान बना रहता है जहां एजेंट वास्तव में नहीं जानता कि वह क्या ढूंढ रहा है। लेकिन ईमानदार आकलन यह है कि RAG का अत्यधिक उपयोग हुआ है। कई use cases जहां teams ने RAG pipelines deploy किए — documentation retrieval, codebase navigation, enterprise knowledge management — फाइलसिस्टम interface से बेहतर serve होते हैं।</p>\n\n<p>सबूत striking है। Mintlify का 460x speedup RAG को augment करने से नहीं, बल्कि उसे फाइलसिस्टम से replace करने से आया [1]। Letta के research से पता चलता है कि simple फाइलसिस्टम operations का उपयोग करने वाले एजेंट memory benchmarks पर 74% accuracy हासिल करते हैं, जो specialized retrieval tools के competitive है। और agentic keyword search approaches vector databases के बिना RAG performance का 90% से अधिक हासिल कर सकती हैं [5]।</p>\n\n<p>भविष्य likely hybrid होगा। Open-ended semantic search के लिए RAG। Structured navigation और task execution के लिए फाइलसिस्टम। लेकिन gravity का केंद्र फाइलसिस्टम की ओर shift हो रहा है, और strategic implications महत्वपूर्ण हैं।</p>\n\n<h2>रणनीतिक अनिवार्यता</h2>\n\n<p>अगर आप agentic infrastructure बना रहे हैं, तो आपको एक VFS strategy चाहिए। यहां बताया गया है क्यों।</p>\n\n<p><strong>SaaS companies के लिए</strong>: Box से सबक यह है कि फाइलसिस्टम एजेंट्स के लिए integration surface बन रहा है। अगर आपके platform का content फाइलसिस्टम के रूप में navigable नहीं है, तो एजेंट आपको bypass कर देंगे। जो SaaS companies अपना data filesystem-like interfaces के माध्यम से expose करती हैं, वे agentic workflow का हिस्सा बनेंगी। जो नहीं करतीं, वे एजेंट्स के लिए invisible हो जाएंगी, जिसका मतलब है users के लिए invisible।</p>\n\n<p><strong>Infrastructure vendors के लिए</strong>: डेटाबेस कहीं नहीं जा रहा। यह फाइलसिस्टम के नीचे move हो रहा है। यह वास्तव में database companies के लिए अच्छी खबर है। Turso ने इसे समझा और SQLite के ऊपर AgentFS बनाया। हर एजेंट जो spin up होता है एक नया database बनाता है। दुनिया जितने अधिक एजेंट चलाती है, उतने अधिक databases की जरूरत होती है। लेकिन डेटाबेस को एक फाइलसिस्टम abstraction के पीछे disappear होना होगा।</p>\n\n<p><strong>Enterprises के लिए</strong>: governance की कहानी मायने रखती है। Box की pitch वास्तव में filesystems के बारे में नहीं है। यह इस बारे में है कि उनका permission model, audit trail, और compliance infrastructure automatically एजेंट्स तक extend होता है जब content VFS layer के माध्यम से access किया जाता है [3]। यह हर CISO के सवाल का जवाब है: \"हम एजेंट्स को अपना content access करने कैसे दें बिना security nightmare बनाए?\"</p>\n\n<h2>Unifying Layer</h2>\n\n<p>Agentic infrastructure stack स्पष्ट phases में evolve हो रहा है: tools (MCP), skills, और context graphs। वर्चुअल फाइलसिस्टम इस arc में तीनों के लिए <strong>delivery mechanism</strong> के रूप में fit होता है। MCP tools फाइलसिस्टम के माध्यम से invoke होते हैं। Skills files के रूप में store होती हैं। Context graphs directory trees के रूप में navigate होते हैं। फाइलसिस्टम इन layers को replace नहीं करता। यह उन्हें एक single, familiar interface के पीछे unify करता है।</p>\n\n<p>यही असली insight है। फाइलसिस्टम कोई नया idea नहीं है। यह computing में सबसे पुरानी abstraction है। लेकिन यही कारण है कि यह एजेंट्स के लिए काम करता है। एक ऐसी दुनिया में जहां हम हर तिमाही नए paradigms invent कर रहे हैं, सबसे शक्तिशाली कदम शायद सबसे proven interface की ओर वापस पहुंचना और उसके पीछे एक modern database रखना हो।</p>\n\n<p>जो companies इसे समझती हैं — Mintlify, Turso, Box, ByteDance — कुछ नया नहीं बना रहीं। वे कुछ पुराने को पहचान रही हैं और उसे एक नई नौकरी दे रही हैं।</p>\n\n<h2>संदर्भ:</h2>\n\n<p>[1] <a href=\"https://www.mintlify.com/blog/how-we-built-a-virtual-filesystem-for-our-assistant\">Mintlify. (2026, April 2). <em>How we built a virtual filesystem for our Assistant</em>. Mintlify Blog.</a></p>\n\n<p>[2] <a href=\"https://turso.tech/blog/agentfs\">Turso. (2026). <em>The Missing Abstraction for AI Agents: The Agent Filesystem</em>. Turso Blog.</a></p>\n\n<p>[3] <a href=\"https://www.blocksandfiles.com/ai-ml/2026/03/09/box-pitches-virtual-filesystem-layer-for-ai-agents/5208017\">Blocks and Files. (2026, March 9). <em>Box pitches 'virtual filesystem' layer for AI agents</em>. Blocks and Files.</a></p>\n\n<p>[4] <a href=\"https://github.com/volcengine/OpenViking\">Volcengine. (2026). <em>OpenViking: An open-source context database for AI Agents</em>. GitHub.</a></p>\n\n<p>[5] <a href=\"https://signals.aktagon.com/articles/2026/02/keyword-search-is-all-you-need-achieving-rag-level-performance-without-vector-databases-using-agentic-tool-use/\">Signals. (2026, February). <em>Keyword Search is All You Need: Achieving RAG-Level Performance Without Vector Databases Using Agentic Tool Use</em>. Signals.</a></p>\n\n<p>[6] <a href=\"https://github.com/subramanya1997/markdownfs\">Subramanya N. (2026). <em>markdownfs: A high-performance, concurrent markdown database built in Rust</em>. GitHub.</a></p>",
  "source_hash": "sha256:ea80be6a7f1e92f4b1cd368f4ce0178d49cbe7579c9693b08d174d40c5961953",
  "model": "claude-sonnet-4-6",
  "generated_at": "2026-04-13T19:27:18.107146+00:00"
}