An AI agent that does real work makes things: a research summary, a screenshot of a bug, a generated image, a cleaned-up CSV, notes for the next run. Then the run ends, the sandbox is thrown away, and the files go with it.
The context window doesn't solve this. Pasting a file back into the conversation costs tokens every turn, and once the conversation is over the file is gone anyway. Agents need somewhere outside the conversation to put things, and a way to find them again.
This guide covers what that storage needs to do, the four common ways to provide it, and how to set it up so next week's run can find what this week's run made.
What an agent needs from storage
Storage for an agent isn't quite storage for a person. Five things matter:
- It outlives the run. Files have to survive the sandbox, the container or the laptop the agent ran on.
- It can be searched. An agent can't browse a folder tree like you would. It needs to ask for "every report tagged with this project" and get an answer.
- Each agent has its own credentials. If one agent misbehaves or its key leaks, you want to switch off that agent, not every agent.
- Private is the default. Agents handle transcripts, customer data and drafts. A file that should have stayed private can't be un-shared once its link is out.
- Repeats don't pile up. Agents retry. A retry shouldn't leave three copies of the same file.
Four ways to do it
1. The local disk
The simplest option: let the agent write to a folder on the machine it runs on, or mount a volume into its container.
It works well for a single agent on a single machine. It falls apart as soon as the agent runs somewhere else, a second agent needs the files, or the machine goes away. Finding things means walking directories, so you end up encoding everything into file names.
2. A cloud storage bucket
Give the agent credentials for an object storage bucket and an SDK. This is durable and scales as far as you like.
The cost is setup and upkeep. You write access policies so each agent can only reach its own prefix, keep credentials somewhere the agent can read them, and teach the agent the SDK. Buckets don't search by content or tags out of the box, so you also build an index, usually a database table listing what's where.
3. An MCP filesystem server
If the agent runs in an MCP client, a filesystem MCP server gives it tools to read and write files in folders you allow. It's quick to set up and the agent understands it immediately.
It is still a local disk underneath: tied to one machine, with no search beyond file names, and no separation between agents beyond the folders you list.
4. A hosted file library with an API
A file library service stores files and the details about them, and lets you search both over HTTPS. Each agent gets a key; the service handles storage, links and search.
This is the category Stow (usestow.com) is in. The trade-off is that you depend on a service, and it's built for the files and data your apps and agents produce, not for huge archives: Stow takes files up to 25 MB.
Setting it up with Stow
Give each agent a key
Create an app on the Apps page of your Stow dashboard for each agent. Each app gets its own key, and each agent's uploads land in a folder named after it. Revoking one key leaves the other agents untouched.
Store what the agent makes
One request stores a file, or text sent as JSON. Store each result as soon as it exists, rather than collecting everything for the end of the run: a run that dies halfway keeps its first half.
curl -X POST https://api.usestow.com/v1/assets \
-H "Authorization: Bearer $STOW_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"text": "Pricing summary for week 43 ...",
"title": "Pricing summary, week 43",
"tags": ["report", "project:pricing", "week:2026-43"],
"visibility": "private"
}'
Stow works out the type of what you sent, stores identical content once, and returns the stored file's id and details.
Find it on the next run
Tags are the agent's filing system. Pick a few key:value tags and use them on every upload: the project, the task, the week. Then a later run can ask for exactly what it needs:
curl -X POST https://api.usestow.com/v1/assets/search \
-H "Authorization: Bearer $STOW_API_KEY" \
-H "Content-Type: application/json" \
-d '{"tags": ["report", "project:pricing"]}'
Search also matches words in titles, descriptions and file names, and can be limited to one folder or one type of file.
Use the MCP server, if your client speaks MCP
For MCP clients such as Claude Desktop and Claude Code, the Stow MCP server (in early access) gives the agent tools to upload, search and read files. Uploads made through it are private unless the agent asks for a public link, and public uploads that look like they contain a secret are refused. See the MCP server docs for the setup.
Habits that keep agent storage useful
- One key per agent. It keeps each agent's files in its own folder and lets you switch one off on its own.
- Tag on the way in. Retrofitting tags onto hundreds of files never happens. Decide on three or four tags and use them from the first upload.
- Private unless it's meant to be shared. Over the API, Stow files are public by default; send
"visibility": "private"for anything else. Public vs private file links explains why the choice matters. - Store as you go. Every finished result is one upload. A crash costs you the file in progress, not the run.
- Don't store secrets as files. Keys and passwords belong in your secret manager, not in an agent's output folder.
If you're weighing this up for a project, File storage for AI agents shows the whole setup on one page.