Your agent's mailbox is now a file store

Sendmux is the email API for AI agents. As of today, every agent mailbox also works as file storage for AI agents: files land in the mailbox by email or direct upload, and your agent lists, filters, and reads them on demand. No base64 in the prompt, no second storage service to wire up.

A customer emails your support agent a 4 MB PDF contract and asks about clause 7. That moment used to force an ugly choice. Now the file just sits in the agent's mailbox, ready to read. Here's what shipped, and how to use it across our MCP server, CLI, and five SDKs.

What is file storage for AI agents?

File storage for AI agents is a durable place an agent can keep files and fetch them back later, using credentials it already holds. In Sendmux, that place is the agent's mailbox. Any file emailed to the address is kept, and your agent can upload files directly too. Each attachment can be up to 7.5 MB, inside a 25 MB limit for the whole message.

The mailbox was already the agent's identity for sending and receiving. Now it doubles as the agent's filing cabinet, so you don't run a separate bucket, parser, and credential set beside it.

Why agents needed this

Agents handle files constantly: contracts, invoices, receipts, screenshots, data exports. Two habits formed around that, and both hurt. Storing files where the mail already lives removes the reason for either one.

The first habit was stuffing file bytes into the model as base64. It works for a tiny image and falls apart for a real document. Tokens balloon, latency climbs, and the bill follows. The second was bolting a storage service, a parser, and another API key onto the mailbox, then keeping all of it in sync. Both are effort spent on plumbing instead of the agent. With mailbox storage, the agent reads a contract the same way it reads the message it arrived on.

How files get into the mailbox

Files reach the mailbox two ways. They arrive as ordinary email attachments, or your agent uploads them directly. Inbound is the simple path: anyone, or any system, emails a file to the agent's address and it's stored with the message.

For outbound or upload-first work, your agent sends the bytes once and gets back a blob_id to attach to a later send. Upload runs over a dedicated endpoint, so file bytes never sit inside a large JSON request body. Big files use a presigned upload instead: your agent mints a short-lived, one-use upload URL, then puts the bytes straight to it. The mint is authenticated. The upload URL isn't, but it's pinned to the exact byte size and content type you declared, and it can write only that one attachment.

How your agent finds and reads a file

Retrieval is the useful half. Your agent lists and filters its own mail by sender, date, folder, keyword, or whether a message even carries an attachment. It finds the file it wants, then pulls the bytes through a short-lived download link.

That link needs no API key and no custom headers, so it works even in clients that can only fetch a URL. Downloads support byte ranges, so the agent grabs one slice of a large file rather than the whole thing. The bytes never pass through the model's prompt. The agent reasons over the full context, the thread, the earlier replies, and the attached documents, then answers from all of it at once.

The same workflow across MCP, CLI, and SDKs

Every Sendmux surface carries the same upload-and-read flow, so you pick the one that fits your stack. The file storage behaves identically whether an agent calls it through a tool, a terminal, or application code.

MCP server: a local tool takes a file path and uploads it for you. Hosted agents mint a one-use presigned URL instead, so no file bytes cross the tool call.

CLI: add --attach<path> to a send, or upload first with a file flag for presigned workflows.

SDKs: TypeScript, Python, Go, PHP, and Ruby each expose a file helper where the language ships one, so you skip the manual base64 step.

Where mailbox file storage helps

The pattern shows up wherever an agent deals with documents, not just text. A support agent reads the contract or screenshot a customer attached, answers from it, and files the thread for later. A finance or ops agent collects invoices and receipts emailed by vendors, keeps them in one mailbox, and pulls the right one when a reconciliation question lands. A research or monitoring agent saves the source PDFs and exports it was sent, then cites them when it reports back.

In each case the file and the conversation live together, under one mailbox key. The agent doesn't juggle a storage SDK, a separate auth flow, and a sync job on top of its email. It reads the attachment the same way it reads the message, and the receipt from March is still there when a question about it arrives in September.

What agent mailbox storage costs

Mailbox storage is metered at 0.15 per 1,000 messages for sending through your own providers and for mail you receive. You never pay for a seat or an empty inbox. That matters when you run a fleet: a thousand agent mailboxes cost nothing until files and mail start flowing through them.

What's live today, and what's next

Today your agent stores files and finds them by listing, filtering, and keyword search inside its own mailbox. That covers the everyday jobs: find the latest invoice from a sender, pull the attachment off Tuesday's thread, read the contract a customer just sent.

Semantic search and querying across a whole team's mailboxes are on the roadmap, not in the product yet. We'd rather ship the honest version and say so than dress up a demo as a feature.

Try it

Create a free @myagent.mx mailbox, email it a file, and have your agent read it back to you in a few lines of code. The mailbox your agent already sends and receives from is now the place its files live too.