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.