Introducing agentfs: A Filesystem for AI Agents

Last updated: April 28, 2026

The Storage Problem for Agents#

Agents need to read and write files. That sounds boring until you try to actually do it in production.

Most agent frameworks paper over the problem with one of three options. The first is the local disk on whatever VM the runtime happens to be sitting on. That works for a single process, but the next agent run starts on a different machine and cannot find anything. The second is a blob store like S3. That works at scale, but it is shaped wrong. Listing a prefix is not the same as listing a directory. Atomic rename is fiddly. Reading a slice of a file means signed URLs and range headers. Most agent code is written as if there is a real filesystem underneath, and there is not. The third is a sandbox like E2B or Daytona. That gives you a real disk, but the disk dies when the sandbox dies, and the cold start cost is real.

None of these is wrong. They are answers to different questions. The question we kept hitting is smaller and more specific. Where does an agent put a file when it wants to come back to it tomorrow, from a different process, on a different machine, without spinning up a VM to find it?

That is the question agentfs is built to answer.

What agentfs Is#

agentfs is a virtualized filesystem for AI agents, backed by Neon Postgres. You talk to it over HTTP. Files have paths. Directories list. Reads and writes are atomic at the file level. There is no machine to provision and no container to wait on.

The model is intentionally small. A workspace is a tree. A path is a string. A file is a blob with metadata, a content type, and a version. Operations are the ones you would expect: read, write, list, move, delete, stat. There is no shell. There is no exec. There is no way to ask the filesystem to run code on your behalf, because the filesystem is not a sandbox and pretending otherwise is how you get the four hundred dollar overnight bill we wrote about in Agent FinOps.

Under the hood, every workspace lives in a Neon branch. Metadata is a few Postgres tables. File contents up to a small size sit inline in Postgres. Larger blobs will spill to object storage in a later release, transparently. Because Neon scales to zero and resumes in milliseconds, there is no cold start to speak of from the agent's point of view. You hit the API, you get the bytes back, you move on.

The pitch is simple. Filesystem-shaped storage for agents. Pay-only. Postgres-backed. No cold starts. No exec, by design.

What agentfs Is Not#

It is worth being explicit about what is out of scope, because being honest about scope is how products earn trust.

agentfs is not a code execution sandbox. If you need to run untrusted Python or compile a binary, reach for E2B, Daytona, or Replit. agentfs is the place those sandboxes can mount a workspace from, not a replacement for them.

agentfs is not a general object store. If your workload is hundreds of gigabytes of training data, S3 is fine and cheap. agentfs is shaped around files an agent reads and writes during a run: notes, drafts, intermediate state, generated code, partial outputs.

agentfs is not a database. There are no queries beyond path operations. If you want to search inside files, build the index in your application.

The point of saying no to these is to say yes, with confidence, to the workload that is left. That workload is large and underserved.

The Pricing Thesis#

There is no free plan.

That decision was deliberate, and it is worth explaining. Free plans on infrastructure products attract two kinds of users. The first kind never converts and never will. The second kind hits the free limit, churns to a competitor with a higher free limit, and treats the product as a commodity. Neither group helps the people who actually need the product to exist in two years.

The pricing is twenty dollars per month for the Plus plan, paid through Clerk Billing, with usage-based tiers above that for storage and request volume. Authentication is Clerk. Billing is Clerk Billing. There is one button to upgrade and one place to manage everything.

Twenty dollars buys a working filesystem with enough headroom for a real agent project. If your agent is doing enough work that it needs more, the usage tiers handle that without a sales call. If you are not sure whether you need it, you probably do not, and that is a fine answer.

This is the same logic that drives the Pay-Only Playbook: users who pay tell you the truth about what they need, users who do not pay tell you what they want for free. Both are useful, but only the first kind builds a durable business.

API Tour#

Here is the shape of the API. The full reference will land with v0.1.

curl#

# Write a file
curl -X PUT https://api.agentfs.dev/v1/fs/notes/draft.md \
  -H "Authorization: Bearer $AGENTFS_TOKEN" \
  -H "Content-Type: text/markdown" \
  --data-binary @draft.md

# Read it back
curl https://api.agentfs.dev/v1/fs/notes/draft.md \
  -H "Authorization: Bearer $AGENTFS_TOKEN"

# List a directory
curl https://api.agentfs.dev/v1/ls/notes \
  -H "Authorization: Bearer $AGENTFS_TOKEN"

JavaScript#

import { AgentFS } from "@agentfs/sdk";

const fs = new AgentFS({ token: process.env.AGENTFS_TOKEN });

await fs.write("notes/draft.md", "# Draft\n\nFirst pass.");
const text = await fs.read("notes/draft.md");
const entries = await fs.list("notes");

Python#

from agentfs import AgentFS

fs = AgentFS(token=os.environ["AGENTFS_TOKEN"])

fs.write("notes/draft.md", "# Draft\n\nFirst pass.")
text = fs.read("notes/draft.md")
entries = fs.list("notes")

The API is small on purpose. If your agent already speaks the Python pathlib or Node fs/promises shape, the wrappers should feel familiar within a few minutes.

The Wedge: agentfs vs E2B, Daytona, Replit#

The closest products in spirit are the agent sandboxes: E2B, Daytona, Replit Agent. They all have filesystems. So why a separate product?

Because their filesystem is a side effect of running a VM. The VM is the product. The disk goes away when the VM does. If you want a file to outlive the run, you write it somewhere else and read it back next time. That is a fine model when you also need to execute code, and a heavy one when you do not.

agentfs is the opposite trade. There is no VM. There is no execution. There is only the disk. If your agent runs in a sandbox today, it can keep running there and use agentfs as the place its files live across runs. If your agent does not need a sandbox at all, you skip the VM entirely and just talk to the API.

The simplest way to think about it: sandboxes are compute with a disk attached. agentfs is a disk with no compute attached. Most agent workloads need both, but they need them on different lifecycles. The disk should outlive the compute. Today they are coupled. agentfs decouples them.

Compare more options on the tools comparison page or browse the rest of the Developers Digest apps.

Roadmap Honesty#

It is easier to get a product taken seriously when you are clear about what is in the box today and what is not.

v0.1 is the first public release. Files smaller than one megabyte. No code execution of any kind. No large binary blob support. No streaming reads or writes. No realtime change feed. No multi-region. Single workspace per account.

That is a deliberately small starting surface. Most agent files are small. Most agent files are text. The first version is sized to that case and nothing else. Trying to do more on day one is how products end up half-finished in three places.

What comes after v0.1, in rough order:

• Large file support, with object storage spill for blobs over the inline threshold.
• Streaming reads and writes, for agents that produce output token by token.
• A change feed, so a watcher process can react to new files without polling.
• Multiple workspaces per account, with separate access tokens.
• Snapshots and time travel, taking advantage of Neon branching.
• A small filesystem mount, for agents that genuinely cannot speak HTTP.

None of those ship in v0.1. Some may not ship at all. The roadmap is what we are working toward, not a promise. If you build on v0.1, you should build on what is there today, not what might be there later. We wrote more about how we think about this in the build-in-public meta post.

How to Try It#

The repo is private while we scaffold. Sign up at agentfs.dev to get on the early access list. Authentication is Clerk, payment is Clerk Billing, the Plus plan is twenty dollars a month, and there is no free plan. If you want to read more about how we are thinking about agents and storage, the agent memory patterns post covers the broader picture, and the rest of the Developers Digest apps shows what we are shipping alongside this.

agentfs is small on purpose. It does one thing. We think that thing is worth twenty dollars a month if you are building agents that need to remember anything across runs. If it is not, the cost of finding out is one month.

FAQ#

What is agentfs?#

agentfs is a virtualized filesystem for AI agents, backed by Neon Postgres and accessed over HTTP. Files have paths, directories list, and reads and writes are atomic at the file level. Operations are read, write, list, move, delete and stat, with no machine to provision and no container to wait on.

Can agentfs run code like E2B or Daytona?#

No. agentfs has no shell and no exec, by design. It is not a code execution sandbox. If you need to run untrusted code, use a sandbox such as E2B, Daytona or Replit, and use agentfs as the place those sandboxes keep files that need to outlive a run.

Does agentfs have a free plan?#

No. There is no free plan. The Plus plan is twenty dollars per month through Clerk Billing, with usage-based tiers above that for storage and request volume.

What are the limits of agentfs v0.1?#

v0.1 supports files smaller than one megabyte, with no code execution, no large binary blob support, no streaming reads or writes, no realtime change feed, no multi-region, and a single workspace per account. Large files, streaming, a change feed, multiple workspaces, snapshots and a filesystem mount are on the roadmap, but not promised.

Sources#

• Neon
• Daytona