Every CRM now says it "works with agents". The difference shows up the first time an agent gets something wrong at 3 a.m. and you are asleep.
These five tests take about ten minutes on a fresh workspace and need nothing but curl and a browser. Run them against whatever CRM you are weighing, with a throwaway key. If one of them needs a workaround, that is the answer.
Test 1: delete 50 records, then get them back
Give the agent's key write access and have it delete 50 contacts in one run.
Pass: you get all 50 back, with their original fields, in one action from the console. No backup restore, no re-import.
Watch for: a "restore" that only brings back the record shell, a trash that empties itself after a few days, and a recovery that only works for deletes and not for fields the agent overwrote. Also check what happens to a record a person edited after the agent touched it: the right answer is that it is skipped and reported, not silently overwritten.
One more thing to try: call the undo with the agent's own key. It should be refused. An agent that can undo (or hide) its own work is not a control.
Test 2: pause one agent while another keeps working
Create two agents with separate keys. Pause one. Fire a read and a write from each.
Pass: the paused agent is refused on its very next call, the other is not affected, and you did not rotate a key or wait for a cache to expire.
Watch for: a single shared integration key (you can only turn everything off), and a "disable" that takes effect minutes later. The refusal should also be readable by the agent: an error that says it is paused and what to do, so a well-behaved agent stops instead of retrying in a loop.
Test 3: read the log and ask whose identity is in it
After tests 1 and 2, open the audit log. Every line should say who acted, which run it belonged to, and what changed, with the record before and after.
Pass: you can tell your agents apart, and an agent from you. The pause from test 2 and the undo from test 1 appear as entries under your name.
Watch for: everything logged as "API user" or a shared integration account. If you cannot attribute a write, you cannot debug a run or explain one to a customer.
Test 4: a contact replies mid-campaign
Draft a follow-up email for a contact, then mark that contact as having replied.
Pass: the unsent follow-up is cancelled, open follow-up tasks are closed, and the contact stays out of further drafts. The cancellation is itself logged.
Watch for: sequences that only stop when the reply arrives through one specific mailbox. Agents mark replies from wherever the reply was found.
Test 5: see exactly what leaves the building
Have the agent draft an email to an outside address, then look for where it goes.
Pass: you can answer "what was sent, to whom, by whom" from the CRM, and nothing is delivered until your policy says so. A dry run that shows what a campaign would send over the next two weeks, before the first real send, is the best version of this.
Watch for: delivery credentials the agent can read or create. If it can, "approval" is a suggestion.
The scorecard
Paste this into whatever you are evaluating:
- One run reverts in one action.
- A paused agent is refused on its next call.
- The log names each agent, each run and each operator action.
- A reply stops the follow-up.
- Outbound mail is visible before it leaves.
An agent-ready CRM passes all five without a workaround. A CRM that passes only two or three still tells you something: which ones it passes shows what the vendor was thinking about when they added the agent endpoint.
Run the tests on a fresh workspace, not your live data. A sixth test that caught something these did not is worth a comment.
Top comments (2)
A sixth one: give the agent no key at all and let it work the CRM through the web UI in a signed-in browser, the way computer-use agents do. Do tests 2 and 3 still hold then, or does every action just log as the person whose session it is?
(I'm on the Auten team. Our agents drive real screens, so that is the case we think about most: the API-side controls only help if the agent goes through the API.)
A rate limit test could be a good addition: what happens when the agent hits the API limit halfway through a bulk update, and can you tell afterwards which records changed?