How to Connect an AI Agent to Your CRM and Existing Tools

You connect an AI agent to your CRM by giving it a small set of defined "tools". Each tool is a piece of code that calls the CRM's API with its own credentials, permissions and checks. The language model never touches your systems directly. It picks a tool and fills in the inputs, and your code decides whether the action runs. Most of the work, and most of the risk, sits in how those tools are designed, scoped and monitored, not in the AI model.

How the connection actually works

An AI agent has three parts: a language model that reasons, a set of tools it can call, and an orchestration layer that runs the loop between them. Say a lead replies to an email. The agent might decide it needs the contact's history, so it asks for a tool such as get_contact_by_email and supplies the address. The orchestration code makes the real API call to the CRM, gets the result and passes it back to the model. The model then decides what to do next.

Each tool is described to the model in a structured way. The Model Context Protocol (MCP) is an open protocol that lets servers expose tools to language models. It defines a tool by a unique name, a human-readable description and an input schema written in JSON Schema. A tool can also declare an output schema so its results can be validated. In practice this means you control exactly which operations exist, which fields they accept and what they return.

Three ways to build the connection

Direct API integration in your own code. You write tools that call the CRM's REST API. This gives you full control over validation, logging and error handling. It is usually the right choice for anything that writes data.
MCP servers. An MCP server exposes tools in a standard format. Any compatible client can find them with a tools/list request and call them with tools/call. This helps when several agents or AI clients need the same tools. Treat third-party MCP servers as code you are trusting with your data. The specification itself tells clients to treat tool annotations as untrusted unless the server is trusted.
Integration platforms and native CRM AI features. These are quicker to start with, but you accept the platform's limits on logic, logging and where data is processed. You also depend on its roadmap.

Step by step: connecting an agent to a CRM

Write down the jobs, not the systems. "Log every inbound call against the right contact and create a follow-up task" is a job. "Connect to HubSpot" is not. Each job turns into a small number of specific tools.
Map the data. List the objects and fields the agent reads and writes: contacts, companies, deals, activities, custom properties. Decide which system is the source of truth for each one. If two systems both think they own a contact's details, the agent will create duplicates or overwrite good data with stale data.
Create a dedicated integration identity. Do not reuse a staff member's login. HubSpot, for example, offers private apps. For each app you choose which scopes, or data types, it can access, and it gets its own access token. Select only the scopes the job needs. Most CRMs offer something similar, such as an API-only user or an OAuth client.
Design narrow tools. update_deal_stage(deal_id, stage) with an allowed list of stages is far safer than a generic update_record tool that accepts any field. Validate every input in code before the API call.
Choose events or polling. Decide how the agent learns that something happened. Webhooks push changes to you as they happen. Polling asks the CRM over and over and uses up your rate limit.
Add approval steps for high-impact actions. Sending external email, deleting records, changing amounts or moving money should either need a human click or pass a fixed rule-based check.
Log everything and test against a sandbox. Record every tool call, its inputs, the result and the model's reasoning. Run the agent against a copy of your data before it goes live.

Permissions: the most important design decision

The OWASP Top 10 for LLM Applications lists "Excessive Agency" as a core risk for systems that can call functions or other systems. OWASP names three root causes:

Excessive functionality: tools that can do more than the job needs, such as an email summariser that can also send messages.
Excessive permissions: credentials with more access than required, such as a database connection with write rights when the agent only needs to read.
Excessive autonomy: high-impact actions carried out with no human check.

OWASP's recommended mitigations translate directly into CRM work:

Limit the tools you expose and avoid open-ended capabilities.
Grant the minimum permissions.
Where possible, run actions in the context of the user they serve, with minimum privileges, rather than through a generic privileged account.
Require human approval for significant actions.
Enforce authorisation in the downstream system itself, not only in the agent.

The MCP specification says the same from the protocol side. Servers must validate inputs, apply access controls, rate-limit tool calls and sanitise outputs. Clients should ask for confirmation on sensitive operations, show tool inputs to the user before calling and log tool usage for audit. The specification also says a human should always be able to deny a tool call.

This is not only a theoretical concern. Any text the agent reads, whether an inbound email, a web form or a call transcript, can contain instructions written to manipulate it. If the agent holds broad write access, a crafted message could lead to changes nobody intended. Narrow tools and permission checks in code limit what a manipulated model can do.

Rate limits, volume and reliability

CRMs cap how many API calls you can make. An agent that looks up context at every step can hit those caps faster than a traditional integration, so check the published limits before you design the agent.

HubSpot applies a short burst limit and a daily limit. For private apps the burst limit is 100 requests per 10 seconds on Free and Starter, and 190 on Professional and Enterprise. Daily limits are 250,000 calls per account on Free and Starter, 625,000 on Professional and 1,000,000 on Enterprise, and they reset at midnight in your account's time zone. Public OAuth apps are limited to 110 requests every 10 seconds per installed account. Go over a limit and the API returns a 429 error that says which limit you hit.
Salesforce sets daily inbound API allocations based on edition and number of licences. These are measured over a rolling 24-hour window, not reset at midnight. Salesforce also caps long-running concurrent requests.

HubSpot's own guidance is to use batch APIs, cache data you access often and use webhooks instead of polling. For agents, this means in practice:

Cache reference data such as pipeline stages, owners and custom property definitions rather than fetching them on every run.
Batch writes where the API supports it.
Retry with back-off when you receive a 429, and queue work rather than dropping it.
Make write operations idempotent, so a retried call does not create a second contact or a duplicate task.
Set timeouts on every tool call, as the MCP specification recommends, so one slow system does not stall the whole agent.

Connecting the rest of your stack

The CRM is rarely the only system involved. A typical agent also touches email, calendars, telephony, a helpdesk, accounting software or an internal database. Each connection follows the same pattern: a dedicated identity, narrow tools, validation and logging. A few extra points apply:

Email and calendars: sending is a high-impact action. Decide up front whether the agent drafts or sends, and from which mailbox.
Telephony: keep the business logic on infrastructure you control. In a voice receptionist we built, the system answers calls on the client's existing phone number. Classification and routing run on our own server, not inside the managed voice platform, so the logic stays ours to change and the platform does not decide how calls behave.
Finance and records systems: a confident wrong write does real damage. Pixelet is a bookkeeping pipeline we built in which several AI models process each entry independently. An entry is accepted only when they agree. The same principle works for any agent writing to a system of record: put an independent check between the model's output and the write.
Legacy or internal systems without an API: these usually need a small service in front of them that offers a few safe operations. Letting the agent query the database directly is the riskier option.

What this looks like in a real build

In an AI sales agent we built, the agent runs outbound prospecting from start to finish. It finds prospects on the web, identifies the owner and their email, writes and sends the email, and replies when the prospect answers. It also schedules each send for the prospect's time zone and reports opens. That is several different kinds of action in one agent: research, writing, sending, replying and reporting. Each carries a different level of risk. Searching the web cannot harm your records, while sending an email in your name can. The same thinking applies when the destination is a CRM. Lookups, activity logging and stage changes should be separate tools with separate permissions, so each can be logged, rate-limited and reviewed on its own terms.

Questions to ask before you sign off an integration

What is the complete list of tools the agent can call, and what can each one change?
Which credentials does it use, what scopes do they have, and who can revoke them?
Which actions need human approval, and where does that approval happen?
How does it behave when the CRM is down, slow or returns a rate-limit error?
Where are tool calls logged, how long are logs kept, and can you trace a CRM change back to the conversation that caused it?
Where does customer data go? Which model provider receives it, and does that fit your GDPR or UK GDPR obligations and your contracts?
Who owns the code, the prompts and the tool definitions if you change supplier?

Build, buy or both

A native AI feature inside your CRM can be enough for simple jobs that stay inside one system, such as summarising records or drafting emails. A custom agent makes sense when the job spans several systems, needs business rules the vendor does not support, or must meet strict audit and approval requirements. Khive builds integrations and custom software in code and hands each system over, so the client owns it. Whichever route you take, the questions above apply.

If you have a CRM and a set of tools you want an agent to work across, send us a brief. Tell us the job you want done, the systems involved and the actions that need a human sign-off, and we will reply with how we would approach it.