The agent changes an account owner, searches for the account, and sees the old owner. It tries the update again.

The read-back used a delayed search index and not the object that accepted the update. A public Microsoft Q&A question about eventual consistency describes a recently changed resource not immediately behaving as expected. Diagnose the read path before deciding the write failed.

Distinguish acceptance from visibility#

A write response, a direct object read, a search query, and a user interface observe different stages of propagation. Establish which path your provider documents as authoritative.

Microsoft's advanced directory query documentation describes an eventual-consistency requirement for certain queries, and not every Graph read behaves that way. Read the documentation for your exact endpoint and query.

Capture the returned object identifier and version information from the write, and verify with them instead of searching by display name, which adds indexing delay and identity ambiguity when you need a precise check.

Verify one owner update#

Take a CRM operation that changes account A-19 from owner U-4 to U-8. The provider returns success and the account identifier, and the agent's next tool searches all accounts named "Northstar" and finds a cached copy owned by U-4.

The verification routine reads A-19 through the provider's documented object path and inspects the owner field. If the direct read shows U-8 while search still shows U-4, report the change as confirmed with search propagation pending.

If the direct read also shows U-4, keep checking within a fixed verification window suited to the provider and do not issue another write. Preserve the original response and request identifier so the integration owner can reconcile if visibility never converges.

Evidence	Interpretation	Next step
Write rejected	Change not accepted	Correct the failure before retrying
Write accepted, direct read matches	Intended state confirmed	Complete or check downstream effect
Direct read matches, search differs	Projection lag	Avoid duplicate write
Direct read differs within expected delay	Verification incomplete	Recheck within the window
Another actor changed the object	Concurrent update	Compare versions and intended outcome
Verification deadline expires	Outcome requires investigation	Preserve evidence and report uncertainty

Do not erase someone else's newer update#

A read-back mismatch can be a real concurrent change. Suppose a human assigns U-9 after the agent assigns U-8. Repeating the old update overwrites the human's newer decision.

Use version preconditions when the provider supports them. During reconciliation, compare the observed version with the version returned by the original write. If another actor changed the object, report the conflict and evaluate the request against the new state before changing anything.

"Retry until the field matches" is therefore an unsafe verification strategy: it combines observation with mutation and forces an obsolete intention onto a changing system.

Verify the outcome the user requested#

Sometimes the field change is an intermediate step: assigning an account owner can require a notification or a downstream routing update. Decide which effects belong to the user's request and which are provider behavior outside the completion condition.

Do not claim downstream success from the source-field update alone, and do not expand a field update into an audit of every consumer. Check the explicit outcome through one relevant path. The guide to result verification covers the broader completion distinction.

Test delayed visibility on purpose#

A fast test environment never exposes propagation delay. Use a fixture where the write succeeds immediately, direct reads lag for a fixed interval, and search lags longer. Assert that the agent does not resubmit the write while verification is pending.

Add a concurrent update after the original success and verify recovery preserves it. Include a permanent mismatch to prove the routine stops and reports the unresolved result.

Put the observation path and verification deadline in the connector's action contract so every caller checks the same evidence. Deixic's action lifecycle and evidence guidance show how to inspect the request and result.