Filesystems as Personal Memory
Here's my actual take on all of this, the thing I think people are dancing around but not saying directly.
Filesystems can redefine what personal computing means in the age of AI.
Not in the "everything runs locally" sense (but maybe?). In the sense that your data, your context, your preferences, your skills, your memory — lives in a format you own, that any agent can read, that isn't locked inside a specific application.
I like this vision of the future — personal data in whatever form is easiest or convenient, stored as the person chooses, arbitrary computation enabled by the natural language interface of LLMs. As I read this superb summary of the current state of coding agents intersecting with the filesystem, I had a couple thoughts.
Knowledge Bases, Skills, and the Git Repository
Plenty of folks have written [1] [2] about the limits of tools given to coding agents. Every new tool floods the agent context with a bunch of instructions on how to use it; the domain-specific language of tool calls decreases "intelligence" and requires model providers to spend reinforcement learning effort on accurately structuring output, and the more tools given to the agent, the more likely it is to ignore them (see for instance the experiments and anecdotes about CLAUDE.md size and context rot).
I've been spending a bunch of time working on Knowledge Bases (bs) recently, a tool for working with notes and issues similar to Beads (Steve Yegge's issue tracker CLI). A chunk of that time has been spent creating, refining, and maintaining the command-line help text and examples so that agents can learn everything bs does via --help. Per the article, I am now considering just how much of what bs does could be done with carefully structured example files. You could put task content in markdown files with a yaml frontmatter that contains the title, status, and relations, naming the file with a short identifier. Git would still handle versioning and merging parallel streams of task creation. This scheme would require no context spent on teaching the bs CLI (domain-specific language) — reading a single file would likely be the only thing needed to effectively work the system.
This train of thought leads me towards using repository-scoped Skills for guiding agents in executing project tasks. As I write this, it sounds trivial, and maybe it is, but I guess I hadn't really considered project tasks like logging designs/tasks/bugs, guidance of coding principles, code review, and many others as candidates for repository-scoped Skills, instead thinking about them as extended man pages for tooling (compilers, etc) the project needs. I need to think about this more — Skills as project process using git-tracked files as memory or artifacts feels compelling to me right now.
Coding Agent Limitations
Perhaps we are prematurely optimizing. There's an assumption underlying parts of the article like this one:
Something similar is happening with AI agents. The bottleneck isn't model capability or compute. It's context. Models are smart enough. They're just forgetful. And filesystems, for all their simplicity, are an incredibly effective way to manage persistent context at the exact point where the agent runs — on the developer's machine, in their environment, with their data already there.
Effective increases to LLM context size, or even better, effective maintenance on LLM "attention" such that tools and guidance are persistently "kept in mind" even at large context sizes, would shift this calculus. We would be able to dump the compiler's help text, the bs help text, and any other MCP definitions that want to come along for the ride into the context and trust that they wouldn't be ignored and wouldn't hinder working memory. Time will tell, though this doesn't feel likely to me, everything I've read and observed points at these issues being fundamental to how LLMs function. For now, I'll probably lean into Skills for my next automatic software engineering experiment.