No Server. No MCP. Just Files in a Folder.

I can tell you the entire architecture in one breath.

The AI agent writes a small JSON file into a folder called inbox. A script running inside REAPER notices the file, runs the command, and writes the result into a folder called outbox. The file moves on to an archive. That is the whole thing.

No server. No socket. No network call. No MCP. No extension to sideload. A folder, some files, and a script that reads them one at a time.

Right now everybody building tools for AI agents is racing to ship an MCP server. It is the fashionable answer, and for a lot of problems it is the right one. Reaper Daemon is almost rude about how little it needs in comparison. And I want to walk through why, because the reasoning is more useful than the tool.

I Did Not Start Here

I did not sit down wanting the simplest possible thing. I wanted the thing that worked and kept working after I stopped paying attention to it. Those turned out to be the same thing, but I had to eliminate the alternatives first.

The Python library everyone points you at for scripting REAPER from the outside is effectively dead. No installable release, a version number that may as well read abandoned. Building anything load-bearing on top of it would have been building on sand.

REAPER speaks OSC out of the box, which sounds promising until you need it to tell you what is actually in the session. OSC can push a fader and trigger an action. It cannot answer “what tracks exist, what plugins are on them, how are they routed.” An agent that cannot read the room is not an assistant. It is a person flipping switches in the dark.

A real local server was the obvious next idea. Stand up a process on a port, have the agent talk to it. And now I own a daemon that has to be running, has to not crash, has to not collide with something else on that port, has to be restarted when it dies, and has to be explained to every single person who installs it. I would be trading a music problem for a sysadmin problem, forever.

So I kept deleting things. The port. The server. The protocol. What is the least that could possibly work.

The least that could possibly work is a folder.

Why Files Win

Files are boring, and boring is the highest compliment I give a piece of infrastructure.

You can read the whole system with your eyes. When something goes wrong, you open the inbox and look. There is the command the agent sent, sitting right there in plain JSON. There is the reply in the outbox. There is the archive of everything that already ran. No packet capture, no attaching a debugger to a live process, no guessing what got swallowed on the wire. The state of the system is just files on a disk, and you already know how to look at files on a disk.

Files do not crash. There is no daemon holding a connection open, no process to babysit. REAPER is already running, because you are already using it. The script lives inside REAPER and wakes up on a timer. If your machine reboots, the folder is still there, the unprocessed commands are still there, and the thing picks right back up.

Files do not care what language the agent is written in. The agent’s whole job is to write a small text file into a directory. Claude can do that. Codex can do that. A bash script you wrote at midnight can do that. There is no SDK to import and no client library to keep in sync with a server you also have to keep in sync.

And files are safe in the one way that matters most when you are letting a machine touch your unsaved work.

Every Move Is One Undo

This is the part I care about more than the architecture.

Every command the agent runs inside REAPER is wrapped as a single undo block. The agent loads a compressor, you do not like it, you press the same Cmd+Z you have pressed ten thousand times, and it is gone. One move, one undo. It cannot quietly do six things and leave you unable to find your way back.

The commands also run one at a time, in order, instead of a swarm of calls racing each other to mutate your session. A folder read top to bottom is naturally a queue. The simple design did not just avoid a server. It gave me a safety model for free, because a line of files waiting their turn is a much easier thing to reason about than a pile of concurrent requests hitting a live process.

That is the trade I keep finding under the surface of these decisions. The fashionable thing buys you power you do not need yet and a failure surface you absolutely do not want. The boring thing solves the actual problem and leaves almost nothing to go wrong.

Simple Is Not the Same as Finished

I want to be honest about what simple does and does not buy you, because the opposite is exactly the kind of overclaim that makes me close a tab.

Simple does not mean magic. The agent still does dumb things sometimes. It will confidently set a parameter you did not want, which is precisely why the undo block matters and why a human still drives. Simple does not mean done, either. A folder of files is easy to reason about and that is exactly what makes the remaining sharp edges easy to find and file down, which is an ongoing job, in the open, on a public repo, where you can watch it happen.

What simple does buy you is this. You can understand the entire thing in an afternoon. You can install it with one line and read every line you installed. When it breaks, it breaks somewhere you can see. And you can hand it to your coding agent and have it explain the whole system back to you, because there is no hidden machinery, just files moving from one folder to the next.

Everyone is going to keep shipping servers, and some of them should. But the next time you reach for the heavy thing on instinct, it is worth asking what the least is that could possibly work. Sometimes the answer is a protocol and a process and a port.

Sometimes it is a folder.

Reaper Daemon is free and open source. There is a page for it here, and the code is on GitHub if you want to read every boring, legible line of it.