The agent answered from company files yesterday. Today the connector receives an invalid delta token, records a failed sync, and keeps serving yesterday's index. Users see a healthy-looking answer with no sign that recent changes are missing.

A delta token is a provider's change-tracking position, and the client cannot always resume from it. A Microsoft Q&A question about invalid drive delta tokens asks when a full resync becomes necessary, and Microsoft's delta query overview describes recovery conditions. Token lifetime differs by resource, and an invalid token is not always an expired one, so do not generalize one resource's behavior to every connector.

Separate freshness from availability#

An index can be available while synchronization is unhealthy, so track both states. "Search returned results" says nothing about whether the index reflects the latest provider state.

Track the last completed synchronization, the current baseline generation, the source scope, and the age of the oldest unresolved gap. Use them to decide whether the agent can answer a current-state question or must report missing evidence. A user asking for last year's architecture note can accept an older index, while one asking whether someone still has access needs current evidence.

Rebuild a baseline deliberately#

Take a document connector offline long enough for its change position to become invalid. Repeating the rejected token does not advance the sync, so the connector needs the provider's documented resynchronization path.

Build the replacement baseline under a new generation identifier:

Keep the original source scope and identity.
Enumerate all required pages.
Apply the provider's deletion semantics.
Make the replacement durable before promoting it as current.

Do not clear the searchable index at the start of the rebuild unless the access policy requires immediate removal, because clearing first turns a recoverable freshness problem into an availability outage. Equally, do not keep serving content whose permission was revoked because the replacement baseline is incomplete. Access decisions need their own conservative handling.

For drive content, Microsoft's drive delta documentation explains delta and deleted-item behavior.

A replacement is more than a successful first page#

Suppose the old baseline contains documents A, B, and C. During the outage, B is deleted and D is created. A partial rebuild returns A and D before the next page fails, and promoting it loses C, keeps B, or both, depending on the merge.

A safer rebuild tracks explicit generation membership. Only after the full baseline completes does the connector find which indexed objects are absent from the new scope, apply removals, and promote the generation.

Recovery stage	Evidence needed before advancing
Invalid token detected	Provider error and affected scope
New baseline started	Fresh generation and original identity
Pages collected	Durable objects and continuation position
Baseline complete	Provider completion marker
Replacement promoted	Membership and deletion reconciliation
Incremental sync resumed	New change position successfully used

Explain the degraded period honestly#

While rebuilding, attach a specific freshness status to answers that depend on the affected source: "The file index last completed synchronization at this time; later changes are not reflected." Do not imply every retrieved document is wrong, and do not present an old answer as current because its citation opens.

If a current fact is essential, fetch the authoritative object directly over the existing permitted connection. Use this as a fallback for one question, not a second synchronization engine with different access rules.

Keep the recovery test small and difficult#

Use a fixture with a deleted item, a renamed item, a newly created item, and a permission change during the gap. Interrupt the rebuild after a page and verify that restart does not promote a partial baseline, then that the next incremental request uses the replacement generation's token.

Record the failed token's resource scope and the chosen recovery method in the connector's operating instructions, and return a clear source status to the agent while the connector owns token recovery. Use connection health to investigate the source and action evidence to trace the reads involved. Recovery is complete when the new baseline is usable, change tracking has resumed, and the stale interval stays visible in history.