OneDrive and Google Drive as working memory for AI agents

Part of the Matrix company OS series.

Company files already contain much of the context agents need. The difficult part is not uploading a PDF to a model. It is giving agents reliable, current, permission-aware access to thousands of changing files without creating a second uncontrolled document system.

For Matrix OS, OneDrive and Google Drive should behave like connected working memory: searchable when authorized, traceable to the source, responsive to changes, and writable only through explicit policy.

This post lays out the technical direction we are exploring. It is not an announcement that these integrations are generally available.

The sync client is useful, but it is not the whole architecture

A Linux sync client can make cloud files look local. That is appealing because agents already know how to use a filesystem. It can also help with offline tooling, previews, and applications that expect paths.

But a filesystem mirror alone does not answer the hardest questions:

• Which user authorized access?
• Did the source permission change?
• Is the local file current?
• Was an item deleted or merely moved?
• Does a shared link grant access outside the workspace?
• Which version did the agent use?
• Should a local write update the source immediately?

The more robust architecture combines provider APIs with a controlled local materialization layer.

The Matrix storage model remains useful for workspace artifacts. Connected drives remain external systems of record.

Track files by stable identity, not only by path

Paths are comfortable for people and fragile for synchronization. Folders are renamed. Files move. Two files can reuse the same name.

Microsoft Graph's driveItem delta API returns a cursor for tracking changes over time and explicitly recommends tracking items by ID because renaming a folder does not cause every descendant to reappear with a new path. Google Drive's changes collection similarly returns the current state of changed files and uses stored page tokens to continue from a known point.

Matrix should therefore maintain a provider-neutral record resembling:

provider: microsoft-graph
tenant: organization-id
drive: drive-id
item: stable-item-id
version: provider-version-or-etag
location: human-readable-path
permissions_version: observed-permission-state
last_seen: timestamp

The human-readable path is presentation. The stable provider identity is the key.

Use notifications to wake the system, then reconcile from a cursor

Webhooks are signals, not a complete ledger.

Microsoft Graph change notifications can tell an application that a resource was created, updated, or deleted. Subscription lifetimes vary by resource and subscriptions must be renewed. Microsoft also documents lifecycle events for reauthorization, removed subscriptions, and missed notifications.

Google Drive's changes.watch sends a notification that new changes exist, but the notification does not contain the change details. The application must read the change feed using its saved page token.

That leads to a resilient pattern:

1. Store the provider cursor durably.
2. Receive a notification or run a scheduled reconciliation.
3. Fetch every page after the stored cursor.
4. Process changes idempotently.
5. update the searchable representation and access state.
6. Commit the new cursor only after processing succeeds.
7. Periodically perform a broader reconciliation to detect drift.

If a webhook is delayed or dropped, the cursor still recovers the sequence. If the same event arrives twice, idempotency prevents duplicate work.

Index less than you can access

An OAuth grant defines a technical maximum, not what every agent should automatically see.

Matrix should separate four scopes:

1. Provider grant: what Microsoft or Google allows the integration to access.
2. Organization policy: which drives, sites, or folders may enter Matrix workflows.
3. Workspace scope: which sources are connected to a specific project.
4. Run scope: which items and operations an agent receives for one task.

Both Microsoft and Google recommend least-privilege authorization. Google classifies some broad Drive scopes as restricted and recommends using the narrowest scope possible. Microsoft distinguishes user-delegated permissions from broader application permissions.

The index should follow the same principle. Do not embed an entire tenant simply because an application permission makes it technically possible. Prefer explicit roots, metadata filters, and per-workspace inclusion.

Retrieval needs provenance and freshness

When an agent uses a passage, Matrix should be able to say where it came from.

A retrieved chunk needs more than text and an embedding:

• provider and stable file ID,
• file name and source link,
• observed version or ETag,
• extraction timestamp,
• page, sheet, slide, or section location,
• workspace and permission context,
• parser version,
• classification or sensitivity metadata where available.

Before a consequential action, the system can compare the indexed version with the provider's current version. If the source changed after retrieval, the run should refresh or ask for review rather than confidently acting on stale context.

This is the difference between “memory” as a convenient model feature and memory as company infrastructure.

Permissions can change independently of content

A file can remain byte-for-byte identical while its audience changes. That is why access-state reconciliation matters.

Microsoft's OneDrive delta documentation includes mechanisms for identifying sharing changes in OneDrive for Business and SharePoint scenarios. Google Drive exposes permission resources and shared-drive behavior through its API. Matrix should treat these as security events:

• remove inaccessible content from retrieval,
• invalidate cached materializations,
• stop or narrow active workflows,
• record the policy transition,
• avoid leaking the old content in summaries or derived indexes.

Derived data is the hard case. If an agent generated a report from a file that later becomes inaccessible, the organization needs a retention policy for the report; deleting the source from the index does not automatically answer whether every derivative must disappear.

Writes should be staged, version-aware, and reviewable

Read access and write access should be separate product choices.

A safe initial write path is:

1. Agent creates a workspace draft.
2. A person reviews the content and destination.
3. Matrix checks the destination permission and latest source version.
4. Matrix writes a new file or a new version according to policy.
5. The response ID, version, and link are recorded.

Direct two-way folder synchronization can introduce rename loops, conflict copies, accidental deletions, and ambiguous ownership. It may be appropriate for selected workflows, but it should not be the default abstraction for agent writes.

The first integration slice

For a first OneDrive implementation, we would keep the surface intentionally narrow:

• connect one organization through Microsoft identity,
• select approved SharePoint or OneDrive folders,
• index metadata and supported document text,
• process changes incrementally through Graph,
• materialize selected files into a Matrix workspace on demand,
• generate drafts locally,
• require review before writing to a designated output folder.

Google Drive can follow the same provider-neutral contracts while using Google's scopes, change tokens, and shared-drive semantics.

The result is not “mount every company file into an agent.” It is a controlled bridge between the company's source of truth and the persistent environment where agents work.

That bridge is a core part of the company OS architecture: current context without uncontrolled copying, and useful automation without surrendering permissions or provenance.