How to let an AI agent work in your CRM without breaking it

Jordan Tate — Mon, 02 Nov 2026 16:53:44 +0000

An AI agent that can read your CRM is useful. An AI agent that can write to it can also merge the wrong contacts, move deals nobody asked it to move, and text a lead at 11pm.

So don't start by giving the agent everything. Treat it like a new hire: limited access, small jobs, and someone checking the work. (Disclosure: I work at a CRM company, and I use our product for the examples below.)

Here's the order that works, whichever CRM you use.

1. Give the agent its own API key

Don't hand it an admin key or your personal one. A separate key gets you three things:

You can see which changes came from the agent.
You can scope it to what the job needs.
You can revoke it without logging your whole team out.

If your CRM only offers one all-powerful key, treat that as a real limit and keep the agent read-only through your own proxy until it doesn't.

2. Start read-only

Give the agent read scopes for a week or two and make it prove itself on jobs where a mistake costs nothing:

Summarize a contact's history before a sales call
List deals that haven't moved in 14 days
Find contacts with missing fields
Draft (don't send) a follow-up

You'll learn more from this than from any demo, including how messy your data is, because an agent repeats your mess back to you with confidence.

3. Use MCP if your CRM has it

Model Context Protocol gives an agent a typed list of tools instead of a pile of API docs. The agent can see what exists and what parameters each tool takes, so it guesses less.

Setup is usually a few lines of config. This is the shape for Claude Desktop, using our own server as the example:

{
  "mcpServers": {
    "conduyt": {
      "command": "npx",
      "args": ["-y", "conduyt-mcp"],
      "env": {
        "CONDUYT_API_URL": "https://conduyt.app",
        "CONDUYT_API_KEY": "cdy_your_key_here"
      }
    }
  }
}

Keep the key in the env block or a secret manager, not in a prompt. Check what the server exposes before you connect it. Ours has a conduyt_check_permissions tool that reports what the current key can do, which is a good first call for any agent. If yours has nothing like it, have the agent try a harmless read and a harmless write, and confirm the write is refused.

4. Decide which writes are safe, then widen slowly

Not all writes carry the same risk. A rough ladder:

Risk	Examples	Suggested handling
Low	Add a note, create a task, add a tag	Let it run, review weekly
Medium	Update a field, move a deal stage	Let it run on rules you wrote down, spot-check daily
High	Merge or delete records, bulk changes	Human approval every time
Customer-facing	Send an email or text	Human approval until you trust it, and always check consent and opt-outs

The last row is the one that hurts. A bad field update is a cleanup job. A bad text to a lead can be a compliance problem, and in the US that includes 10DLC registration and opt-out rules. Sending stays with a human longer than anything else.

5. Look for guardrails built for concurrency

Agents are fast, and they act on data that may be seconds old. Two things to check in your CRM's API:

Conflict detection. If a rep edits a deal while the agent is working from a stale copy, does the write fail or silently overwrite the rep? Look for revision or version checks. In our API, some writes accept an expectedRevision and return a 409 if the record changed underneath you. Whatever your CRM calls it, you want that behavior, and you want the agent told to re-read and retry rather than force it.

Two-step destructive actions. Our merge tool won't run on the first call. It's marked destructive and asks for a confirmation of the impact first. If your CRM has no equivalent, wrap destructive calls yourself and require a human yes.

6. Write the rules down where the agent can read them

An agent can't follow a rule that only exists in someone's head. Put them in the system prompt or a shared doc:

Which pipelines it can touch
What "stale" means here
Who to assign new tasks to
When it must stop and ask
What it should never do

Short and specific beats long and general.

7. Check the work on a schedule

Pick a time each week to read what the agent changed. If your CRM keeps a timeline or audit trail, use it. If mistakes keep falling, widen its access. If they aren't, fix the rule or narrow the scope.

Where to start on Monday

Create a separate read-only key.
Connect it through MCP or a small script.
Ask it one question you already know the answer to, like "which deals over $5,000 haven't moved in two weeks?"
Compare the answer with what you know.

That last step tells you whether your agent, or your data, is ready for more.

If you want to see how the tool side looks in practice, our MCP server page lists what an agent can do in Conduyt. The steps above work with any CRM that has an API.

Jordan Tate is VP of Customer Relations at Conduyt, a flat-price CRM for small sales teams. This post was drafted with AI assistance.

DEV Community: Jordan Tate