IMO, for real file systems, just give a view via cgroups/namespaces.
Implementing a database abstraction as a file system for an LLM feels like an extra layer of indirection for indirection's sake: just have the LLM write some views/queries/stored procs and give it sane access permissions.
LLMs are smart enough to use databases, email, etc without needing a FUSE layer to do so, and permissions/views/etc will keep it from doing or seeing stuff it shouldn't. You'll be keeping access and permissions where they belong, and not in a FUSE layer, and you won't have to maintain a weird abstraction that's annoying/hampered with licensing issues if you want to deploy it cross platform.
Also, your simplified FUSE abstraction will not map accurately to the state of the world unless you're really comprehensive with your implementation, and at that point, you might as well be interacting directly in order to handle that state accurately.
Agree that to far fetched mappings to files don’t really make sense. The email example is more illustrative then real world inspired, thought it might be good to show how flexible the approach is.
I think there is a gap between “real file systems” and “non file things in a database” where mapping your application representation of things to a filesystem is useful. Basically all those platforms that let users upload files for different purposes and work with them (ex Google Drive, notion, etc). In those cases representing files to an agent via a filesystem is the more intuitive and powerful interface compared to some home grown tools that the model never saw during training.
See my own https://github.com/matthiasgoergens/git-snap-fs which lets you expose all branches and all tags and all commits and all everything in a git repository as a static directory tree. No need to git checkout anything: everything is already checked out.
LLMs can handle Google drive perfectly well with a service account, including the Google drive specific quirks through the API. It could be helpful to expose via a file system rather than a custom API if you wanted a different interface than Google already provides, but this wouldn’t be driven by the limitations of the LLM.
In terms of ergonomics, I’d say a filesystem is more intuitive for an agent than the Google Drive API even if it can handle both. Hard to argue without building an eval set and evaluating both, though.
I’ve been doing this recently and for the basics agents had no problem with the API apart from the weird behaviour of shared drives needing a special flag to handle them. This could probably be mapped to a file system in a way that wouldn’t trip up an agent, but at the expense of losing the Google drive specific functionality. A trade off, not much better or worse per se, but with the added complexity of the FUSE layer.
The less juggling of concepts thr more effective any problem solver cam be.