My AI agent created a folder, wrote a blog post into it, and confirmed success. Thirty seconds later, the folder was gone. The file was gone. The agent’s write call returned success — because at the POSIX level, it did succeed. Then OneDrive’s sync daemon ran its reconciliation cycle, decided the folder didn’t exist on the server, and deleted the local copy to match.
This happened three times in one session before the agent gave up and wrote to a different path.
This isn’t a OneDrive bug. It’s a fundamental architectural mismatch: cloud-synced filesystems are eventually consistent, and AI agents expect transactional writes. Every agent builder working with local files on macOS, Windows, or Linux is going to hit this wall.
The Five Failure Modes
After tracking these failures across dozens of agent sessions, the same patterns repeat:
1. New Folders Vanish After Sync
Agent creates a subfolder → writes a file into it → folder appears locally → sync daemon runs → folder and contents disappear. OneDrive’s Files On-Demand (mandatory since macOS 12.1 Monterey) reconciles local state against server state. If the folder was never uploaded, the next reconciliation removes it locally.
2. Edits Land on Stale Copies
Agent reads a file → edits it → writes back. Between the read and write, OneDrive may pull a server-side version that overwrites the local copy. Microsoft documents this: “OneDrive replaces newer versions of files with old versions”. The agent’s edit lands on a version that then gets clobbered.
3. Rapid Multi-Step Writes Race the Sync Daemon
Agent creates a folder → writes File A → writes File B → edits File A. By the time it returns to File A, the folder or file has been “reconciled away.” OneDrive’s change detection polls every 30–60 seconds. Agent operations happen in under a second. These two cadences are incompatible.
4. Cloud-Only Folders Return Empty
readdir on a shared folder returns 0 items even though files exist. The folder is “online-only” — macOS shows the mount point, but contents are cloud-only placeholders that haven’t been hydrated. Files On-Demand working as designed — and breaking every programmatic tool that expects POSIX semantics.
5. Files Appear in Wrong Folders
Files written to one folder appear in a different one, or get duplicated. macOS metadata indexing (Spotlight, .DS_Store, extended attributes) confuses the sync daemon’s change detection. Microsoft acknowledges the pattern: “OneDrive might misinterpret the file as new or different, leading to duplicates or corruption”.
Why Agents — Not Humans — Exposed This
These failure modes have existed for years. Microsoft’s support forums have hundreds of reports. But humans rarely noticed because they write one file every few minutes, with seconds between operations. The sync daemon’s eventual consistency was invisible.
AI agents write differently:
| Human File Operations | Agent File Operations |
|---|---|
| One file at a time | Folder + multiple files in <1 second |
| Minutes between writes | Milliseconds between writes |
| Expects “save” might fail | Expects write() returning success = persisted |
| Never reads back immediately | Reads back instantly to verify |
| Can see Finder sync status | No visibility into sync state |
The fundamental tension: OneDrive is an eventually-consistent cloud sync layer masquerading as a POSIX filesystem. AI agents treat it as a transactional filesystem. The contract is broken.
This isn’t OneDrive-specific. The same class of failures would hit:
- iCloud Drive (Apple documents the same race conditions)
- Google Drive File Stream
- Dropbox Smart Sync
fast.io documented (Feb 2026) that “without good sync, agents re-download files, miss updates from others, and lose past context” — but their solution is a purpose-built sync layer for agents, not a fix for the underlying architectural mismatch.
The Enterprise Version: SharePoint
SharePoint is the same problem, minus the sync daemon, plus three new ones.
OneDrive, Google Drive, and Dropbox are sync layers pretending to be filesystems. SharePoint doesn’t even pretend to be a filesystem — it’s a content management system accessed via REST API (Microsoft Graph). That means all the sync-daemon failure modes are still present when SharePoint is accessed through the OneDrive sync client, and then SharePoint adds its own class of failures on top.
No POSIX semantics by design. There’s no atomic rename. No cross-file atomic operations. No file locking. An agent that writes a folder structure, moves a file, and reads it back is issuing three separate API calls with no transactional guarantee between them. Microsoft acknowledges this directly: agents writing to SharePoint may see stale or missing data on read-back, especially when a second workflow acts on the same content simultaneously.
Eventual consistency on search. Newly written files are not immediately indexed. An agent that writes a document and then queries SharePoint for it may get zero results and treat the write as failed — when in fact the file exists but hasn’t been indexed yet. There’s no documented SLA on indexing latency. The agent’s write and SharePoint’s search index operate on different clocks, with no synchronization signal between them.
The Graph API throttle is a hard ceiling. SharePoint’s write quota is 3,000 requests per 2.5 minutes per app-tenant pair — and Microsoft cannot raise it. An agent writing file state at machine speed will hit 429s. The prescribed response is Retry-After + backoff, which means an agent that expects write-and-continue semantics has to be redesigned around an assumption of intermittent write failure. Most agent frameworks aren’t built this way.
Structural limits that agents hit programmatically. 1,000 files, 50 folders, and 10 subfolder layers per source. An agent scaffolding a project structure, generating test artifacts, or archiving session state can exhaust these limits without a human ever noticing — until the next write silently fails.
The framing that ties these together: OneDrive is an eventually-consistent sync layer masquerading as a filesystem. SharePoint is a document management system masquerading as a storage layer. They fail agents for the same root reason — both were built for humans saving documents every few minutes, not machines writing state at sub-second intervals. The failure modes differ in the details; the architectural mismatch is identical.
The Collaboration Model Is Also Wrong
Fix the consistency problems and a second, deeper mismatch remains: these tools were built for how humans collaborate, not how agents do.
Human collaboration needs: a shared folder both parties can see, a comment thread, a co-editing session, an @mention, a notification. SharePoint, Google Drive, OneDrive, and Dropbox were all designed around these primitives. Every feature — version history surfaced in a UI, real-time co-authoring, permissions by person, activity feeds — exists because humans need visibility, coordination signals, and social context to work together.
Agents need none of that. An agent doesn’t read @mentions. It doesn’t benefit from a comment thread. It doesn’t need a notification that someone edited the file — it needs to know what changed, when, and whether its local state is still valid.
What agents actually need for collaboration:
| Human collaboration need | Agent collaboration need |
|---|---|
| Shared folder both can see | Distributed clone — each agent has a full copy |
| Co-editing / real-time sync | Branching — parallel work without interference |
| Version history in a UI | Diff — machine-readable change log |
| Conflict resolution by human | Merge — deterministic conflict resolution |
| @mention / notification | Pull — agent fetches state when it needs it |
| Permissions by person | Signed commit — authorship is cryptographically verified |
Git provides every item in the right column. It has been doing so at scale for decades. The Linux kernel — 2,134 developers in the 6.18 release alone, 725 contributing organizations, 80,035 changesets across the 2025 LTS cycle — operates with no shared folder, no co-editing session, and no notification feed. Every coordination primitive is a git operation. The npm registry, the Python Package Index, and the broader GitHub ecosystem — 100 million developers, 227 million pull requests merged in a single year — all run on the same mechanism. The open source contributor community is, functionally, a distributed multi-agent system that solved the multi-writer coordination problem before AI agents existed.
The field is catching up to this. Scott Chacon — GitHub’s co-founder, now building GitButler — is explicitly reimagining git for agentic workflows: parallel branches for parallel agents, agent-optimized diffs, autonomous merge. OWL, the multi-agent framework that tops the GAIA benchmark, uses git and MCP tools as the coordination layer between agents. Letta introduced a portable agent file format specifically so agents can be version-controlled and checked into repos alongside the code they operate on. The convergence is not coincidental — it’s the field discovering that git is the correct primitive.
The reason this matters beyond code: agents are no longer writing only code. They write Markdown, JSON, YAML, prompts, skills, structured notes, handoff files. All of these are text. Git handles text. The same mechanism that coordinates 2,134 human contributors on a kernel release can coordinate ten agents writing knowledge artifacts — because the underlying problem is identical: multiple writers, shared state, deterministic conflict resolution.
Cloud sync tools solve the human version of this problem. Git solves the agent version. The tools that dominate enterprise collaboration today were optimized for the wrong consumer.
The Punchline
The filesystem is the most durable abstraction in computing. LLMs are trained on files. Agent frameworks use file operations as their primary state management tool. That’s not going to change.
What needs to change is what’s underneath. Cloud-synced mount points — OneDrive, Google Drive, iCloud, Dropbox, SharePoint — were designed for humans saving documents every few minutes, not for agents writing state at machine speed. They’re eventually consistent layers masquerading as something agents can rely on.
The question isn’t whether to replace them. It’s what to replace them with. The answer points toward S3 as the durable substrate and git as the collaboration interface — no sync daemon, no throttle ceiling, no collaboration model built for humans.