An AI agent updated our CRM. How do I prove exactly what changed?
Prove it from the write steps: when CRM updates run as recorded steps, each change is a step carrying the record touched, the fields changed with their before and after values as references, and the instruction the change answered. Review the receipt and actual deliverable before accepting a handover.
CRMs accumulate agent touches quietly: enrichments, stage moves, note appends, deduplications. Each is small; the aggregate is your pipeline's memory being edited by software, and the first time it matters (a deal that vanished from a stage, a contact merged wrongly, a customer who received the wrong follow-up) the question is always the same and always urgent: exactly what changed, when, and on whose instruction.
The recorded-write pattern answers from structure. A write step names the CRM object and the fields it changed, references the before state, and sits under the job and instruction that authorised it. Reads can be logged more lightly; writes are the consequential class, and they are gated accordingly, the same consequence-based rule the customer-data page in this set applies. Rollback conversations change too: instead of debating whether the agent "probably" moved a deal, the team reads the step, sees the before values, and restores precisely.
Retrofitting history is the honest limit: changes already made unrecorded can only be reconstructed from the CRM's own audit features, where they exist, and from exports. The discipline starts with the next write. Teams usually adopt it the week after their first unanswerable CRM question, which is a fine week, and adopt it cheaper the week before.
Checklist: recorded CRM writes
1. Writes as steps: every agent change to the CRM is a recorded step; no direct unrecorded write path for agents. 2. Step contents: CRM object, fields changed, before values as references, the job and instruction above the step. 3. Gates: bulk changes and deletions require a recorded human approval step first. 4. Review view: filter steps by date range, object, agent, or field; the weekly ops review samples it. 5. Restore drill: pick one changed record per quarter and restore its before state from the record, timed. 6. Legacy note: pre-discipline changes are marked as reconstructed where CRM audit data supports it, and as unknown where it does not.
Worked example
The approval gate's shape is the decision layer on any accepted record, for example https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 , where a human decision sits on the work itself. For CRM bulk changes, that decision step sits before the writes execute, which is the difference between authorising a change and discovering one.
Frequently asked questions
Our CRM has its own audit log. Is that not enough?
It is a real asset and the first place to reconstruct from. Its limits are attribution and context: platform audit logs usually show a user or an integration changed a field, not the instruction, job, and reasoning above the change, and they rarely survive platform migrations. The recorded step carries the why with the what.
Does recording slow the agent down?
A write step is saved as the write happens; the cost is negligible against CRM API latency. What it removes is the unbounded cost of the first unanswerable change, which is paid in days, not milliseconds.
What about changes agents make through the CRM's own automations?
Treat automations as agents for this purpose: their rule changes are versioned decisions, and their executions belong in the same step record, labelled with the automation that ran. An automation nobody records is an employee nobody supervises.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai