Skip to main content
CRM writes are dangerous when state drifts between the time the agent resolves a customer record and when the write executes. Invoke verifies identity before the write lands.

The problem

Your agent resolves cust_123 at plan time. Between plan and execution, the record changes — the account is reassigned, merged, or the customer ID updates. Without state verification, the write hits the wrong entity.

Solution: state verification before write

Use POST /state/verify to confirm the customer record matches assumed state before executing the CRM update:

What Invoke checks

Before the CRM write executes, Invoke compares:
  • Customer ID — is the resolved entity still the same record?
  • Account status — has the status changed since the agent planned the action?
  • Required fields — are all fields the agent depended on still current?
If any condition fails, Invoke returns replan_required and the write never lands.

Direct API call

Here customer_id drifted from cust_123 to cust_999 — Invoke blocks the write.

Next steps