Why your AI agent needs a file layer, not just a tool layer

A developer is asking Claude Code to find every reference to a deprecated API across a 50 GB log archive that lives on S3. The agent is willing. The agent has tools. The agent starts calling s3:ListObjects, then s3:GetObject on the first page of results, parsing each response, paginating. About four minutes in, the context window is half-consumed by tool-call protocol overhead and the agent has searched approximately one percent of the archive. The developer cancels the run and goes for coffee.

This post is about the alternative. Mount the bucket as a drive. The agent runs grep -r 'deprecated_api' /mnt/logs and gets the answer in five seconds. Same workload, same archive, completely different time and token cost. The pattern generalizes to every cloud-hosted dataset an agent might want to touch — SharePoint docs, Drive projects, Box folders, Dropbox archives, SFTP intake — and every agent that lives in the grep, cat, find world today.

What the tool layer actually costs

When an AI agent talks to a cloud service through an SDK or an MCP server, every operation is a structured tool call. The protocol is verbose by design — the agent has to know what tools exist, what arguments they take, what they return, and how to chain them. The model burns context window on the schema and on the call/response pairs themselves.

A concrete budget for the log-archive case. 50 GB at an average object size of 5 MB is about 10,000 objects. To grep for a deprecated API string across all of them through the tool layer:

• One ListObjects call per page of 1,000 objects: 10 calls.
• One GetObject call per object the agent needs to read: up to 10,000 calls.
• Each GetObject returns a multi-megabyte response. The agent doesn't keep the full content in context, but it has to either grep it locally (impossible for a remote agent) or extract a search-result excerpt, both of which involve the model seeing significant portions of file content as tokens.
• Tool-call protocol overhead per call: about 200–400 tokens for the call/response envelope, before any payload.

Even with aggressive sampling and streaming, an agent doing this seriously will burn through its context window in the first thousand files and have to give up or restart. The provider SDKs and MCP servers exist for cases where the agent legitimately needs to invoke a typed API (start a job, change a setting, kick off a workflow). They're the wrong shape for read these files and tell me what's in them.

What the file layer does instead

Mount the same bucket as a filesystem under, say, /mnt/logs. The agent now has access to the bucket through the operations its built-in tools already know how to use:

• Bash tool: grep -r 'deprecated_api' /mnt/logs returns the matching lines and paths in a single tool call.
• Read tool: Read('/mnt/logs/2026-03/server-04.log') returns the file content.
• Bash tool again: find /mnt/logs -name '*.gz' -newer 2026-04-01 returns the files matching a date filter.

Three tool calls instead of ten thousand. The agent's context budget is spent on reasoning about results, not on protocol overhead. The 50 GB scan that timed out in the tool-layer version completes in seconds because the actual byte processing happens kernel-side and the agent only sees the matching lines.

The mount also gives the agent the operations it doesn't have an SDK call for. There is no S3 API for grep recursively starting from this prefix, returning context lines around matches. There is no SharePoint API for find every file modified in the last week containing this phrase. The Unix toolchain has those operations and has had them for forty years. Mounting the cloud as a drive is what gives the agent access to them.

Three real workflows where this matters

Claude reads a team's SharePoint docs

A product manager points Claude at a SharePoint site holding three years of meeting notes, RFCs, and design docs. The ask is summarize the architecture decisions we made about retry logic.

Through the tool layer: Claude would need a SharePoint MCP server (one exists, but it's its own setup and authentication story), or it would need the user to paste in URLs one at a time and Claude would call GetFile for each. Every file passes through the model's context. The summary is bounded by how many files Claude can read before it hits the wall.

Through the file layer: SharePoint is mounted at /Volumes/SharePoint/Architecture/. Claude runs grep -rli 'retry' /Volumes/SharePoint/Architecture/ | head -50 to find the relevant files, then reads the dozen most relevant ones in full. Same task, ten times the throughput, none of the per-call overhead.

Codex refactors a project hosted on Drive

A team's documentation project lives in Google Drive — a folder of Markdown files, some PDFs, and a couple of spreadsheets. The team wants to migrate it to a Git repo with consistent frontmatter. Codex is willing to do the refactor.

Through the tool layer: Codex needs to enumerate the Drive folder via the Drive API, download each file, transform it, write the output somewhere (where? back to Drive? to a local checkout? to GitHub?). The protocol overhead on the read path is real, and the write path needs another set of API calls.

Through the file layer: Drive is mounted at ~/Drive/. Codex treats ~/Drive/Docs/ as a source directory and ~/repos/docs-site/content/ as a destination. It runs the same find / sed / mkdir -p operations it would run on a local refactor. The Drive operations are byte-for-byte what the agent would do if the files were already local.

Cursor grounds suggestions on an S3 build artifact

A Cursor user is editing an iOS app that's built nightly into a 200-file build artifact stored on S3. Cursor's code completion gets better if it can see the build artifact for context. There's no Cursor plugin for "read this S3 bucket as if it were a source folder."

Through the tool layer: Cursor's MCP server support exists, but writing a custom MCP server to expose S3 reads to Cursor is a real engineering project for a single user's convenience.

Through the file layer: S3 is mounted at ~/builds/nightly/. Cursor's existing file indexer sees the build artifact as a normal folder and indexes it. Cursor's completion gets the context it would have if the build were a sibling folder in the local repo. Setup time: five minutes of ExpanDrive configuration.

Why this works — agents are filesystem-native

Every modern AI coding agent is built around a set of built-in tools that assume a filesystem. Anthropic's Claude has Read, Write, Glob, Grep, Bash. OpenAI's Codex has equivalent primitives. The agents in IDEs (Cursor, Continue, Aider) all expect to operate on a project directory. The contract every one of them inherits from is here is a folder, do things to it.

Cloud providers don't speak that contract. They speak HTTPS APIs with typed payloads, presigned URLs, and pagination tokens. To get the cloud data into the shape the agent already knows how to use, something has to translate. The two options are:

• Write an MCP server (or a tool-handler plugin, or a wrapper SDK call) for each cloud service the agent needs to touch. This is what happens when an agent vendor adds "Drive support" or "SharePoint support." It works, but every cloud needs its own integration, every integration has its own auth and permissions story, and the agent's context burns on the SDK overhead.
• Mount the cloud as a drive. Now the agent's existing filesystem tools just work — across every cloud service, with the same workflow, with no per-cloud integration to maintain. The cost is the mount layer itself, which a tool like ExpanDrive provides for the major cloud services in one install.

The file layer wins on the simple cases (read files, search files, edit files) because the simple cases are the cases the agent's primitives were designed for. The tool layer is the right answer for the operations a filesystem can't express — start a Workflow, send an Approval, list all admins, change a permission — but those operations are the minority of what an agent actually does on cloud-hosted data.

Honest about the edges

A few real caveats:

Latency on a mount is not zero. A cat of a 200 MB file from a mounted bucket takes longer than a cat of a local file. For random small-reads in a tight loop, the round-trip time adds up. The mitigation is pin-for-offline on the hot subset of data — mark the directories the agent reads from most often as locally resident, and the rest stays in the cloud on-demand. For most agent workflows the latency doesn't matter; the agent isn't running a tight loop, it's running a small number of high-value reads.

Some workflows want a real local clone. If the agent is going to do a hundred-pass refactor over a repo, cloning the repo locally is faster than working against a mount. The mount is the right answer when the data is too large to clone (a 500 GB log archive) or too live to clone (a SharePoint site that's getting updated while the agent works). For small, snapshot-stable data, just clone.

Read-only mounting is the safer default for an agent. Letting an agent write into a mount means a bug in the agent can wreck the source-of-truth in the cloud. The conservative default is to mount read-only and have the agent write to a local staging directory it owns, then promote the staging output to the cloud as a deliberate step. ExpanDrive supports read-only mode per connection; use it.

The agent still needs the right credentials. Mounting doesn't bypass authentication. The mount uses your credentials to talk to the cloud service, and the agent runs as you. If the agent shouldn't see something, don't give the mount credentials that can see it. Standard least-privilege rules apply.

Some operations genuinely need the API. Anything that's not a file read or write — adding a user to a team, changing a sharing policy, starting a workflow — needs the API. The file layer doesn't replace the tool layer for those; it complements it. The right architecture for most agent workflows is file layer for data, tool layer for actions.

What this looks like at the enterprise level

Most of this post has been about the individual-developer workflow. The same pattern scales up, and at scale the requirements shift. A team wants the AI agent to read from cloud storage, but they also want audit logs of what the agent read, IAM-grade permissions on which directories the agent can see, and the ability to wire the same mount up to an MCP server for the cases where typed API access is the right shape.

Files.com is the version of this story with IAM, audit logs, per-folder permissions, and a hosted MCP server on top of the same data the mount exposes. The mount-as-drive workflow your developers run on their laptops is the same data your governance and compliance team can audit centrally. Agents get the file-layer access they need; the company gets the visibility it needs. Worth knowing as the option for the cases where the individual developer's setup grows into a team and a team grows into a fleet.

What to do next

If you're running an AI agent against any cloud-hosted data today and watching it grind through SDK calls, try the file layer. Download ExpanDrive, connect the cloud account the agent's already working against (S3, Drive, SharePoint, Box, Dropbox, OneDrive, SFTP — they all mount the same way), and point the agent at the mount path instead of through the SDK. The behavior change is immediate.

The first thing to do is pick the agent workflow that's currently most annoying and try it against a mount. If it's faster, you have a new pattern. If it isn't, you've learned something about when the file layer doesn't help, and the mount stays useful for the other workflows it does help.