How to connect an AI agent to your CRM safely

To connect an AI agent to your CRM, first decide which system owns each customer identity, field, stage, activity, task, consent, and file. The agent may read, interpret, and request changes; it must not become a shadow database in chat history or memory. Carry stable record ids and source versions through every tool result. When two systems hold overlays, name which fields are external, which are local, and how conflicts reconcile.

Use a vendor-native agent or connector when it already supports the exact job and permission model. Use an API adapter when you need a narrow stable contract over specific CRM endpoints. Use an MCP server when a compatible AI client should discover and call CRM tools through a standard protocol. MCP improves interoperability, not authorization by itself: the server still needs OAuth or another verified identity, exact scopes, safe schemas, tenant isolation, rate limits, and an owning service.

Create separate capabilities for search or read, draft, approve, create, update, send, delete, export, and administration. Start with the smallest read-only set. Do not expose a generic `run request` tool that can reach every endpoint, and do not let the model select credentials or organization ids. Resolve the signed-in principal on the server, constrain record scope, filter sensitive fields, and require stronger confirmation for bulk, external, destructive, financial, or access-changing effects.

Every tool should accept a closed structured request and return a structured result: record id, expected revision, exact fields, proposed values, reason, source references, idempotency key, and approval state. The CRM service—not the language model—validates required fields, allowed transitions, duplicates, consent, ownership, and current revision. Show a human-readable preview before sensitive commits. Record actor, tool, arguments safe for audit, outcome, and resulting revision without leaking customer data into logs.

Assume timeouts, duplicate delivery, expired OAuth, revoked membership, stale schema, concurrent edits, rate limits, partial provider success, malformed model output, prompt injection in customer text, and an unavailable CRM. Reads can fail clearly; writes need idempotency and reconciliation. Queue unresolved work instead of claiming success, preserve a correlation id, and give a person a bounded way to retry, correct, reject, or roll back. Test disconnect and revocation, not only first connection.

Company Preview includes its own CRM records for organizations, people, opportunities and interactions, plus configurable fields and saved views. To work with an external CRM, use only a suitable supported connection and selected tools. Exact Company membership, granted actions and the connected server's permissions still control each call; a native CRM module does not certify universal one-click provider integration. Start with one read or draft tool, identify which system owns each record, and verify both the result and revoked access before adding writes.