A couple of weeks ago I had a post over on LinkedIn about using FUSE to isolate my Pecan VMs such that they didn’t even need to have external read-write mounts to the filesystem. Everything could be done through an overlayfs-style implementation that allowed the Pecan Server to pull changes back into the host filesystem. The original implementation had tried to do this host-side by implementing a virtual filesystem using FUSE and then mounting that in the Pecan container. Unfortunately on macOS at least this didn’t do what I wanted since I had used FUSE-T to avoid MacFUSE’s increasingly annoying kernel extension dance. It turns out you can’t mount an NFS filesystem in Apple’s Containerization framework.
Having found a clean implementation I set FUSE-T aside and moved on to other things, but I always had it in the back of my head that there was probably something interesting I could do FUSE and the macOS FUSE-T implementation. Fast forward a bit and I’m reading about Garry Tan telling people to wrap their MCP implementations in CLIs because it works better and I think to myself that hey if you’ve got a CLI that’s not working maybe you should convert that to a file-based solution instead since if there’s one thing agents like more than CLIs its files.
So I started on using FUSE to expose Ragtime’s RAG system as a virtualize filesystem that agents could then explore with simple commands instead of having to teach them about the Ragtime CLI. Should be better right? Not sure, because while I did that I had an even better idea along the way…
An Agent Operating System#
See, about halfway through implementing that idea I had another thought: I’ve got these Starlark rules in Ragtime which aren’t really part of the RAG system. They’re mostly there to drive things like the approval automation and I just happened to use them to implement the RAG system because it felt like that would be more flexible for users down the line who wanted to customize things. But.. what if I did everything that way?
Enter the “Agent Operating System” or “The Most Unhinged FUSE Filesystem Ever.”
The way it works is that Ragtime’s Starlark rules can now be run in response to events coming from the FUSE filesystem. So, for example, you can write a Starlark rule that responds to file and directory operations happening in, say, /tasks that implements a task tracker similar to what Beads was when it first came out. Especially if you give the Starlark system access to the SQLite backing store you’re already using you can now implement a Kanban style system that works entirely via file manipulation but stores everything in a database like a grown-up. Hell, it could be driving something like Github Issues or JIRA for all the agent cares… All it does is read and write files or moves them around.
For example this basic rule updates the task state depending on where it is moved in the filesystem. Pretty simple right? And the agent is none the wiser.
Goodbye CLIs and Hello Files.
Adding a Muxer#
The other thing I wanted to add to Ragtime was a muxer to make it sort of the most minimalist orchestration harness I could. Also I’m just tired of dealing with tmux when all I really want is to be able to spin up agents and send them commands from time to time. I don’t need all the fancy pane layout stuff or multiple sessions or windows or whatever. I just need Claudes and Gemini’s in the background. So now I can do that but I can also do it all through Starlark rules and the FUSE filesystem if I want. Sure I can use the CLI to send strings just like tmux but I also have a Starlark rule that knows how to call than command when you echo to a file in the filesystem.
We implemented a little queuing system so that typing won’t get sent if the agent is working (not strictly necessary since they mostly queue on their own… but avoids issues around things like permissions calls hopefully) and now we’ve got ourselves the beginnings of a full Gas Town-style orchestration system for the agents to use. I suppose next mkdir /agent/foo should let an agent launch another agent… but for the moment agents that you launch now have an easy file-based way of talking to each other.
So what’s next?#
Well, I made a website for it so that’s something and this feels like just the beginning of what we could do here. I’m calling it an orchestration operating system because files and hooks are the system calls of the agent world and this gives you a kernel for implementing them.
I’m already thinking about using the same overlayfs-style approach I used in Pecan here where an agent could be launched inside of the virtual filesystem entirely and then the project files could be mounted as the lower layer in an overlayfs with changeset and merge functionality. The reason I think that might be interesting is that it would also mean I could make the <project>/.claude directory fully dynamic and automatically generate not just the hook settings for Claudes running in the shell, saving the user the trouble, but also even dynamically generate skill files and maybe more importantly gather telemetry on their usage and how well they’re performing. Then other agents could try to optimize those skills based on the telemetry for superreasearch-style loops in an entirely self-contained agent ecosystem.
There’s also a bunch I should do with the PWA and TUI as well. Adding the muxer and xterm.js interfaces into the PWA is an obvious no-brainer and so is a dashboard for tracking how your agents are doing, context usage, cost that sort of thing when available. That’s all good stuff that you need for monitoring your OS and seeing how they’re doing. Also building Starlark interactions into the PWA also means people can start implementing their own custom agent IDEs that can take advantage of this platform in easy ways. I’m sure I’ll come up with more ideas now that I’ve got the platform.
The sky’s the limit here…