What should a buyer ask before letting an AI agent write to a CRM?

An agent that can write to your CRM can also freeze bad data into the systems that already trust it. Wrong owner, wrong stage, wrong account link—once those land, routing, forecasting, and nurture sequences keep moving on the error. Undo is rarely a clean reverse; it is detective work across objects that have already fanned out.

Before you grant write access, insist on three proofs in one controlled dry run. Map every field the agent may touch, including picklists and custom relationships, and force a no-write pass that shows the proposed payload next to the current record. Require an approval gate on ownership, stage, amount, and association fields—everything else can stay semi-automatic if you must keep velocity. Confirm you can roll back by actor and timestamp, not by vague bulk restore.

Ask also who holds the integration identity, whether duplicate rules fire before create, and whether change history tags agent writes separately from humans. The non-obvious risk: a well-mapped agent still teaches reps to trust the feed. When a silent mapping drift later rewrites lifecycle fields, people stop questioning the CRM until pipeline math no longer matches reality—and by then the agent looks innocent because the damage is operational, not dramatic.

Approve CRM write access only when least privilege is provable in logs, not in slides. A buyer should ask which fields the agent may create or update, how source-of-truth mapping is enforced when a contact already exists, and whether every mutation leaves an immutable actor-and-change record that survives vendor UI gloss.

A polished demo cannot prove those controls. It can show a clean form fill and a green success toast. It will not show what happens when match keys collide, when a restricted field is requested, or when support later needs to reverse an automated edit without guessing intent.

Run one implementation move before go-live: in a non-production org, grant the agent a token scoped to a single object and a short allowlist of fields, then attempt a write that (a) targets a near-duplicate record and (b) includes a forbidden field. Accept the integration only if the forbidden field is rejected, the duplicate path is blocked or explicitly resolved by policy, and the change history records agent identity, field-level before/after values, and the decision path. The non-obvious cost of skipping that evidence is operational: incident response inherits unattributed CRM drift that human reviewers cannot reconstruct, so trust collapses after the first bad write—not during the demo.