Agent memory isn't a storage problem

Give an agent something to remember and most teams reach for a database. It's a reasonable instinct and usually the wrong one. The cost of that choice doesn't show up in storage. It shows up in the model's context budget, every time the agent has to be reminded how your schema works.

Carter Rabasa recently made the case that the filesystem is turning into the natural memory interface for agents, and that the reason is simple. The model already knows how to use one. We think that's right, and the why is worth pushing on, because the why is what changes how an architect should choose. The reason a filesystem works isn't that files are a better place to keep state. It's that every other interface you could hand an agent arrives with a bill the filesystem doesn't.

Call it the teaching tax. It's the part of every agent's reasoning budget you spend teaching it an abstraction it didn't arrive knowing, like your schema, your endpoints, or the difference between three fields that all look like an ID. The agent can learn all of it, and a capable model will. But it pays for the lesson out of the same context window it needs for the actual work, and it pays again on the next call, because the window doesn't remember the last one.

One layer earlier

A normal program calls GET /tasks/123 because a developer already turned a human's intent into a precise operation. The endpoint exists because somebody decided, in advance, exactly what would be asked and exactly how to answer it. That's the whole premise of an API. It's a contract written for software that already knows what it wants.

An agent lives one layer earlier than that. It's still interpreting a messy goal, working from partial context and ambiguous names and a correction the user made halfway through. It hasn't yet collapsed intent into an operation, which is precisely the step the API assumes is already done. Hand that agent a normalized schema and a set of narrowly scoped endpoints, and you've handed it an interface optimized for a job it isn't doing yet.

The capability is not in question. Models call APIs and write SQL, and sometimes they should. The question is what it costs. To use your endpoints well, the agent has to reconstruct the mental model the developer had when they designed them, which means you have to teach it the schema, the relationships, the safe mutations, the edge cases, and the reason assignee_id and owner_id are not the same column. Then you have to keep teaching it as the system changes.

An operations team at a mid-size logistics platform wired their scheduling agent into the existing task service through the same REST endpoints the web app used, and kept a rule that the agent could only write through the API and never touch the database directly. Sound governance. The side effect was that every session opened with the agent spending part of its context being re-taught which of several near-identical fields meant what, and which writes were safe, before it could do anything useful. The endpoints worked. The toll was the teaching tax, paid per session, charged against the budget the agent needed for the actual scheduling. The sharper cost showed up on the busy days. When a session filled with enough back-and-forth that the context got tight, the part of the budget holding the field definitions was the part that got squeezed, and the agent would occasionally write a change to the wrong column. The errors clustered exactly when the system was under load, which is the worst time to be paying down a tax with reasoning the agent no longer had to spare.

What the model already knows

There's an interface the model didn't have to be taught, because the training already covered it. ls, cat, grep, cd, mkdir. Every engineer recognizes these on sight, and so does every model, because the foundation they were trained on includes decades of Unix manuals, open-source repositories, and the enormous body of writing that explains what these commands do and how they combine. The filesystem is the rare interface where the teaching tax is close to zero. The lesson was paid for upstream, once, by everyone who ever wrote about how a file works.

Once you notice this, the pattern is everywhere in how agents already get built. A CLAUDE.md is a markdown file. A skill is usually a directory with a SKILL.md and some supporting files. Coding agents do their work by reading, editing, searching, and testing files in a repository. Agent platforms keep landing on file-like workspaces and mounted storage as the place the model actually works. None of that is an accident. It's the model being met on the interface it already understands instead of one it has to be walked through.

A filesystem gives the model names, paths, hierarchy, timestamps, and conventions it can already reason about without instruction. It isn't a complete memory architecture, and treating it as one is its own mistake. But for the part of memory agents struggle with most, the durable working context that has to be read, revised, and corrected over time, a file is an unusually good substrate precisely because nobody has to explain it.

The second payer

The teaching tax is charged to two budgets, not one. The first is the model's context. The second is the attention of the human who has to supervise what the agent did, and this is the one most agent designs forget until it surfaces as a problem after the thing ships.

When an agent writes a row into a database, a human usually needs a product surface, an admin tool, or a query to find out what happened. When an agent edits a markdown file, a human opens it and reads the diff. They can comment on it, revert it, fix it by hand, or review it in a pull request the same way they'd review anyone else's change. The agent's memory becomes inspectable using tools that already exist, which means a stale assumption or a bad piece of state is something a person can see and delete rather than something buried in a store they need a separate interface to read. That changes the debugging loop. With a database-backed memory, finding out why an agent did something strange starts with building a way to look at what it remembered. With files, the looking is free, and the fix is often a one-line edit a reviewer can make and explain in the same commit.

Cloud filesystems push this further than a local disk can. A shared drive isn't only storage. It's version history, access control, search, retention, audit, and legal hold, the unglamorous enterprise machinery that agent demos tend to skip right up until the moment they go live and someone in security asks who can see what. The same interface the model reads for free is the one your governance already knows how to wrap. The tax stays low on both sides at once.

Where files are the wrong answer

Before the boundary, the difference is worth seeing in one place.

The idea gets oversold past this point, so it's worth saying plainly. When filesystems are in fashion, teams skip everything a database is actually good at. A markdown file is not a database, and building one out of files is how you end up with a slow, expensive shared document that does a database's job badly. When the work is transactional or analytical, the relational model earns its keep, and so do APIs and vector search. None of that is going away.

But an agent often doesn't need the database directly. What it needs is a working set. Plans, notes, task lists, policies, drafts, summaries, logs, and the running record of what it changed and why. That layer doesn't want strict consistency or analytical queries. It wants to be legible to the model writing it and the human reading it, and for that layer the teaching tax is the dominant cost in the decision, not throughput and not join performance. The instinct to reach for a real data layer is correct for the problems a data layer solves. It's miscast when the actual problem is giving an agent somewhere to think.

The deeper point isn't that the answer is always a filesystem. Sometimes the interface the model already knows is email, or a spreadsheet, or Git, or a calendar. The move is to stop and ask, every time you find yourself writing instructions to teach an agent a custom abstraction, whether there's a paradigm the model already learned that would cost nothing to adopt. Models don't arrive as blank slates. They arrive with operational priors from the digital world we already built, and an interface that rides those priors starts the agent at a different place than one that has to be explained from scratch.

The teaching tax is a line item almost nobody puts on the architecture diagram. Teams price storage by consistency and joins and throughput. They tune the model, the retrieval, and the prompt. They rarely price the interface itself, the toll the agent pays on every single call to use the thing they built, charged against the one budget that can't be expanded. The filesystem isn't the answer to every memory problem. But the teams reaching past it for a real data layer are often paying a tax they never accounted for, to buy guarantees the agent never asked for.