Agent Memory Ingestion: Connectors, Freshness, and Permissions
Design a reliable path from workspace documents to agent answers, with explicit checks for synchronization lag, authorization, retries, and deletion.
A connector makes source content available to your agent. It does not, by itself, prove that the content is current or that the person asking a question may see every imported document.
For enterprise agents, design ingestion and retrieval together. Every document needs a stable identity, a source version, a retrieval scope, and a way to become unavailable after deletion or a permission change. This applies whether a managed connector handles synchronization or your team writes the integration.
How do you connect Google Drive or Notion to agent memory?
Use the provider's documented authorization flow, select the intended source content, associate it with an authorized application scope, and verify that ingestion has completed before querying it. Supermemory documents Google Drive and Notion connections. Provider-specific setup still matters: completing OAuth does not prove that every intended file has been selected or processed.
Start with one document and three checks: retrieve its current content, change it and observe the update, then revoke access or delete it and verify the intended removal. Treat automatic synchronization and live source lookup as different behaviors. The memory lifecycle guide explains why a removed search result is only one part of deletion.
Choose how updates enter the system
Three patterns solve different problems:
| Pattern | Useful when | Failure to handle |
|---|---|---|
| Webhooks | The source can notify you about changes | Duplicate, delayed, missing, or out-of-order events |
| Scheduled polling | The source exposes a change feed or incremental listing | Expired cursors, rate limits, and time between checks |
| Fetch on demand | A task needs current information from a known source | Source availability and request latency during the task |
These patterns can coexist. For example, use webhooks for prompt updates and periodic reconciliation to find changes that were missed. A query can search an index and then fetch the authoritative record before acting on a consequential field.
A connector can use webhooks and still serve searches from an indexed copy. Avoid treating “connected” as a synonym for “read live on every query.”
What Supermemory connectors do
Supermemory documents automatic ingestion from connected sources, with synchronization mechanisms that vary by provider. Its connector overview describes webhooks, scheduled sync, and manual sync; this is a synchronization pipeline, not a universal promise that each search calls the original source. It also documents a choice between removing a connection with its imported documents and disconnecting while retaining them. Connector behavior and lifecycle.
For Google Drive, new scoped connections use a file and folder picker. Imports can wait until the user completes that selection. Full-Drive synchronization is a separate configuration choice. A successful OAuth callback therefore does not establish that the intended documents are already searchable. Google Drive setup.
Check the documented provider list before promising a native integration. For a source such as Slack that is not listed there, validate the supported ingestion route separately; an application built with the API is different from a documented managed connector.
Keep identity separate from version
Consider a support policy document that changes three times. You want one source identity with traceable versions, not three indistinguishable policies competing in retrieval.
A useful application-side record contains:
| Field | Purpose |
|---|---|
| Source provider and resource ID | Identify the original document independently of its title |
| Tenant or user scope | Tie ingestion to the authorized application context |
| Source version or modification time | Recognize new changes and reject stale updates |
| Ingestion status and completion time | Distinguish accepted work from searchable content |
| Source URL | Let a person inspect the underlying evidence |
| Access state | Represent whether the document remains eligible for retrieval |
This is an application design example, not a required Supermemory API schema. Map it to the actual fields supported by your chosen endpoint.
Use stable identifiers to make retries safe. If two versions arrive out of order, avoid letting the older event overwrite the newer state. When a provider does not offer a reliable version counter, design an explicit reconciliation policy instead of assuming arrival order equals edit order.
Enforce permission changes after ingestion
The account that imports a document and the person asking the agent a question may be different. OAuth limits what a connection can obtain; your application still needs a retrieval policy appropriate to its users.
For a personal assistant, a user-specific scope may match the product boundary. For a shared workspace agent, a workspace-wide collection may contain documents with different audiences. The design must account for that difference through separate scopes, supported permission filters, source checks, or another tested access-control mechanism.
Run a revocation test: ingest a document, verify an authorized user can retrieve it, remove that user's access, and repeat the question. Also try direct document lookup and cached answers. Search passing the test is insufficient if another route still exposes the text. See multi-tenant memory isolation.
Measure freshness through the whole pipeline
Record when a source change happened, when the integration observed it, when processing completed, and when retrieval first returned the new version.
For example, a hypothetical policy edit at 10:00, observed at 10:02 and searchable at 10:05, has five minutes of end-to-end lag. Reporting only the final three minutes hides the detection delay. Measure distributions across representative documents, including failures and retries.
Define the acceptable lag from the product's needs. A research assistant and an agent applying an account restriction may need different freshness guarantees. When the latter needs current business state, query the authoritative application rather than treating remembered text as the final authority.
Test disconnects, deletion, and recovery
Before expanding a connector rollout, exercise these cases:
- Replay the same event. Confirm it does not create duplicate knowledge.
- Deliver an older change after a newer one. Confirm the current version remains current.
- Revoke source access. Check search, document lookup, profiles, and cached answers where applicable.
- Delete a source document. Verify the intended downstream behavior, including derived memories.
- Disconnect the integration. Confirm the chosen policy for previously imported material.
- Expire credentials or interrupt ingestion. Confirm a visible error and a recoverable checkpoint.
- Restore processing. Confirm the integration catches up without silently skipping changes.
Keep one small collection as a regression fixture and run these checks when connector settings or permissions change. Start with a supported source and a clearly bounded audience, then expand after freshness and access behavior are demonstrated. Use the connector documentation for setup and the memory debugging guide when accepted content fails to appear in answers.
For uploaded files, use the persistent knowledge-base workflow to track source identity, accepted revisions, and readiness.
For the related implementation, see Supermemory with Zapier: Scoped Ingestion and Reliable Retries.
For the related implementation, see Supermemory with n8n: HTTP Workflows, Identity, and Readiness.
Start with one source your team already uses. Open the Supermemory console and follow the supported connector setup linked above, then run a small sync, revision, and permission-change test before importing the rest of the workspace.