We often obsess about model size, training datasets and latency – but forget that the file system an AI agent uses is where real-world utility and risk collide. The friction of safely, efficiently exposing user files to an agent is an architectural problem, not a purely ML one.
Context
I recently came across an interesting project that tackled the gap between agentic systems and multi-tenant file storage. The developer catalogued the trade-offs of approaches like VMs/sandboxes, S3 mounts, language-specific reimplementations of shell utilities, and ultimately adopted an SDK-backed, scoped filesystem (AgentFS) built on Turso/SQLite – only to be blocked in production by upstream limitations around multi-database write attachments.
Analysis – what this means for architecture and product strategy
There are three overlapping constraints here that every CTO and architect must internalize when designing agent-powered products: security, scale, and performance.
– Security (least privilege by design). Giving an agent a full shell is equivalent to granting adaptive remote execution; it invites both accidental damage and intentional exploitation. The safer pattern is explicit tool wiring: expose only read/write/list/search primitives and enforce per-session/user scope. This is the essence of a zero-trust stance applied to agent tooling – limit the surface area and make isolation part of the API contract, not an afterthought.
– Scale (multi-tenant state without multi-tenant complexity). Storing each user’s workspace as separate DB files is simple locally but operationally infeasible at cloud scale. The desire for a database-per-user model is understandable (isolation, backup granularity), but production requires a routing layer or a multi-DB host that supports attachable read-write mounts. When upstream storage services impose read-only cross-attaches, you face an architectural impasse: you can prototype, but not ship multi-user production safely without workarounds that reintroduce risk or cost.
– Performance (native ops vs. object storage). Mounting object storage as a POSIX filesystem often hides the cost of network IO until grep or find runs, at which point latency and request overhead kill UX. For agents that “navigate” files rather than ingest them wholesale into context, efficient server-side search primitives (metadata indexes, precomputed shards, or SQL-backed content scanning) are non-optional.
Build vs Buy – pragmatic guidance
This case neatly frames the classic decision for platform builders. Buy (use an off-the-shelf mount or sandbox) reduces initial engineering effort but shifts risk into operational and cost domains: cold starts for VMs, slow scans for mounted object stores, or leaky abstractions in FUSE. Build (custom SDK and search primitives) gives control and better security guarantees but requires owning indexing, routing, and multi-tenant DB orchestration.
My recommendation for engineering leaders:
– Treat the filesystem as a service: expose a narrow, well-documented tool surface (read/write/list/search) and implement strong per-session auth and isolation at the API layer.
– Build server-side search and metadata indexes rather than relying on remote mounts to behave like local disks.
– Evaluate the hosted DB’s roadmap closely. If your architecture depends on a storage feature (e.g., read-write ATTACH across many DBs), require concrete timelines and fallbacks before committing.
– Prototype with per-user SQLite files locally, but design the production routing layer (connection proxy, logical DB mapping) from day one to avoid expensive rework.
Localization: why this matters for India (and regions with intermittent connectivity)
In markets like many parts of India – including the Northeast – bandwidth variability and higher latency make the cost of naive remote mounts even more tangible. An offline-first or hybrid pattern (local indexes + server sync, or database-backed search) isn’t just an optimization; it becomes a necessity for good UX. For public-sector or MSME deployments on constrained networks, minimizing chat-time IO and keeping computations server-side reduces both costs and failure modes.
Takeaways
– Zero-trust tooling > exposing shells. Limit what agents can do explicitly.
– Server-side search and metadata indexing are core platform responsibilities.
– Don’t commit to a storage stack without confirmed production features or a clear fallback.
– Design for network variability if your users are in connectivity-constrained regions.
Closing thought
The jump from prototype to production for agentic systems is rarely about models – it’s about durable, secure, and scalable state management. Solve the filesystem problem with the same rigor you apply to data governance, and the rest becomes engineering.
About the Author
Sanjeev Sarma is the Founder Director of Webx Technologies Private Limited, a leading Technology Consulting firm with over two decades of experience. A seasoned technology strategist and Chief Software Architect, he specializes in Enterprise Software Architecture, Cloud-Native Applications, AI-Driven Platforms, and Mobile-First Solutions. Recognized as a “Technology Hero” by Microsoft for his pioneering work in e-Governance, Sanjeev actively advises state and central technology committees, including the Advisory Board for Software Technology Parks of India (STPI) across multiple Northeast Indian states. He is also the Managing Editor for Mahabahu.com, an international journal. Passionate about fostering innovation, he actively mentors aspiring entrepreneurs and leads transformative digital solutions for enterprises and government sectors from his base in Northeast India.
