Agents need a shared filesystem

This is the second post in a series about the infrastructure primitives behind Adapt. In the first, How we run sandboxes for agents at scale, we wrote about orc, the compute layer that gives every conversation its own isolated computer.

Giving an LLM a computer changes what it can do. It can write and run code, install software, call APIs, and build real artifacts instead of just returning text.

But a computer by itself has an obvious limitation: it forgets. A sandbox can do great work, then disappear when the conversation ends. The next sandbox starts fresh. It does not know about the report, the dataset, the app, or the workflow the last one created.

So we built basin, a shared filesystem for every organization. Now when a sandbox gets spun up, a shared filesystem is mounted at /mnt/org and shared with every other sandbox inside the organization. Work can persist beyond a single conversation and be available for the next agent, teammate, scheduled task, or app that needs it.

Sandboxes should be disposable

The local filesystem inside an Adapt sandbox is intentionally ephemeral.

That is not a limitation we want to work around by making every sandbox a long-lived machine. Disposable computers are easier to secure, update, recover, and scale. A conversation can get a clean environment with the tools it needs, do its work, and disappear without leaving behind old processes, stale dependencies, or untrusted files.

The problem isn't that the computer disappears, but that the work disappears with it. Making a sandbox persistent would solve this for that one conversation, but not for the organization. A teammate should not need to find the exact conversation that generated a report in order to use it. A scheduled task should not need to recreate a dataset from scratch because the last run ended. An agent building an app should not have to pass source code back through chat just so another agent can pick it up later.

The thing we want to persist is the work, and not the machine used to produce the work.

Why a filesystem?

We could have given every feature its own storage system.

Reports could go in one database. App code could go somewhere else. Knowledge could live behind another API. Scheduled tasks could manage their own state. Every new capability could introduce another abstraction for the model to learn and another integration for us to maintain.

That path creates a product full of special cases.

A filesystem is a much better interface because it is already the universal interface for work. Programs know how to read and write files. Developers know how to inspect them. LLMs can use ordinary tools like mkdir, cat, grep, Python, Node, and shell scripts without needing a custom SDK for every new thing we build.

Files also make ownership and handoff simple.

An LLM can write a report. Another LLM can read it. A scheduled task can update it. A teammate can inspect it. An app can use it as input. Nobody has to know which conversation, model, or workflow created it.

That is a much more natural foundation for software that is supposed to compound across a team.

The goal is not a shared directory

A shared directory is useful. But that is not the full idea.

The longer-term goal is a unified filesystem for the organization: one coherent place where an LLM can find the work that matters, create new work, and leave it in a form that other LLMs and people can build on.

That could include:

/mnt/org/knowledge/
/mnt/org/skills/
/mnt/org/apps/
/mnt/org/reports/
/mnt/org/data/
/mnt/org/events/

A report should not just be an answer buried in an old chat. It should be work the organization can reuse.

A skill should not just be a hidden configuration record. It should be something that can evolve as the team improves it.

An app should not be disconnected from the files, data, and workflows that created it.

An event from a connected system could become something agents can reason over, index, and react to.

The filesystem is the common layer underneath all of that.

Why this matters for an organization

Most AI products today are still organized around individual conversations. You ask a question. You get an answer. Maybe you save a prompt or upload a file. But the work largely remains attached to that one interaction.

That is useful, but it does not compound very well.

The more valuable version is one where each useful piece of work can become the starting point for the next piece of work. An LLM researches a customer and saves an account brief, a teammate improves it after a call, and an automation refreshes the facts each week. And this work can become the starting point for a new task. The organization gets better not because every person starts from zero with a better model, but because the useful work remains available.

What Basin enables today

Today, Basin gives Adapt organizations a persistent filesystem shared across their sandboxes.

That means different conversations, teammates, and automations can work from the same files without manually copying artifacts through chat or teaching each workflow about a separate storage API.

It is an early foundation, not the finished vision. We are not yet materializing every connected system as files. We are not yet indexing every filesystem change or turning every write into an automated workflow. We are not yet at a complete unified namespace for the organization. But we're well on our way to achieving that vision.

Stay tuned for deep dives on the tech.