How to connect an AI agent to your CRM?
The connection is the easy half. Deciding what the agent may change is the half that goes wrong.
Answered in short
5 things that decide this
- 01Give the agent its own service account in the CRM, never a staff member's login, so its actions are separable in the audit log.
- 02Run read-only until the agent has been wrong in public at least once and you have seen how it fails.
- 03Scope permissions to the specific objects and fields the task needs, rather than granting a broad admin role for convenience.
- 04Log every write with the record id, the field, the old value and the reason, because an agent that cannot be audited cannot be trusted with a customer record.
- 05Put a human approval step in front of anything that contacts a customer or changes money.
The CRM is a record of truth, not a scratchpad
A CRM is where your commercial history lives. Renewal dates, contacts, deal stages, the note explaining why a client nearly left in March. An agent writing into it carelessly does damage that is slow to spot and awkward to reverse.
The usual first mistake is authentication by convenience. Somebody hands the agent an admin API key, because that is the key that works. Now every action the agent takes is indistinguishable from a person, and the blast radius is the whole database.
The second mistake is trusting a confident summary. An agent that reads a call transcript and updates a deal stage is making a judgement, and it will sometimes make it badly. Without a log of what changed and why, you find out weeks later from a confused salesperson.
- GoLancer runs a client CRM alongside Stripe invoicing and AI daily priorities, so we have built this boundary in production.
How to roll it out without breaking your pipeline
Begin with reading. Let the agent summarise, draft and suggest for a few weeks while a person applies the changes. You learn its failure shape at no cost.
Then allow writes to fields nobody sells on. Internal notes, tags, enrichment data. Leave deal stage, owner and forecast alone until the log shows the agent is boring.
Give it an identity of its own. A dedicated service account lets you filter the audit trail to just the agent and revoke it in one action. It also answers the question your finance team will ask about who changed a number.
Keep a reversal path. Store the previous value with every write, so undoing a bad run is a query rather than an archaeology project.
- Anything that emails a customer or moves money gets a human in front of it. That is not caution, it is the difference between an error and an incident.
- Service accountIts own identity, not a person's.
- Scoped fieldsOnly what the task needs.
- Read-only phaseWatch it be wrong cheaply.
- Logged writesOld value, new value, reason.
- Human gateCustomer contact and money.
- ReversalUndo is a query, not a rescue.
Most teams start at step four. The first three are what make step four survivable.
Related questions
01Should the agent write directly or raise a suggestion?
Raise suggestions until the audit log is dull. Direct writes are appropriate for low-stakes fields once you can see a clean history of what the agent has been doing. Deal stage and anything a forecast depends on deserve a human for longer than teams expect.
02What if our CRM has a weak API?
Constrained APIs push you toward batch syncs and a staging table, which is slower but often safer. The agent writes proposals into a queue your CRM ingests on a schedule. That queue also gives you the audit trail the CRM itself may not provide.
03How do we stop the agent creating duplicate records?
Match on a stable key before every create, and make the create step refuse when confidence is low. Duplicate contacts are the most common damage an eager agent does. Near-matching names look identical to a model and obviously different to your sales team.
