6 Things Your CRM Needs Before an AI Agent Touches It

The agent isn't the hard part

Getting a model to read a call transcript and summarize it takes an afternoon. Getting that summary onto the right contact, with the right owner, in a CRM where the contact exists once and the owner still works there, is the actual project.

An agent has two connections to your business: what it reads and what it writes. Both go through the system of record. If the record is wrong, the agent is confidently wrong at scale. That's why we audit the stack read-only before any AI build, and why most AI engagements start with CRM work that has nothing to do with AI.

Here are the six checks the audit runs. Score yourself as you go: each one is a yes or a no.

1. One record per real thing

An agent looking up a caller needs to find one contact, not three. If your CRM has duplicates, the agent either picks one at random or asks a person every time. Neither is useful.

Check: Pull the contact and account counts. Search for the same email or phone number across records. If you find the same customer twice more than a handful of times, the agent will too.

What we do about it: Merge rules by field, not by hand. Match on phone and email first, then name plus address. Dry-run the merge, review the results, then commit. At a direct-to-consumer brand that meant about 5,400 duplicates merged, with a rollback log for every one, before a single automation was switched on.

2. Fields that mean what they say

An agent writing a lead source, a stage, or a status has to pick from values that are actually used. Every CRM we audit has a picklist with "Other" as the most common value and a stage nobody has moved a deal into since the last admin left.

Check: For each field the agent will write, count the distinct values in use. Look at the last-modified dates. If a value hasn't been set in a year, it's dead.

What we do about it: Retire the dead values and document what each live one means in a sentence. The agent gets that sentence as its instruction. The people using the CRM get it too, which is usually the first time anyone wrote it down.

3. An owner who still exists

Agents route. A new lead goes to a rep, a service request goes to a queue, an escalation goes to a manager. Every route ends at a person or a queue, and in most orgs some of those people are gone.

Check: List every active assignment rule, round-robin, and default owner. Cross-reference against active users. Count the records owned by deactivated users.

What we do about it: Reassign by rule, fix the defaults, and put a guardrail on the agent so it never writes to a deactivated owner. Route to a queue instead and let a human pick it up.

4. Automations you can name

The agent writes a record. That write fires your existing automations. If nobody can list what fires when a lead is created, nobody can predict what the agent will trigger.

Check: Inventory every flow, trigger, and workflow rule on the objects the agent touches. Note which ones send email or text, because those are the ones that reach customers.

What we do about it: Turn off the dead ones. For the live ones, decide whether an agent-created record should fire them. Often it shouldn't. A record the agent created at 2 a.m. from a voicemail should not send the "welcome" sequence until a person confirms it's a real lead. And make the live ones fail loudly: a run that fails should alert and keep the record, not drop it silently. That matters more once a model is creating records.

5. A place for the agent to be unsure

This is the one most teams skip. The agent will hit inputs it can't read. A voicemail in another language. An intake form listing two medications that contradict each other. A lab PDF with a marker the schema has never seen.

If the agent has nowhere to put "I'm not sure," it guesses. If it has a queue, a person handles the exception and the record stays clean.

Check: Does the object have a status value and a queue for "needs review"? Does anyone look at it?

What we do about it: Every agent we've built has a confidence score and a rule for what happens with it. Sometimes the rule is a threshold: above it the write happens and is logged, below it the record goes to a review queue with what the model saw attached. Sometimes the rule is that a person confirms every one. The clearest example is practitioner matching in the wellness-plan platform we built: the model proposes a methodology match with a confidence score, a rule with no model calls ranks the practitioners, and staff confirm every match before a plan is generated. The score is on screen for the reviewer. It never decides alone.

6. A way back

Agents write fast. If the prompt is wrong or the source data shifted, the agent can create or update a large number of records before anyone notices.

Check: Can you find every record the agent touched in the last 24 hours? Can you undo the change?

What we do about it: Tag every agent write with a source and a batch. Keep a rollback for each batch. We hand off with rollback on every build, and for agent writes it's not optional.

Your score

Count the yeses.

• 6 of 6: Your CRM is ready. The AI build is the whole project.
• 4 or 5: Normal. Expect CRM work before the agent, and budget for it up front instead of discovering it partway through the build.
• 3 or fewer: Don't start with an agent. Start with the record. An agent on top of this CRM will be blamed for problems it didn't cause, and it'll get switched off.

If you run Salesforce, the Org Health Checklist scores the first four of these in more detail, across 30 items, and gives you a report to keep.

Where to start

None of this is AI work. All of it decides whether the AI works.

The read-only audit runs the six checks against your actual CRM and puts the counts in front of you before anything changes. That's where every AI engagement we take on starts, and it's the part we'd recommend even if you build the agent with someone else. Ask for the audit and we'll tell you what it covers and what it costs before you commit to anything.