The oldest thing on the screen
I have been using computers long enough to have watched several interface fashions arrive with great confidence and leave quietly. Skeuomorphic buttons that looked like leather. Flat design that looked like nothing. The ribbon, the hamburger menu, the sidebar that collapses into a smaller sidebar. Each one was going to change how we work.
Meanwhile the folder sat there. Same yellow-ish rectangle, same idea: a place with things in it. I do not think anyone has ever been asked to attend a training session on how to open one.
I used to put that down to habit. Then I ran a business that depended on forty different tools, and noticed that the only thing every one of them could still hand me at the end was a file.
The simplest contract we ever agreed on
A file has a name, it has bytes, and it lives somewhere you can find it. That is nearly the whole agreement. Any program that can read bytes can open it, and any program can write one without asking the others for permission.
Think about what that contract leaves out. There is no account to create, no schema to learn, no version of the interface that stops working after an update. A spreadsheet someone saved decades ago still opens. A text file from before most of my colleagues were born still opens. I cannot say that about a single one of the dashboards I have paid for.
There is a kind of humility in it. A file does not know what it is for. It does not insist on being part of your workflow. You can put a contract in one, or a recipe, or a log, and nothing complains. Every tool built on top of that has to guess what you will do with it. The file never guessed, which is why it has so rarely been wrong.
Software has made many agreements with itself since, and most of them have been renegotiated within a few years. The file has barely moved. That is not because nobody tried to replace it. It is because every replacement ended up needing a way to export, and the export was a file.
A Tuesday, as an example
Here is a working day I think many small teams would recognise. At nine, somebody opens plan.md to see what the week is meant to be. It is a Markdown file, about two screens long, with a heading per project and a line under each saying who has it.
At ten, a teammate drops a customer call summary into a notes folder, because that is where call summaries go. At eleven, someone asks an agent to read the last three of them and say whether the same complaint keeps coming up. It reads the files, finds it does, and quotes the sentences. At two, a decision gets made in a meeting, and one person adds four lines to decisions.md with the reasoning, because otherwise it will be relitigated in a month.
None of this involved a product tour. Nobody asked which tab the decisions live in. The structure was a few folder names and a habit, and the habit was cheap to keep because the folder was already there.
Later that afternoon a new hire asked where the pricing reasoning lived. Nobody pasted a link. Someone said it was in decisions.md and the new hire found it in the time it takes to type the name. A year from now, a different person, or a different agent, will do exactly the same thing, and will not need to be told the file exists, because it is where files go.
Agents speak it already
The coding agents we use every day were trained on a very large amount of people doing the same few things: reading a file, searching for a pattern, changing a few lines, writing it back. Claude Code, Codex, Cursor, Gemini and the rest differ in plenty of ways, but ask any of them to find something and they will go and look through files, because that is the motion they know best.
This matters more than it first appears. If you want an agent to use your product, there are two options. You can teach it your API, your object model, your particular names for things, and hope it holds on to all of that. Or you can put the work in a folder, where it already knows what to do.
I used to think the second option was a compromise, the thing you did when you could not afford a proper integration. I changed my mind. A shared convention that both sides learned independently is rarer than a good integration, and it does not need maintaining.
There is a practical side to this as well. Agents get better every few months, and each time they do, they get better at working with files too. A bespoke interface has to be rewritten to benefit. The folder gets the improvement for free, because the improvement was in the agent, and the folder was only ever the place the work happened.
I should say I am not claiming that every task becomes a file edit. Plenty of things want a proper interface: drawing, scheduling, anything with a lot of moving parts that a person needs to see. My claim is narrower. For the shared, written, long-lived material of a team, the folder is where the agents are already comfortable, and a person is comfortable too. That overlap is rare, and I would protect it.
Plans in Markdown, answers by asking
Something has been happening quietly on teams that use agents a lot. They have stopped keeping their plans in an app. The plan is a Markdown file. So are the specs, the meeting notes, the list of open questions, the page that says how we deploy. Markdown is not especially beautiful. It wins because an agent can read it without an adapter, and so can the person who joined last week.
The second shift follows from the first. If the plan is a file an agent can read, you stop clicking through an app to find out where things stand. You ask. Which tasks have no owner. What did we decide about pricing and when. Is there anything in the notes that contradicts the launch plan. The agent reads the folder and tells you, usually with the file it got it from, so you can check.
I find this oddly restful. The question comes first and the screen is optional.
What the folder never had
I should be fair to the folder, because it has real gaps, and they are the reason apps took over in the first place. A folder on one laptop is a private thing. It assumes one person, working on one machine, one at a time.
It has no idea that two people, or ten agents, might open the same file at once. When they do, the last save wins and someone's afternoon disappears, or the file forks into plan-final-v2-ACTUAL.md and a small argument about which is real. It cannot search across everything a team has ever written, so people keep a second system just to find things. And it has no memory: when something is saved over, it is gone.
Cloud storage fixed some of this by copying files around, which fixed the access problem and created a new one. Now there are copies. For a human team that is annoying. For a team with agents, which are quick and do not tire, it is a machine for producing versions.
Underneath all of these gaps is the same thing. The folder was designed for one person at one desk, and it has been asked to carry a whole team, and now a crowd of agents too. The interface is fine. It is the arrangement underneath that never grew to match.
Keep the folder, move the hard parts underneath
This is the idea behind Baseseat, and I will keep it short because it is the least interesting part of the argument. We kept the folder as the interface and put the missing things underneath it.
You mount a drive on macOS, or on Linux with FUSE, and it appears as a folder in Finder or a terminal. Agents can reach the same files over MCP, the CLI or the Python SDK without mounting anything. Everyone, people and agents, works in the same files at the same moment. Every save becomes a new revision. If your save was based on an older one, it is refused with stale_version and nothing is written, so the agent reads the latest and redoes its change on top. Both changes land, in order. Search covers the whole drive, and a deleted file waits in the trash for an hour.
That is the story from the start, really. Dalton asked Claude Code to tighten the goals in our launch plan while I, in a different city, asked Codex to give every task an owner. Codex found the new goals already in the file, kept them, and added the owners. Nobody sent anything or merged anything. Two people and two agents had just been working in one folder.
I do not think the folder is the interface of the future because it is clever. Everyone already knows it, including the new colleagues who never sleep, and the sensible thing to do with an interface like that is to leave it alone.