File systems are the new primitive for AI agents

01 — the shift

From schemas to a box that asks “What can I do for you?”

For two decades, building software meant starting with tables. A customer had requirements; your brain went straight to what schema do we need, what interface do we build? You can't look at a web app without seeing its data model underneath.

But interfaces are collapsing into a single prompt, and agents are what's behind them. The question is what those agents should stand on.

02 — what agent memory needs

A good read/write memory does four things

Reaching for SQL, ORMs, or APIs is natural — we've built a lot of software that way. But those interfaces were designed for programs that already know exactly what they want.

03 — the mismatch

Agents live one layer earlier than APIs

A web app calls GET /tasks/123 because a developer already turned intent into a precise operation. An agent is still upstream of that — interpreting messy goals, partial context, ambiguous names, and human corrections.

The agent can call the API — but it burns reasoning budget reconstructing assumptions, and you burn engineering budget keeping its instructions in sync with the system.

04 — the prior

LLMs already know how to use file systems

Really know. ls, cat, grep, cd, mkdir — every engineer recognizes these instantly, and so does every model, trained on 50+ years of Unix man pages, GitHub repos, and millions of documents about exactly how they behave.

05 — the fit

A filesystem checks the boxes — and gives the model handles it knows

It isn't a complete memory architecture, and pretending it is would be a mistake. But it's an unusually good substrate for the part agents struggle with most: durable, inspectable, revisable working context. Files give the model names, paths, hierarchy, timestamps, permissions, diffs, and conventions it already reasons about.

06 — the demo

Two markdown files, one agent, no bespoke API

A team-management agent backed by two files in Box — the same data denormalized across both. A human marked a task complete in the UI. Then: the agent noticed one file was newer, compared it to the other, synced the stale copy, and left an audit trail.

07 — once you see it

You start seeing files everywhere

It's not a coincidence that agent tooling keeps converging on file-shaped surfaces:

CLAUDE.md is just a markdown file. A skill is often a directory with a SKILL.md. Coding agents work by reading, editing, searching, and testing repositories. Platforms keep exposing file-like workspaces as the place models do their work.

08 — why it matters

Shared legibility is the real payoff

If an agent writes a row to a database, a human needs a product surface, an admin tool, a SQL query, or a log pipeline to see what happened. If an agent edits a markdown file, a human just opens it.

Cloud filesystems make this richer still: a shared drive isn't just storage — it's collaboration, access control, version history, search, preview, comments, legal hold, retention, and auditability. Exactly the boring enterprise requirements demos ignore until they become production problems.

09 — the honest caveat

A markdown file is not a database

But agents often don't need the database directly. What they need is a working set — plans, notes, task lists, policies, drafts, summaries, logs, corrections, decisions. For that layer, a filesystem-shaped interface is more legible to both the model and the humans supervising it.

10 — the broader move

Ride the model's priors

Every time you find yourself spending inference-time effort teaching an agent a custom abstraction, stop and ask whether there's already a paradigm the model knows deeply.

The answer won't always be “filesystem.” The point is that models aren't blank slates — they arrive with operational priors learned from the digital world we already built. Good agent design uses them.