Technical

How we think about giving an AI agent access to your CRM

A voice agent that can only talk isn't that useful on its own. The real value shows up once it can look something up or write something back mid-call, which means giving it scoped, auditable access to your CRM.

· 2 min read

A voice agent that can only talk isn't especially useful for most businesses beyond answering a handful of static questions. The real value shows up once it can look something up mid-call or write something back, like checking an order status or updating a contact record while the caller is still on the line. That means giving it access to your CRM, which understandably makes a lot of people nervous the first time it comes up in a planning conversation.

The two connection types

For Salesforce and Zoho, we use native connectors with live schema discovery. That means the agent reads your actual field structure directly from your instance, including any custom fields you've added over the years, instead of assuming a generic setup that doesn't match how your team actually uses the system. This matters more than it sounds, since most CRM instances after a year or two of real use look quite different from the default template.

For everything else, meaning any system outside Salesforce and Zoho, the connection is configurable REST tools. You define exactly what endpoint the agent can call, what data it's allowed to read, and what it's permitted to write. Nothing happens outside of what's explicitly configured by your team ahead of time, and there's no default fallback that grants broader access than you intended.

What we deliberately don't do

The agent never gets open-ended access to your whole database. Every single action it can take during a call is a defined, scoped tool with defined boundaries. If you don't configure a delete record tool, the agent cannot delete records, full stop. This isn't a permissions toggle buried somewhere in a settings menu that someone could accidentally leave open, it's simply not a capability that exists unless your team deliberately builds it in as part of the configuration.

What this looks like in an actual call

A caller asks about their order. The agent calls a lookup tool, retrieves the order status, and reads it back to the caller in plain language. If the caller wants to update their shipping address, that's a separate, explicitly defined write action with its own scope and its own logging. Every one of these calls is recorded, so there's a complete audit trail showing exactly what the agent did during any given call, not just what it said.

Why this approach matters for trust

The goal is an agent that's genuinely useful because it can take real action on a caller's behalf, without turning your CRM into an open door that anyone with access to the voice platform could exploit. Scoped access with a full audit trail gives your team the ability to actually verify what happened on any call after the fact, rather than just trusting that everything went fine because nobody complained.

Frequently asked questions

Can the AI agent access every field in our CRM?

No. Native connectors read your actual schema including custom fields, but the specific tools available to the agent during a call are explicitly configured, not open-ended.

What stops the agent from making unauthorized changes to records?

Every write action is a separately defined, scoped tool. If a specific action like deleting a record isn't configured, the agent has no way to perform it, regardless of what a caller asks for.

Is there a record of what the agent actually did during a call?

Yes. Every tool call the agent makes, whether a lookup or a write action, is logged, creating a full audit trail for that call.

See it on one of your own call flows

Bring one workflow. We will configure it, validate it with controlled test calls, and show you the whole system around it.