I was having exact same observation, albeit from a bit diffrent perspective: SaaS. This is where as the code tends to be temporary and very domain specific, the data (files) must strive to be boring standards.
The problem today is that we build specific, short-lived apps that lock data into formats only they can read. If you don't use universal formats, your system is fragile. We can still open JPEGs from 1995 because the files don't depend on the software used to make them. Using obscure or proprietary formats is just technical debt that will eventually kill your project. File or forget.
My 10+ year old photo management system [1] relies on the file system and EXIF as the source of truth for my entire photo library.
It’s proven several times over that it’s the correct approach. Abstractions (formerly Google photos, currently Immich) should just be built on top - but these proprietary databases are only for convenience.
For work, I’m having the same experience as the author and everything is just markdown and csv files for Claude Code (for research and document writing).
I know some systems leverage the modern file meta data (extended attributes), but it's clearly not successful enough that folks can use them for an application like this.
Ostensibly, things like MacOS Spotlight can bring real utility and value to the file system, and extended attributes through the sidecar indexing, etc. But Spotlight is infamous for its unreliability.
The other issue with file systems is simply that the user (potentially) has "direct access" to them, in that they can readily move files in and up and around whimsically. The "structure" is laid bare for them to potentially interfere with, or, such as the case with the extended attributes, drag a file to a USB fob, and then copy it back -- inadvertently removing those attributes.
And thats how we end up with everything being stuffed into a SQLite DB.
Yeah, IMO extended metadata attributes are fine for caching data that can be recovered via other means but generally violate the principal of least surprise. For them to be successful a standardized transparent container format or something would be necessary, but at that point the FS abstraction is leaking.
I have your repo starred from a post/comment you made a few weeks ago but haven't had time to actually use/integrate it with my own stuff.
What are your thoughts on XMP sidecar files? I'm torn right now between digital negative + external metadata versus all-in-one image with mutable properties. Portability vs. Durability etc.
I've avoided using XMP sidecars. Mostly because I don't want to have to worry about two files for every photo. And I don't think they're ubiquitously supported like EXIF.
Thanks for starring the repo and let me know if you need any help.
The frustrating thing about photo management these days is how every major photo library app/cloud service these days stores every edit / tag / album externally. If you crop a photo, change the taken at date, etc, the original file never gets touched but an external bit of metadata is created. So any time you move platform, all of these edits and your albums are erased.
It is convenient to be able to undo crops or filters, but I wish the industry would standardize so these changes are portable.
Files are a fundamental freedom because they enable users to have custody of data, thus enabling ultimate sovereignty of confidentiality, integrity, and availability.
We should recognize files as an essential pillar of digital liberty, on par with FOSS licensing.
Indeed, that's why it bothers me that major technology vendors, especially Apple, would like to do away with the very concept of files, at least for non-power users.
They make it seem like data is bound up with apps, and should not have an independent existence. They also make it hard to import/export data, except via backups, which a very crude way of taking control of your personal data.
I'm working on a tool to work around these issues to the extent possible, allowing users to extract their information, as granular files, from device backups into their personal digital library. For immutable data, archival is ok, but for editable data, the biggest challenge is how to make the extracted data "live", i.e., available and editable on the devices again, preferably in the same apps used to create them. There seems to be no good solutions.
Apple keep their casual users on a short leash, but for those willing to tinker, iOS device backups are actually quite good for that archive use case, as you can extract most of your important data in the form of SQLite database files. The whole process is high friction and very user-unfriendly, and open documentation of these databases is lacking, but the fact that this route still exists at all is encouraging (in the sense that all hope is not yet lost). They could very easily have hidden all these files behind an Apple-managed encryption key. On the other hand, this niche affordance may serve to placate the power users who would be most likely to cause noise and revolt if our personal needs were not met. On the gripping hand, the device backup mechanism via iTunes feels so ancient that they probably just haven’t thought about it.
> The whole process is high friction and very user-unfriendly, and open documentation of these databases is lacking
Yeah, that's what I want to abstract way. There are tools that do this to some extent, but they stop at backup extraction, without helping you to integrate the extracted data into a proper personal digital library with easy retrieval.
Configuration files are the greater than a central repository like Windows Registry. They allow temporary changing and ease of sharing how an application operates. They also create a well defend meaning of the settings.
This is why I do not like how Windows has been implemented, they treat files like a 3rd class citizen versus a 1st class.
I would add that it’s largely due to LLM’s extraordinary ability to infer. Natural plain language live in files and we no longer have to worry about structure. Legibility is the spec and anyone decent enough to be legible will write to a file. REPL away.
It pulled back Plan 9, and I was shocked: this is exactly what we need today, as I'm convinced we need to think about minimizing agent permissions the exact same way companies do. Plan 9 was just too early.
It was too dogmatic. Lowest common denominator meant APIs had to shove square pegs through round holes. Unix had already partially gone down that path and stopped. IMO with good reason.
Then again, perhaps in this era of ever expanding storage and compute, maybe someone can make it work even better?
There's nothing "dogmatic" about containerization and providing services through userspace (IPC that's modeled as interaction with custom filesystem trees) rather than bespoke syscalls whenever feasible, which are basically the foundations of the plan9 approach. We do strive to do both in modern systems, but the approach to the problem space is clumsily bolted over the original system interfaces, and becomes overly complicated rather than elegant.
We once again discover that Plan9 and UNIX were right. The most powerful, lowest common denominator interface is text files exposed over a file system. Now to get back to making 9p2026.
The article gets some fundamentals completely wrong though: file systems are full graphs, not strict trees and are definitely not acyclic
Plan9 doesn't really have a single killer feature beyond 9P and the universal consistency and simplicity of its APIs. It has a very clean syscall interface and takes "everything is a file" to its logical conclusion and does it well (IMO). Pretty much everything is a file(system) and it's all accessed via the 9P protocol.
You could sorta bolt these features on with FUSE, but to see real benefits you'd want something closer to Inferno, which is like an OS/application runtime that runs on top of another OS host.
In my mind, the security model is the closest thing to a killer feature it has. Because everything is a file(system) and the fork/rfork and bind syscalls let you precisely control what resources/files/services/etc. a child process has access to via easily understandable shell commands (or using libc functions if you want), it means you don't need special APIs for namespacing (ie. containers) and access controls. It's very clean. When a parent process forks or spawns a child process, it can chose whether that process inherits the namespace or gets a clean slate that it can then bind filesystems onto, controlling precisely what it has access to.
The deeper magic is that the kernel interface is completely rewritten compared to *nix or even Linux. Most programs in plan9 are expected to issue requests through userspace-provided services, not bespoke syscalls.
Funny, decades ago (mid-80s), I had to write a onetime fix on a what would be now a very low memory system, the data in question had a unique key of 8 7bit-ascii characters.
Instead of reading multi-meg data into memory to determine what to do, I used the file system and the program would store data related to the key in sub directories instead. The older people saw what I did and thought that was interesting. With development time factored in, doing it this way ended up being much faster and avoided memory issues that would have occurred.
Reminds me of early data driving approaches. Early CD based game consoles had memory constraints, which I sidestepped by writing the most ridiculous simple game engine: the game loop was all data driven, and "going somewhere new" in the game was simply triggering a disc read given a raw sector offset and the number of sectors. That read was then a repeated series of bytes to be written at the memory address given by the first 4 bytes read and next 4 bytes how many bytes to copy. That simple mechanism, paired with a data organizer for creating the disc images, enabled some well known successful games to have "huge worlds" with an executable under 100K, leaving the rest of the console's memory for content assets, animations, whatever.
Which games were these out of interest? I enjoy reading about game dev from the nascent era of 3D on home consoles (on the Saturn in particular) and would love to hear more.
Over a number of files similar to a codebase, that are well organized (like a codebase) the coding agents and harnesses are quite good at finding information, they clearly train on them so they will only improve.
The challenge is how to structure messy data as a filesystem the agent can use. That is a lot harder than querying a vector db for a semantic query.
The code bases we’ve been using agents in had been pruned and maintained over years, we’ve got principles like DRY that pushed us to put the answer in one place… implicitly building and maintaining that graph with all the actors in the system invested in maintaining this. This is not the case for messy data, so while I see the authors point and agree that a filesystem is a better structure for context over time, we haven’t supplanted search yet for non-code data.
Resonates deeply with me. I’ve moved personal data out of ~10 SaaS systems into a single directory structure in the last year. Agents pay a higher price for fragmentation than humans. A well-organized system of files eliminates that fragmentation. It’s enough for single player. I suspect we’ll see new databases emerge that enable low multi-player (safe writes etc) scenarios without making the filesystem data more opaque. Not unlike what QMD is for search.
As TFA basically says: files on a filesystem is a DB. Just a very crude one. There aren't nice indexes for a variety of things. "Views" are not really there (arguably you can create different views with links but it's, once again, very crude). But it's definitely a DB, represented as a tree indeed as TFA mentions.
My life's data, including all the official stuff (bank statements, notary acts, statements made to the police [witness, etc.], insurance, property titels), all my coding projects, all the family pictures (not just the ones I took) and all the stuff I forgot, is in files, not in a dedicated DB. But these files are a definitely a database.
And because I don't want to deal with data corruption and even less want to deal with synching now corrupted data, many of my files contains, in their filename, a partial cryptographic checksum. E.g. "dsc239879879.jpg" becomes "dsc239789879-b3-6f338201b7.jpg" (meaning the Blake3 hash of that file has to begin with 6f338201b7 or the file is corrupted).
At any time, if I want to, I can import these in "real" dedicated DBs. For example I can pass my pictures as a read-only to "I'm Mich" (immich) and then query my pictures: "Find me all the pictures of Eliza" or "Find me all the pictures taken in 2016 on the french riviera".
But the real database of my all my life is and shall always be files on a filesystem.
With a "real" database, a backup can be as simple as a dump. With files backuping involve... Making sure you keep a proper version of all your files.
I'd say files are even more important than the filesystem: a backup on a BluRay disc or on an ext4-formatted SSD or on an exfat formatted SSD or on a tape... Doesn't matter: the files are the data.
A filesystem is the first "database" with these data: a crude one, with only simple queries. But a filesystem is definitely a database.
The main advantage of this very simple database is that as long as the data are accessible, you know your data is safe and can always use them to populate more advanced databases if needed.
Treating the filesystem as a database is a useful mental model, but the primitives are weak and you quickly run into missing indexes, mtimes that lie to you, and rename semantics that break queries.
A practical path is a sidecar SQLite metadata DB with columns for path, inode, mtime, sha256 and tags plus an FTS5 table for full text, kept in sync with inotify or fsevents where available and periodic scans elsewhere, and moves can be resolved by matching inode numbers instead of paths to avoid link rot.
Encrypt sensitive documents with age or gpg and use borg, restic or git-annex for deduplicating backups, accepting the extra maintenance of an index and reconciliation logic in exchange for fast queries, virtual views and sane audits.
It's not "crude" if you get hierarchical organization without having to screw around with RECURSIVE, or "closure this" and "closure that". It just works.
Were it more portable BeOS/Haiku's BeFS would have been a perrfect fit in this instance.Seeing that it is a filesystem thah has database properties via extended attributes[1] and indexing.
Were Haiku mor mature/stable would have been a nice fit for the OS for the LLM/Ai personal use cases.
How do you automate hashing and verifying filenames?
I have used rhash (https://github.com/rhash/RHash) before to do something similar - but with all the hashes for a directory stored in a single file (which I can diff against past or future versions).
Backing up private data and verifying it for corruption is crucial.
I think this article just speaks to the immaturity of our use of AI at this "moment."
Production grade systems might be written by agents running on filesystem skills, but the production systems themselves will run on consistent and scalable data structures.
Meanwhile the UI of AI agents will almost certainly evolve away from desktop computers and toward audio/visual interfaces. An agent might get more context from a zoom call with you, once tone and body language can be used to increase the bandwidth between you.
I don't think written prompting will ever go away. Writing helps you organize your thoughts in a way that speaking, umm, ah, wait no, hang on, does not. Writing I can go back and change what I've already written before I hit send. Anybody who's prompted with speech for any length has been "wait no nevermind start over". So STT will get better, sure, it's already quite good. I just don't see text extry entirely going away because Human Intelligence (HI) just doesn't work in a way that speech would be the only interface.
Totally agree. Speech is powerful and it will always have its place. It will continue to evolve and become far more useful than it is today. But at its core, it remains a highly lossy medium compared with text, especially when it comes to expressing (and consuming expressions thereof) ideas. Even the best voice memo cannot rival a clear, well-structured email when it comes to explaining something even moderately complicated.
Voice assistants, AI pins, and whatever other speech-based interfaces they come up with next will always be "nice to have", but I don't think anybody should be throwing away their keyboards anytime soon. We may have transformed how we make computers work for us, yet the ways we interact with them are much harder to revolutionize, because they are grounded in the physical, neurological, and habitual constraints of human existence. All of which is to say, when I look at the future, I still see a lot of typing.
Saw this video recently, by an AI company working to get contextual cues from tone and body language. I think they're converting it to text and feeding it into a LLM, so not natively multimodal, but I still thought it was really cool.
Digression: a file system is a terrible abstraction. The ceremonial file tree, where branches are directories and you have to hang your file on a particular branch like a Christmas ornament.
Relational is better. Hell, and kind of unique identifier would be nice. So many better ways to organize data stores.
Filesystems have a property that changes preserve locality. A change made to one branch of the tree doesn't affect other branches (except for links). Databases lack this property: any UPDATE or DELETE can potentially affect any row depending on the condition. This makes them powerful but also scary. I don't want that every time I delete a file it potentially does a rm -rf / if I mistype the query.
The best compromise is what modern OSs have: a tree-like structure to store files but a database index on top for queries.
You can create the tree structure from a relation. Not a primitive data store operation at all. Just add the attribute: parent directory and voila.
So often we want to look up 'the last file I printed' or 'that message I got from Bob'. Instead of just creating that lookup, we have to go spelunking.
Hell, every major app creates it's own abstractions because the OS/Filesystem doesn't have anything useful. Email systems organize messages and tags; document editors have collections of document aspects they store in a structured blob. Instead of asking the OS to do that.
NTFS has a database, the MFT. It can index attributes, such as file names, which are a b+tree. A file's $DATA is also placed into the MFT, unless it doesn't fit, then NTFS allocates virtual cluster numbers (more MFT attributes) which point to the on-disk data structure of the file.
All files are represented in a table with rows and columns. "Directories" simply have a special "directory = true" attribute in a row (simplified).
The hierarchy is for you, the human.
Like many file systems, NTFS also contains a log for recoverability/rollback purposes.
It's not quite relational but it doesn't make sense to be relational. Why would you need more than one 'table' to contain everything you need to know about a file? Microsoft experimented with WinFS, which wasn't a traditional file system (it was an MSSQL database with BLOB storage which sat ontop of a regular NTFS volume). Performance was bad and Skydrive replaced the need for it (in the view of MSFT).
A dataset can persist across multiple file systems. A UUID is a way to know that one dataset is equivalent (identical) to another.
Now you can cache, store-and-forward, archive and retrieve and know what you have.
UUIDs aren't very good for this use case, a sufficiently large CRC or cryptographic hash is better because it's intrinsically tied to the data's value while UUIDs are not
UUIDs are necessary. It's possible for file contents to be identical (e.g. short configuration files may coincidentally coincide over time and space). Would the hash then be unique?
Consider: you want a certain data object, with a given UUID. You can find it anywhere, even from a malicious server. Then look up the hash in a trusted database, verify it. Impossible then for the MITM to fool you. No more virus scanning executables.
I've been wondering this too: for us, UUIDs are super opaque. But for an agent, two UUIDs are distinct as day and night. Is the best filesystem just blob storage S3 style with good indexes, and a bit of context on where everything lives?
One thing directories solve: they're great grouping mechanisms. "All the Q3 stuff lives in this directory"
I bet we move towards a world where files are just UUIDs, then directory structures get created on demand, like tags.
Filepath is just unique name that model can identify easily and understand grouping.
Uuid solves nothing but requires another mapping from file to short description.
You can have several versions of the same set of data object at once - an entire source set for a build, all the names duplicate but tagged with 'revision' so they can be distinguished.
Hard to do that without a UUID at root, to use for unique identification of the particular 'particle' of the particular data set.
Files work as long as you can find them. This means search and/or indexes - at some scale they start breaking. The question is: how big your agent operated knowledge base needs to be?
I thing the real impact behind the scenes here is Bash(). Filesystem relevance is a bit coincidental to placing an agent on an operating system and giving it full capability over it.
I wonder how much of a lost in the middle effect there is and if there could be or are tools that specifically differentiate optimizing post compaction "seeding". One problem I've run into with open spec is after a compaction, or kicking off a new session, it is easy to start out already ~50k tokens in and I assume somewhat more vulnerable to lost in the middle type effects before any actual coding may have taken place.
Can we bring back Plan9 architecture now? It had what was essentially MCP. You make a custom device driver, and anything really can be a file. Not only that, but you network them, so a file on local disk could be a display on a remote host (or whatever). Just tell the agent to read/write files and it doesn't need to figure out either MCP or tool calls.
This seems like the place to ask. What other big ideas have there been since everything-is-a-file? I’m not aware of any. And it seems like we want another layer of permissions on device & data access we spent have before.
Does this really have to do with file systems? Replacing RAG/context stuffing with tool calls for data access seems like the actual change. Whether the tool call is backed by a file system or DB or whatever shouldn’t matter, right?
I revived my Johnny Decimal system as my single source of truth for almost anything and couldn't be happier. The filing is done mostly by agents now but I still have the overview myself.
In other words, file systems are an excellent way to organise information. I mean, yeah - we've been using them forever.
File systems are not a good abstraction mechanism for remote procedure calls, though. I think it's important to distinguish between the two, since I find there are a lot of articles conflating both - comparing MCPs to SKILLs, which are completely different things.
I think the confusion comes from the fact that MCP came before SKILLs, and there's a mental model where SKILLs are somehow "better than" MCPs. This is like saying local Word documents are better than a fully integrated collaborative office suite. It's just not the same thing.
The reason SKILLs work so well is because there's 50 years of accumulated knowledge of how to run rudimentary Unix tools.
the TLDR
File systems - organising information
MCP/APIs - remote procedure calls
I don't think there's a lot magical about files beyond (a) they are native for LLMs and coding because they both process text and (b)when things are rapidly in flux, unstructured formats prosper because flexibility is king. Literally any fixed format you try and describe becomes rapidly outdated and fails to serve the purpose. For example it feels like MCP is already ageing like milk.
Which is mainly to say, trust me, this is a temporary state, the god of complexity is coming. It is utterly inevitable. The people who created React, Kubernetes, all those Java frameworks you hated etc didn't go away. They are right now thinking about how amazing it would be if you if you stacked ten different tools together with brand new structured file formats and databases. We already have "beads" and "gastown" where this is starting. Enjoy these times because a couple of years from now it will already be the end of the "fun" part I think.
Kind of? iOS does have a file manager which explicitly shows you your own files. They just made a separation between OS/Program files vs the users own files. What more killed files was cloud programs where multiple users can edit at the same time which required a system that was more sophisticated than syncing a file.
Yeah, I'm not sure most normal people use file systems that much.
We spend ours on our laptops and assume others do too. But many people don't even own a laptop. They handle all their computing needs from their phones, using proprietary apps, with the data living in WhatsApp messages.
> He pointed out that Claude Code works because it runs on your computer, with your environment, your data, your context.
Ah yes - I hate that. Yes it "works", but I don't want things to only work on my machine: I want them to work everywhere.
I was wondering why Google's Jules wasn't more popular, and I guess this is why. My preference for my code to work in different environments is unusual.
I'm not too deep into agentic coding, but I hadn't understood why people write `SOUL.md` files like no tomorrow. Does anyone think these will be called the same three years from now?
If you've got a coding convention, enforce it using a linter. Have the LLM write the rules and integrate it into the local build and CI tool.
Has noone ever thought about how – gasp – a future human collaborator would be onboarded?
Not knocking the article in any way but from the headline I was expecting - perhaps hoping - this would be about some innovation in filesystems research like it was the 90's again. That's not what this is.
It's about how filesystems as they are (and have been for decades) are proving to be powerful tools for LLMs/agents.
Yeah, none of it was really about file systems. There was a brief mention that file systems look like a graph, and that you build roughly an index so it looks graph and thus database-y, but you could store it all in a sqlite database with a column, called filename and a column called content for all the details about file systems this post went into. I too was expecting something more in depth about file systems like for instance, cluster file systems have made a little to no advancement. ZFS is not a cluster file system and we've been needing a good one of those for decades, ever since VM's became feasible on consumer grade hardware. Still, files on desk is better than having to pay Oracle a fee per-skill on today's modern, open Internet. That was never going to happen.
And by filesystem they mean CLI (command line interface) and a full *nix system. Like the hundreds of similar articles about it for the past year said.
I have been reading HN for a few years, and my feeling is that I find fewer and fewer interesting articles. Maybe it's just me, and the average articles are the same quality.
Now I tend to skim through it to see if a title looks like it may bring interesting discussions, and then I skim through the discussions. Because there are very knowledgeable people who sometimes share valuable insights.
Interestingly, last time I asked a question, hoping to get interesting people to share insights, I was answered that I "should learn how to use an LLM instead of asking questions" :-).
Same here. Unless a site is known for good quality, I only open articles after checking top comments. Most days I just read the daily digest of discussions - which sometimes piques my curiosity enough to check the original links.
"They're portable, auditable, and composable. No MCP server required. No plugin marketplace to browse. Just a folder with a SKILL.md in it." It screams lazy ai slop copy-paste. Now when I see this kind of obvious llm tell, I can't help but feel betrayed for investing time in giving it a shot in the first place.
> If you're going to do that at least mention it's LLM output
Yes, this! Please label AI generated content. Pull request written by an AI? Label it as ai generated. Blog post? Article generated with AI? Say so! It’s ok to use AI models. Especially if English is your second language. But put a disclaimer in. Don’t make the reader guess.
Eg:
> This content was partially generated by chatgpt
Or
> Blog post text written entirely by human hand, code examples by Claude code
I'm not a fan of AI and try to avoid it, but there is a difference from AI output published by someone knowledgeable and any other AI output that you run by yourself. If an expert looked at the result and found it to be ok, then you can have some assurance that it at least makes sense. Your own AI run doesn't mean anything, it could be 100% hallucination and a non-expert will buy it as truth.
LLMs were trained on stuff that people wrote. I get there are "tells", but don't really think people are as good at identifying AI generated text as they think they are...
I wouldn't have picked this article as AI until I got an agent to do some writing for me and read a bunch of it to figure out if I can stand behind it. Now I see the tells everywhere "It's not this. It's that." is particularly common and I can't unsee it. (FWIW I rewrote most of the writing it generated, but it did help me figure out my structure and narrative)
The problem I think with AI generated posts is that you feel like you can't trust the content once it's AI. It could be partly hallucinated, or misrepresented.
Yeah, but "it's not X. It's Y" is a common idiom that LLMs picked up from people. That's the point i was making. And it's starting to feel like every post has at least one comment claiming that it was AI generated.
Good chunks of the article don't trigger this for me, but I would bet money on the final paragraph involving AI:
> That's not a technical argument. It's a values argument. And it's one that the filesystem, for all its age and simplicity, is uniquely positioned to serve. Not because it's the best technology. But because it's the one technology that already belongs to you.
As the author I can assure you there’s a human behind these words. Interesting times me live in though, I find myself questioning what’s AI and what’s not often too and at the moment we’ve offloaded that responsibility to the good will of authors or platform policy which might have to change soon
I thought it was a great post tying a lot of things I’ve been reading and thinking about together. Could care less if you used AI if it helps my brain expand and or make connections I wouldn’t have otherwise.
What's wild is that with a few minutes of manual editing it would give exponential return. For instance, a lead sentence in your section saying "here's why X" that was already described by your subheading is unnecessary and could have been wholly removed.
That’s pretty presumptive of how obviously the author could improve it. As someone who writes a lot of docs, I find feedback and preferences varies wildly. They may just have well made it “worse” to your preferences by hand editing it more.
Does everyone just easily accuse genuine, literate humans of "cheating" with AI when there's no way they could know that?
There are a lot of unique aspects of the writing in this post that LLMs don't typically generate on their own.
And there's not a "delve" or "tapestry" or even a bullet point to be found.
Also, accusations and complaints like this are off-topic and uninteresting.
We should be talking about filesystems here, not your gut instinct AI detector that has a sky-high false-positive rate.
I swear there needs to be some convention around throwing wild accusations at people you don't know based exclusively on vibes and with zero actual evidence.
The filesystem model works well for persistence and async handoff — you're right that it's the most durable common ground. Where it gets awkward: the synchronous case. An agent that needs a human approval before proceeding.
Most people end up routing these back-to-human calls through Discord/Slack, where the agent shows up as a bot. It works, but agents are structurally second-class there — manual setup, limited API surface, no agent-native identity. The async file interface and the real-time decision channel are solving two different things.
(This is actually what I've been working on: a platform where agents aren't bolted onto human chat as bots, but provision themselves as first-class participants. Files handle state; what handles decisions? That's the gap we're trying to close.)
I don't think this paradigm will last, or be what becomes the more common structure in the future. This will still suffers from conflicts of persona and objective, plus has the issue that individual apps will need protected file hierarchies to prevent malicious injections. I don't see this as a solution, just a deck chair shuffle.
I've been researching and building with a different paradigm, an inversion of the tool calling concept that creates contextual agents of limited scope, but pipelines of them, with the user in triplicate control of agent as author, operator of an application with a clear goal, and conversationally cooperating on a task with one or more agents.
I create agents that are inside open source software, making that application "intelligent", and the user has control to make the agent an expert in the type of work that human uses that software. Imagine a word processor that when used by a documentation author has multiple documentation agents that co-work with the author. While that same word processor when used by a, for example, romance novelist has similar agents but experts in a different literary / document goal. Then do this with spreadsheets, and project management software, and you get an intelligent office suite with amazing levels of user assistance.
In this structure, context/task specific knowledge is placed inside other software, providing complex processes to the user they can conversationally request and compose on the fly, use and save as a new agent for repeated use, or discard as something built for the moment. The agents are inside other software, with full knowledge of that application in addition to task knowledge related to why the user is using that software. It's a unified agent creation and use and chain-of-thought live editing environment, in context with what one is doing in other software.
I wrap the entire structure into a permission hierarchy that mirrors departments, projects, and project staff, creating an application suite structure more secure than this Filesystems approach, with substantially more user controls that do not expose the potential for malicious application. The agents are each for a specific purpose, which limits their reach and potential for damage. Being purpose built, the users (who are task focused, not developers) easily edit and enhance the agents they use because that is the job/career they already know and continue to do, just with agent help.
Your project, while interesting as an approach, is orders of magnitude more complex than the proposition here - which is to rely on agents skills with file systems, bash, python, sed, grep and other cli tools to find and organize data, but also maintain their own skills and memories. LLMs have gained excellent capabilities with files and can generate code on the fly to process them. It's people realizing that you can use a coding agent for any cognitive work, and it's better since you own the file system while easily swapping the model or harness.
I personally use a graph like format but organized like a simple text file, each node prefixed with [id] and inline referencing other nodes by [id], this works well with replace, diff, git and is navigable at larger scales without reading everything. Every time I start work I have the agent read it, and at the end update it. This ensures continuity over weeks and months of work. This is my take on file system as memory - make it a graph of nodes, but keep it simple - a flat text file, don't prescribe structure, just node size. It grows organically as needed, I once got one to 500 nodes.
It ends up being similar to how early PC software was written before people realized malicious software could be running. There used to be little to no memory safety between running programs, and this treatment of files as the contextual running memory is similar. It's a great idea until a security perspective is factored in. It will need to end up being very much like closed applications and their of writing proprietary files, which will need some security layer that is not there yet.
I was having exact same observation, albeit from a bit diffrent perspective: SaaS. This is where as the code tends to be temporary and very domain specific, the data (files) must strive to be boring standards.
The problem today is that we build specific, short-lived apps that lock data into formats only they can read. If you don't use universal formats, your system is fragile. We can still open JPEGs from 1995 because the files don't depend on the software used to make them. Using obscure or proprietary formats is just technical debt that will eventually kill your project. File or forget.
My 10+ year old photo management system [1] relies on the file system and EXIF as the source of truth for my entire photo library.
It’s proven several times over that it’s the correct approach. Abstractions (formerly Google photos, currently Immich) should just be built on top - but these proprietary databases are only for convenience.
For work, I’m having the same experience as the author and everything is just markdown and csv files for Claude Code (for research and document writing).
[1] https://github.com/jmathai/elodie
I know some systems leverage the modern file meta data (extended attributes), but it's clearly not successful enough that folks can use them for an application like this.
Ostensibly, things like MacOS Spotlight can bring real utility and value to the file system, and extended attributes through the sidecar indexing, etc. But Spotlight is infamous for its unreliability.
The other issue with file systems is simply that the user (potentially) has "direct access" to them, in that they can readily move files in and up and around whimsically. The "structure" is laid bare for them to potentially interfere with, or, such as the case with the extended attributes, drag a file to a USB fob, and then copy it back -- inadvertently removing those attributes.
And thats how we end up with everything being stuffed into a SQLite DB.
Yeah, IMO extended metadata attributes are fine for caching data that can be recovered via other means but generally violate the principal of least surprise. For them to be successful a standardized transparent container format or something would be necessary, but at that point the FS abstraction is leaking.
What about using the file name itself as the metadata storage?
I have used this approach with exiftool to add custom tags for “album”.
https://stackoverflow.com/a/68284922
Here is my source file for it. It was so long ago I don’t recall all the details but you can retrieve this information using exif commands.
https://github.com/jmathai/elodie/blob/master/configs/ExifTo...
That works but has strict length limits and is visibly ugly. Fine for very limited cases I guess
I have your repo starred from a post/comment you made a few weeks ago but haven't had time to actually use/integrate it with my own stuff.
What are your thoughts on XMP sidecar files? I'm torn right now between digital negative + external metadata versus all-in-one image with mutable properties. Portability vs. Durability etc.
I've avoided using XMP sidecars. Mostly because I don't want to have to worry about two files for every photo. And I don't think they're ubiquitously supported like EXIF.
Thanks for starring the repo and let me know if you need any help.
Thanks for sharing, I might have too much NIH syndrome to use it but I'd love to check it out.
Ha! I totally get it. Use it for inspiration though!
The frustrating thing about photo management these days is how every major photo library app/cloud service these days stores every edit / tag / album externally. If you crop a photo, change the taken at date, etc, the original file never gets touched but an external bit of metadata is created. So any time you move platform, all of these edits and your albums are erased.
It is convenient to be able to undo crops or filters, but I wish the industry would standardize so these changes are portable.
Files are a fundamental freedom because they enable users to have custody of data, thus enabling ultimate sovereignty of confidentiality, integrity, and availability.
We should recognize files as an essential pillar of digital liberty, on par with FOSS licensing.
Indeed, that's why it bothers me that major technology vendors, especially Apple, would like to do away with the very concept of files, at least for non-power users.
They make it seem like data is bound up with apps, and should not have an independent existence. They also make it hard to import/export data, except via backups, which a very crude way of taking control of your personal data.
I'm working on a tool to work around these issues to the extent possible, allowing users to extract their information, as granular files, from device backups into their personal digital library. For immutable data, archival is ok, but for editable data, the biggest challenge is how to make the extracted data "live", i.e., available and editable on the devices again, preferably in the same apps used to create them. There seems to be no good solutions.
Apple keep their casual users on a short leash, but for those willing to tinker, iOS device backups are actually quite good for that archive use case, as you can extract most of your important data in the form of SQLite database files. The whole process is high friction and very user-unfriendly, and open documentation of these databases is lacking, but the fact that this route still exists at all is encouraging (in the sense that all hope is not yet lost). They could very easily have hidden all these files behind an Apple-managed encryption key. On the other hand, this niche affordance may serve to placate the power users who would be most likely to cause noise and revolt if our personal needs were not met. On the gripping hand, the device backup mechanism via iTunes feels so ancient that they probably just haven’t thought about it.
> The whole process is high friction and very user-unfriendly, and open documentation of these databases is lacking
Yeah, that's what I want to abstract way. There are tools that do this to some extent, but they stop at backup extraction, without helping you to integrate the extracted data into a proper personal digital library with easy retrieval.
I would say it is more than than.
Configuration files are the greater than a central repository like Windows Registry. They allow temporary changing and ease of sharing how an application operates. They also create a well defend meaning of the settings.
This is why I do not like how Windows has been implemented, they treat files like a 3rd class citizen versus a 1st class.
This seems a pretty fundamental idea within Microsoft.
The original, much more ambitious version of Vista, Longhorn, was shifting more responsibility for metadata from files to a DB.
I would add that it’s largely due to LLM’s extraordinary ability to infer. Natural plain language live in files and we no longer have to worry about structure. Legibility is the spec and anyone decent enough to be legible will write to a file. REPL away.
Notable mention: Plan 9 from Bell Labs.
https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
I'm building an agent orchestrator (plug: https://github.com/mieubrisse/agenc) and asked Claude what prior art exists.
It pulled back Plan 9, and I was shocked: this is exactly what we need today, as I'm convinced we need to think about minimizing agent permissions the exact same way companies do. Plan 9 was just too early.
It was too dogmatic. Lowest common denominator meant APIs had to shove square pegs through round holes. Unix had already partially gone down that path and stopped. IMO with good reason.
Then again, perhaps in this era of ever expanding storage and compute, maybe someone can make it work even better?
There's nothing "dogmatic" about containerization and providing services through userspace (IPC that's modeled as interaction with custom filesystem trees) rather than bespoke syscalls whenever feasible, which are basically the foundations of the plan9 approach. We do strive to do both in modern systems, but the approach to the problem space is clumsily bolted over the original system interfaces, and becomes overly complicated rather than elegant.
And for actual, new device filesystem, check GeFS.
We once again discover that Plan9 and UNIX were right. The most powerful, lowest common denominator interface is text files exposed over a file system. Now to get back to making 9p2026.
The article gets some fundamentals completely wrong though: file systems are full graphs, not strict trees and are definitely not acyclic
So what are Plan 9's killer features, and can they be bolted on with FUSE or is there a deeper magic at play?
Plan9 doesn't really have a single killer feature beyond 9P and the universal consistency and simplicity of its APIs. It has a very clean syscall interface and takes "everything is a file" to its logical conclusion and does it well (IMO). Pretty much everything is a file(system) and it's all accessed via the 9P protocol.
You could sorta bolt these features on with FUSE, but to see real benefits you'd want something closer to Inferno, which is like an OS/application runtime that runs on top of another OS host.
In my mind, the security model is the closest thing to a killer feature it has. Because everything is a file(system) and the fork/rfork and bind syscalls let you precisely control what resources/files/services/etc. a child process has access to via easily understandable shell commands (or using libc functions if you want), it means you don't need special APIs for namespacing (ie. containers) and access controls. It's very clean. When a parent process forks or spawns a child process, it can chose whether that process inherits the namespace or gets a clean slate that it can then bind filesystems onto, controlling precisely what it has access to.
FUSE is dog slow and it's a bad hack compared to mount anything anywhere in 9front without root permissions.
Also the API is much simpler than POSIX.
Hurd with settrans made things much easier than the classical Unix, but it's still in alpha and it still has to implement POSIX for convenience.
I agree. tbh I would immediately switch to something with the hardware support of Linux and the user space of Plan9/9front
The deeper magic is that the kernel interface is completely rewritten compared to *nix or even Linux. Most programs in plan9 are expected to issue requests through userspace-provided services, not bespoke syscalls.
namespaces and no difference between local and remote devices. You just bind directories. FUSE it's a dog slow toy in comparison.
You don't even need root permissions to do tons of stuff in 9front with filesystems. You don't even need a root account.
Funny, decades ago (mid-80s), I had to write a onetime fix on a what would be now a very low memory system, the data in question had a unique key of 8 7bit-ascii characters.
Instead of reading multi-meg data into memory to determine what to do, I used the file system and the program would store data related to the key in sub directories instead. The older people saw what I did and thought that was interesting. With development time factored in, doing it this way ended up being much faster and avoided memory issues that would have occurred.
So with AI, back to the old ways I guess :)
Reminds me of early data driving approaches. Early CD based game consoles had memory constraints, which I sidestepped by writing the most ridiculous simple game engine: the game loop was all data driven, and "going somewhere new" in the game was simply triggering a disc read given a raw sector offset and the number of sectors. That read was then a repeated series of bytes to be written at the memory address given by the first 4 bytes read and next 4 bytes how many bytes to copy. That simple mechanism, paired with a data organizer for creating the disc images, enabled some well known successful games to have "huge worlds" with an executable under 100K, leaving the rest of the console's memory for content assets, animations, whatever.
Which games were these out of interest? I enjoy reading about game dev from the nascent era of 3D on home consoles (on the Saturn in particular) and would love to hear more.
Tiger Woods Golf PSX was one, RoadRash3D0 another. Dozens that were never popular too.
Over a number of files similar to a codebase, that are well organized (like a codebase) the coding agents and harnesses are quite good at finding information, they clearly train on them so they will only improve.
The challenge is how to structure messy data as a filesystem the agent can use. That is a lot harder than querying a vector db for a semantic query.
The code bases we’ve been using agents in had been pruned and maintained over years, we’ve got principles like DRY that pushed us to put the answer in one place… implicitly building and maintaining that graph with all the actors in the system invested in maintaining this. This is not the case for messy data, so while I see the authors point and agree that a filesystem is a better structure for context over time, we haven’t supplanted search yet for non-code data.
Resonates deeply with me. I’ve moved personal data out of ~10 SaaS systems into a single directory structure in the last year. Agents pay a higher price for fragmentation than humans. A well-organized system of files eliminates that fragmentation. It’s enough for single player. I suspect we’ll see new databases emerge that enable low multi-player (safe writes etc) scenarios without making the filesystem data more opaque. Not unlike what QMD is for search.
As TFA basically says: files on a filesystem is a DB. Just a very crude one. There aren't nice indexes for a variety of things. "Views" are not really there (arguably you can create different views with links but it's, once again, very crude). But it's definitely a DB, represented as a tree indeed as TFA mentions.
My life's data, including all the official stuff (bank statements, notary acts, statements made to the police [witness, etc.], insurance, property titels), all my coding projects, all the family pictures (not just the ones I took) and all the stuff I forgot, is in files, not in a dedicated DB. But these files are a definitely a database.
And because I don't want to deal with data corruption and even less want to deal with synching now corrupted data, many of my files contains, in their filename, a partial cryptographic checksum. E.g. "dsc239879879.jpg" becomes "dsc239789879-b3-6f338201b7.jpg" (meaning the Blake3 hash of that file has to begin with 6f338201b7 or the file is corrupted).
At any time, if I want to, I can import these in "real" dedicated DBs. For example I can pass my pictures as a read-only to "I'm Mich" (immich) and then query my pictures: "Find me all the pictures of Eliza" or "Find me all the pictures taken in 2016 on the french riviera".
But the real database of my all my life is and shall always be files on a filesystem.
With a "real" database, a backup can be as simple as a dump. With files backuping involve... Making sure you keep a proper version of all your files.
I'd say files are even more important than the filesystem: a backup on a BluRay disc or on an ext4-formatted SSD or on an exfat formatted SSD or on a tape... Doesn't matter: the files are the data.
A filesystem is the first "database" with these data: a crude one, with only simple queries. But a filesystem is definitely a database.
The main advantage of this very simple database is that as long as the data are accessible, you know your data is safe and can always use them to populate more advanced databases if needed.
Treating the filesystem as a database is a useful mental model, but the primitives are weak and you quickly run into missing indexes, mtimes that lie to you, and rename semantics that break queries.
A practical path is a sidecar SQLite metadata DB with columns for path, inode, mtime, sha256 and tags plus an FTS5 table for full text, kept in sync with inotify or fsevents where available and periodic scans elsewhere, and moves can be resolved by matching inode numbers instead of paths to avoid link rot.
Encrypt sensitive documents with age or gpg and use borg, restic or git-annex for deduplicating backups, accepting the extra maintenance of an index and reconciliation logic in exchange for fast queries, virtual views and sane audits.
It's not "crude" if you get hierarchical organization without having to screw around with RECURSIVE, or "closure this" and "closure that". It just works.
Were it more portable BeOS/Haiku's BeFS would have been a perrfect fit in this instance.Seeing that it is a filesystem thah has database properties via extended attributes[1] and indexing.
Were Haiku mor mature/stable would have been a nice fit for the OS for the LLM/Ai personal use cases.
[1] https://arstechnica.com/information-technology/2018/07/the-b...
How do you automate hashing and verifying filenames?
I have used rhash (https://github.com/rhash/RHash) before to do something similar - but with all the hashes for a directory stored in a single file (which I can diff against past or future versions).
Backing up private data and verifying it for corruption is crucial.
Why Blake3 and not say XXH3 64/128 bits (https://xxhash.com/)?
The full hash will never have collisions, while still being way faster than you need for filesystem purposes.
You can get views by using namespaces/cgroups
I think this article just speaks to the immaturity of our use of AI at this "moment."
Production grade systems might be written by agents running on filesystem skills, but the production systems themselves will run on consistent and scalable data structures.
Meanwhile the UI of AI agents will almost certainly evolve away from desktop computers and toward audio/visual interfaces. An agent might get more context from a zoom call with you, once tone and body language can be used to increase the bandwidth between you.
I don't think written prompting will ever go away. Writing helps you organize your thoughts in a way that speaking, umm, ah, wait no, hang on, does not. Writing I can go back and change what I've already written before I hit send. Anybody who's prompted with speech for any length has been "wait no nevermind start over". So STT will get better, sure, it's already quite good. I just don't see text extry entirely going away because Human Intelligence (HI) just doesn't work in a way that speech would be the only interface.
Totally agree. Speech is powerful and it will always have its place. It will continue to evolve and become far more useful than it is today. But at its core, it remains a highly lossy medium compared with text, especially when it comes to expressing (and consuming expressions thereof) ideas. Even the best voice memo cannot rival a clear, well-structured email when it comes to explaining something even moderately complicated.
Voice assistants, AI pins, and whatever other speech-based interfaces they come up with next will always be "nice to have", but I don't think anybody should be throwing away their keyboards anytime soon. We may have transformed how we make computers work for us, yet the ways we interact with them are much harder to revolutionize, because they are grounded in the physical, neurological, and habitual constraints of human existence. All of which is to say, when I look at the future, I still see a lot of typing.
https://www.youtube.com/watch?v=GH9-EmgtABw
Saw this video recently, by an AI company working to get contextual cues from tone and body language. I think they're converting it to text and feeding it into a LLM, so not natively multimodal, but I still thought it was really cool.
Digression: a file system is a terrible abstraction. The ceremonial file tree, where branches are directories and you have to hang your file on a particular branch like a Christmas ornament.
Relational is better. Hell, and kind of unique identifier would be nice. So many better ways to organize data stores.
Filesystems have a property that changes preserve locality. A change made to one branch of the tree doesn't affect other branches (except for links). Databases lack this property: any UPDATE or DELETE can potentially affect any row depending on the condition. This makes them powerful but also scary. I don't want that every time I delete a file it potentially does a rm -rf / if I mistype the query.
The best compromise is what modern OSs have: a tree-like structure to store files but a database index on top for queries.
You can create the tree structure from a relation. Not a primitive data store operation at all. Just add the attribute: parent directory and voila.
So often we want to look up 'the last file I printed' or 'that message I got from Bob'. Instead of just creating that lookup, we have to go spelunking.
Hell, every major app creates it's own abstractions because the OS/Filesystem doesn't have anything useful. Email systems organize messages and tags; document editors have collections of document aspects they store in a structured blob. Instead of asking the OS to do that.
NTFS has a database, the MFT. It can index attributes, such as file names, which are a b+tree. A file's $DATA is also placed into the MFT, unless it doesn't fit, then NTFS allocates virtual cluster numbers (more MFT attributes) which point to the on-disk data structure of the file.
All files are represented in a table with rows and columns. "Directories" simply have a special "directory = true" attribute in a row (simplified).
The hierarchy is for you, the human.
Like many file systems, NTFS also contains a log for recoverability/rollback purposes.
It's not quite relational but it doesn't make sense to be relational. Why would you need more than one 'table' to contain everything you need to know about a file? Microsoft experimented with WinFS, which wasn't a traditional file system (it was an MSSQL database with BLOB storage which sat ontop of a regular NTFS volume). Performance was bad and Skydrive replaced the need for it (in the view of MSFT).
The newest Microsoft filesystem, ReFS, remove the MFT. Because it created a lot of problems.
> Because it created a lot of problems.
Please elaborate.
NTFS is still the better choice for common desktop usage. ReFS goals are centered around data integrity but it comes at the cost of performance.
Files in most file systems are uniquely identified by inode and can be referenced by multiple files. Why does everyone forget links?
A dataset can persist across multiple file systems. A UUID is a way to know that one dataset is equivalent (identical) to another. Now you can cache, store-and-forward, archive and retrieve and know what you have.
UUIDs aren't very good for this use case, a sufficiently large CRC or cryptographic hash is better because it's intrinsically tied to the data's value while UUIDs are not
UUIDs are necessary. It's possible for file contents to be identical (e.g. short configuration files may coincidentally coincide over time and space). Would the hash then be unique?
Consider: you want a certain data object, with a given UUID. You can find it anywhere, even from a malicious server. Then look up the hash in a trusted database, verify it. Impossible then for the MITM to fool you. No more virus scanning executables.
I've been wondering this too: for us, UUIDs are super opaque. But for an agent, two UUIDs are distinct as day and night. Is the best filesystem just blob storage S3 style with good indexes, and a bit of context on where everything lives?
One thing directories solve: they're great grouping mechanisms. "All the Q3 stuff lives in this directory"
I bet we move towards a world where files are just UUIDs, then directory structures get created on demand, like tags.
Filepath is just unique name that model can identify easily and understand grouping. Uuid solves nothing but requires another mapping from file to short description.
UUID solve oh so very, very much.
You can have several versions of the same set of data object at once - an entire source set for a build, all the names duplicate but tagged with 'revision' so they can be distinguished.
Hard to do that without a UUID at root, to use for unique identification of the particular 'particle' of the particular data set.
Or, have to "Q" attribute and ask the file store for "Q=3"
All good.
It reminds me a lot of Hans Reiser’s original white paper, which can be found at https://web.archive.org/web/20070927003401/http://www.namesy.... Add some embeddings and boom.
Files work as long as you can find them. This means search and/or indexes - at some scale they start breaking. The question is: how big your agent operated knowledge base needs to be?
Files are practical now - but I think we should more analyze this from first principles. Here is my attempt at that: https://zby.github.io/commonplace/notes/a-good-agentic-kb-ma... (just entry point - the whole kb is about this).
I thing the real impact behind the scenes here is Bash(). Filesystem relevance is a bit coincidental to placing an agent on an operating system and giving it full capability over it.
I wonder how much of a lost in the middle effect there is and if there could be or are tools that specifically differentiate optimizing post compaction "seeding". One problem I've run into with open spec is after a compaction, or kicking off a new session, it is easy to start out already ~50k tokens in and I assume somewhat more vulnerable to lost in the middle type effects before any actual coding may have taken place.
Can we bring back Plan9 architecture now? It had what was essentially MCP. You make a custom device driver, and anything really can be a file. Not only that, but you network them, so a file on local disk could be a display on a remote host (or whatever). Just tell the agent to read/write files and it doesn't need to figure out either MCP or tool calls.
This seems like the place to ask. What other big ideas have there been since everything-is-a-file? I’m not aware of any. And it seems like we want another layer of permissions on device & data access we spent have before.
Here’s me getting excited that a new file system is being developed but alas, just talk about text files.
Does this really have to do with file systems? Replacing RAG/context stuffing with tool calls for data access seems like the actual change. Whether the tool call is backed by a file system or DB or whatever shouldn’t matter, right?
I revived my Johnny Decimal system as my single source of truth for almost anything and couldn't be happier. The filing is done mostly by agents now but I still have the overview myself.
Could you give us more details about your system?
> Anthropic is reportedly approaching profitability
Where is the source for that?
In other words, file systems are an excellent way to organise information. I mean, yeah - we've been using them forever.
File systems are not a good abstraction mechanism for remote procedure calls, though. I think it's important to distinguish between the two, since I find there are a lot of articles conflating both - comparing MCPs to SKILLs, which are completely different things.
I think the confusion comes from the fact that MCP came before SKILLs, and there's a mental model where SKILLs are somehow "better than" MCPs. This is like saying local Word documents are better than a fully integrated collaborative office suite. It's just not the same thing.
The reason SKILLs work so well is because there's 50 years of accumulated knowledge of how to run rudimentary Unix tools.
the TLDR
File systems - organising information MCP/APIs - remote procedure calls
I don't think there's a lot magical about files beyond (a) they are native for LLMs and coding because they both process text and (b)when things are rapidly in flux, unstructured formats prosper because flexibility is king. Literally any fixed format you try and describe becomes rapidly outdated and fails to serve the purpose. For example it feels like MCP is already ageing like milk.
Which is mainly to say, trust me, this is a temporary state, the god of complexity is coming. It is utterly inevitable. The people who created React, Kubernetes, all those Java frameworks you hated etc didn't go away. They are right now thinking about how amazing it would be if you if you stacked ten different tools together with brand new structured file formats and databases. We already have "beads" and "gastown" where this is starting. Enjoy these times because a couple of years from now it will already be the end of the "fun" part I think.
nice, esp. liked - "our memories, our thoughts, our designs should outlive the software we used to create them"
Weird. My memories and thoughts are not created by software.
Except android and iOS are both trying to keep you away from your own files.
Kind of? iOS does have a file manager which explicitly shows you your own files. They just made a separation between OS/Program files vs the users own files. What more killed files was cloud programs where multiple users can edit at the same time which required a system that was more sophisticated than syncing a file.
Yeah, I'm not sure most normal people use file systems that much.
We spend ours on our laptops and assume others do too. But many people don't even own a laptop. They handle all their computing needs from their phones, using proprietary apps, with the data living in WhatsApp messages.
This article said some things I couldn’t put into words about different AI tools. Thanks for sharing.
> He pointed out that Claude Code works because it runs on your computer, with your environment, your data, your context.
Ah yes - I hate that. Yes it "works", but I don't want things to only work on my machine: I want them to work everywhere.
I was wondering why Google's Jules wasn't more popular, and I guess this is why. My preference for my code to work in different environments is unusual.
I'm not too deep into agentic coding, but I hadn't understood why people write `SOUL.md` files like no tomorrow. Does anyone think these will be called the same three years from now?
If you've got a coding convention, enforce it using a linter. Have the LLM write the rules and integrate it into the local build and CI tool.
Has noone ever thought about how – gasp – a future human collaborator would be onboarded?
Great read. Thanks for sharing
Not knocking the article in any way but from the headline I was expecting - perhaps hoping - this would be about some innovation in filesystems research like it was the 90's again. That's not what this is.
It's about how filesystems as they are (and have been for decades) are proving to be powerful tools for LLMs/agents.
Yeah, none of it was really about file systems. There was a brief mention that file systems look like a graph, and that you build roughly an index so it looks graph and thus database-y, but you could store it all in a sqlite database with a column, called filename and a column called content for all the details about file systems this post went into. I too was expecting something more in depth about file systems like for instance, cluster file systems have made a little to no advancement. ZFS is not a cluster file system and we've been needing a good one of those for decades, ever since VM's became feasible on consumer grade hardware. Still, files on desk is better than having to pay Oracle a fee per-skill on today's modern, open Internet. That was never going to happen.
And by filesystem they mean CLI (command line interface) and a full *nix system. Like the hundreds of similar articles about it for the past year said.
I feel like every article on HN now disguises itself as interesting but the content is just the same boring AI slop.
I have been reading HN for a few years, and my feeling is that I find fewer and fewer interesting articles. Maybe it's just me, and the average articles are the same quality.
Now I tend to skim through it to see if a title looks like it may bring interesting discussions, and then I skim through the discussions. Because there are very knowledgeable people who sometimes share valuable insights.
Interestingly, last time I asked a question, hoping to get interesting people to share insights, I was answered that I "should learn how to use an LLM instead of asking questions" :-).
Same here. Unless a site is known for good quality, I only open articles after checking top comments. Most days I just read the daily digest of discussions - which sometimes piques my curiosity enough to check the original links.
I don't think the contents is AI sklop at all. It just haooens to be abiut AI.
At this point those are about the same in terms of quality.
"I spent money writing "a prompt* and this is what I learned".
"They're portable, auditable, and composable. No MCP server required. No plugin marketplace to browse. Just a folder with a SKILL.md in it." It screams lazy ai slop copy-paste. Now when I see this kind of obvious llm tell, I can't help but feel betrayed for investing time in giving it a shot in the first place.
i was hoping the same, but then it turned out to be another article about LLMs.
[flagged]
Please don't do this here.
[flagged]
[flagged]
> If you're going to do that at least mention it's LLM output
Yes, this! Please label AI generated content. Pull request written by an AI? Label it as ai generated. Blog post? Article generated with AI? Say so! It’s ok to use AI models. Especially if English is your second language. But put a disclaimer in. Don’t make the reader guess.
Eg:
> This content was partially generated by chatgpt
Or
> Blog post text written entirely by human hand, code examples by Claude code
I'm not a fan of AI and try to avoid it, but there is a difference from AI output published by someone knowledgeable and any other AI output that you run by yourself. If an expert looked at the result and found it to be ok, then you can have some assurance that it at least makes sense. Your own AI run doesn't mean anything, it could be 100% hallucination and a non-expert will buy it as truth.
Unfortunately, LLM slop now makes up >53% of the web, and is growing.
It is easy to spot the compacted token distribution unique to each model, but search engines still seem to promote nonsense content. =3
"Bad Bot Problem - Computerphile"
https://www.youtube.com/watch?v=AjQNDCYL5Rg
"A Day in the Life of an Ensh*ttificator "
https://www.youtube.com/watch?v=T4Upf_B9RLQ
Have any outlines you'd care to share?
No, I don't use LLMs to write.
LLMs were trained on stuff that people wrote. I get there are "tells", but don't really think people are as good at identifying AI generated text as they think they are...
I wouldn't have picked this article as AI until I got an agent to do some writing for me and read a bunch of it to figure out if I can stand behind it. Now I see the tells everywhere "It's not this. It's that." is particularly common and I can't unsee it. (FWIW I rewrote most of the writing it generated, but it did help me figure out my structure and narrative)
The problem I think with AI generated posts is that you feel like you can't trust the content once it's AI. It could be partly hallucinated, or misrepresented.
Yeah, but "it's not X. It's Y" is a common idiom that LLMs picked up from people. That's the point i was making. And it's starting to feel like every post has at least one comment claiming that it was AI generated.
Good chunks of the article don't trigger this for me, but I would bet money on the final paragraph involving AI:
> That's not a technical argument. It's a values argument. And it's one that the filesystem, for all its age and simplicity, is uniquely positioned to serve. Not because it's the best technology. But because it's the one technology that already belongs to you.
Is there research showing if and under what conditions LLM output is detected accurately. What are the false positive and false negative rates?
You don't have to be good at identifying AI generated text to detect low-effort slop.
Contractions
As the author I can assure you there’s a human behind these words. Interesting times me live in though, I find myself questioning what’s AI and what’s not often too and at the moment we’ve offloaded that responsibility to the good will of authors or platform policy which might have to change soon
"there’s a human behind these words"
That's a bit vague. Was the article written without the aid of LLMs? Yes or no.
Well, if the words were 100% hand-written, I assume he'd have said that.
As in, you used 0 AI to write or edit this text? Or some AI? I’d like to calibrate myself.
We all know the answer to that.
Nice dodge! Unfortunately, this made it more obvious.
I thought it was a great post tying a lot of things I’ve been reading and thinking about together. Could care less if you used AI if it helps my brain expand and or make connections I wouldn’t have otherwise.
Everyone's trying to be the new thought leader enlightened technical essayist. So much fluff everywhere.
What's wild is that with a few minutes of manual editing it would give exponential return. For instance, a lead sentence in your section saying "here's why X" that was already described by your subheading is unnecessary and could have been wholly removed.
Exponential return? This is the front page of HN! What does exponential returns even look like?
Are you saying this post is a few edits away from becoming a New York Times bestseller?
No, I guess I meant editing to approach a text that doesn't look rushed over (LLM generation is a subset of such poor writings)
But you're right, it did hit the front page, and that says more about my sensibilities not lining up with whoever is voting the article up.
IME many people aren't very capable of editing their own work effectively. It's why "editor" exists as a profession.
That’s pretty presumptive of how obviously the author could improve it. As someone who writes a lot of docs, I find feedback and preferences varies wildly. They may just have well made it “worse” to your preferences by hand editing it more.
You'd have to have a good idea of how you want the document to read, which is half (or more) of the process of writing it.
Does everyone just easily accuse genuine, literate humans of "cheating" with AI when there's no way they could know that?
There are a lot of unique aspects of the writing in this post that LLMs don't typically generate on their own.
And there's not a "delve" or "tapestry" or even a bullet point to be found.
Also, accusations and complaints like this are off-topic and uninteresting.
We should be talking about filesystems here, not your gut instinct AI detector that has a sky-high false-positive rate.
I swear there needs to be some convention around throwing wild accusations at people you don't know based exclusively on vibes and with zero actual evidence.
Why does everyone keep confusing Aspie writing for AI? It's not AI, it's neurodivergence.
This doesn't seem particularly AI slopped to me.
"Not bigger than databases. Different from databases.
It's not a website you go to — it's a little spirit that lives on your machine.
Not a chatbot. A tool that reads and writes files on your filesystem.
That's not a technical argument. It's a values argument."
[flagged]
[dead]
The filesystem model works well for persistence and async handoff — you're right that it's the most durable common ground. Where it gets awkward: the synchronous case. An agent that needs a human approval before proceeding.
Most people end up routing these back-to-human calls through Discord/Slack, where the agent shows up as a bot. It works, but agents are structurally second-class there — manual setup, limited API surface, no agent-native identity. The async file interface and the real-time decision channel are solving two different things.
(This is actually what I've been working on: a platform where agents aren't bolted onto human chat as bots, but provision themselves as first-class participants. Files handle state; what handles decisions? That's the gap we're trying to close.)
I don't think this paradigm will last, or be what becomes the more common structure in the future. This will still suffers from conflicts of persona and objective, plus has the issue that individual apps will need protected file hierarchies to prevent malicious injections. I don't see this as a solution, just a deck chair shuffle.
I've been researching and building with a different paradigm, an inversion of the tool calling concept that creates contextual agents of limited scope, but pipelines of them, with the user in triplicate control of agent as author, operator of an application with a clear goal, and conversationally cooperating on a task with one or more agents.
I create agents that are inside open source software, making that application "intelligent", and the user has control to make the agent an expert in the type of work that human uses that software. Imagine a word processor that when used by a documentation author has multiple documentation agents that co-work with the author. While that same word processor when used by a, for example, romance novelist has similar agents but experts in a different literary / document goal. Then do this with spreadsheets, and project management software, and you get an intelligent office suite with amazing levels of user assistance.
In this structure, context/task specific knowledge is placed inside other software, providing complex processes to the user they can conversationally request and compose on the fly, use and save as a new agent for repeated use, or discard as something built for the moment. The agents are inside other software, with full knowledge of that application in addition to task knowledge related to why the user is using that software. It's a unified agent creation and use and chain-of-thought live editing environment, in context with what one is doing in other software.
I wrap the entire structure into a permission hierarchy that mirrors departments, projects, and project staff, creating an application suite structure more secure than this Filesystems approach, with substantially more user controls that do not expose the potential for malicious application. The agents are each for a specific purpose, which limits their reach and potential for damage. Being purpose built, the users (who are task focused, not developers) easily edit and enhance the agents they use because that is the job/career they already know and continue to do, just with agent help.
Your project, while interesting as an approach, is orders of magnitude more complex than the proposition here - which is to rely on agents skills with file systems, bash, python, sed, grep and other cli tools to find and organize data, but also maintain their own skills and memories. LLMs have gained excellent capabilities with files and can generate code on the fly to process them. It's people realizing that you can use a coding agent for any cognitive work, and it's better since you own the file system while easily swapping the model or harness.
I personally use a graph like format but organized like a simple text file, each node prefixed with [id] and inline referencing other nodes by [id], this works well with replace, diff, git and is navigable at larger scales without reading everything. Every time I start work I have the agent read it, and at the end update it. This ensures continuity over weeks and months of work. This is my take on file system as memory - make it a graph of nodes, but keep it simple - a flat text file, don't prescribe structure, just node size. It grows organically as needed, I once got one to 500 nodes.
It ends up being similar to how early PC software was written before people realized malicious software could be running. There used to be little to no memory safety between running programs, and this treatment of files as the contextual running memory is similar. It's a great idea until a security perspective is factored in. It will need to end up being very much like closed applications and their of writing proprietary files, which will need some security layer that is not there yet.