Keeping Your Carrier on Agentforce: BYOT for Salesforce CTI Agents

Most contact center teams that start evaluating Salesforce Agentforce for voice AI spend the first few weeks focused entirely on the agent logic—the flows, intent detection, and CRM integration. What tends to surface later, usually around the time someone from IT asks about the telephony stack, is that the question of which carrier handles the actual call routing was never answered. If your organization has spent years negotiating rates, building redundancy, and fine-tuning compliance controls around a specific telephony provider, the prospect of swapping that out to run Agentforce is—putting it plainly—not a trivial consideration. Agentforce AI voice agent integration changes that calculus entirely. With bring-your-own-telephony compatibility, organizations can explore Agentforce voice capabilities without necessarily replacing the telephony infrastructure they have already invested in. It's a capability that deserves far more attention than it typically gets in the early sales cycle.

Worth flagging here: this article isn't going to tell you that BYOT is right for every deployment. That's not how infrastructure decisions actually work. Whether it's the right call depends on a number of things specific to your environment, your carrier contracts, and how your compliance team is going to react to any proposed change in how voice traffic is handled.

What Actually Changes When You Connect an Existing Carrier

Agentforce, at its core, is designed to support autonomous AI agents that can take actions, handle conversations, and operate across channels—voice included. The telephony layer sits beneath that. Salesforce's native approach connects through its own voice infrastructure, while BYOT configurations allow organizations to bridge an existing carrier or contact center platform into the Agentforce environment using SIP or an established CTI adapter. For organizations exploring implementation details, a salesforce cti integration guide can help clarify how these connectivity options fit into the broader Agentforce architecture.

The practical consequence of this is that the voice traffic - the actual packets, the routing logic, the trunk configurations - stays with your carrier. Agentforce handles the agent behavior, the CRM reads, the action triggers. What doesn't move is the carrier relationship, the DID portfolio, and the compliance tooling your network team has already built around it.

Honestly, for organizations that have spent meaningful time getting their telephony infrastructure right, that's not a small thing.

BYOT Salesforce Agentforce - How the Architecture Actually Sits Together

The Salesforce CTI architecture varies somewhat depending on which CTI platform you're already running, but the general shape of it is consistent. An Open CTI adapter—Salesforce's API layer for connecting third-party telephony—acts as the bridge. Your carrier or contact center platform handles signaling and media, while Agentforce sits on top, operating through the Service Cloud Voice framework when voice channels are in scope.

Here's what tends to get underestimated in early scoping conversations:

• The adapter layer is where most of the configuration work actually lives. Getting the SIP trunk or CTI connector built and stable is often the heavier lift compared to configuring the Agentforce agents themselves. Teams that plan for two weeks of integration work sometimes find themselves in month two still resolving audio quality and failover issues.
• Not every carrier supports the same connection options. Some of the major contact center platforms - Genesys, Avaya, Five9, NICE CXone - have published or partner-supported connectors for Salesforce. Others require more custom work. The distance between "technically supported" and "actually working in your environment without heroics" tends to be something nobody warns you about until you're already in it.
• Compliance tooling may need to be extended, not rebuilt. If your existing telephony stack includes call recording, PCI-scoped call pause/resume, or TCPA consent controls, those usually need to be explicitly mapped into the new configuration. They don't migrate automatically, and assuming they do is a failure mode that shows up during audit cycles, not during testing.

One more thing worth naming directly: the latency implications of adding an AI agent layer on top of an existing carrier connection are real. Milliseconds matter in voice. Deployments that don't performance-test under realistic concurrent call loads tend to discover this later rather than earlier.

What You Actually Keep - and What Still Changes

Element	BYOT Approach	Native Salesforce Voice
Carrier relationship	Maintained - existing provider stays	Shifts to Salesforce/Amazon Chime
DID/phone number portfolio	Retained as-is	Migrated or replaced
SLA and uptime accountability	Your carrier's existing SLA applies	Salesforce Voice SLA applies
Call recording infrastructure	Your carrier's tooling (may need bridging)	Service Cloud Voice recording
Compliance controls (TCPA, PCI)	Existing controls - may need extension	Built within Salesforce config
Agentforce agent capabilities	Full access	Full access
CRM integration	Full Salesforce native	Full Salesforce native

That compliance controls row - TCPA, PCI, all of it - is genuinely the one that slows procurement down the most. Legal and compliance people tend to have real feelings about where recordings end up sitting and exactly which vendor can get eyes on them, so that conversation is worth having earlier than feels necessary, not later. It's also a big part of the Salesforce CTI security and compliance conversation, especially when you're evaluating how call data and recordings are handled.

Why "Keep Salesforce as the Existing Carrier" Is Genuinely a Strategic Question

The phrase keep existing carrier Salesforce sounds like a technical preference, but it often reflects something more layered - contractual obligations, geographic routing requirements, regulatory jurisdiction, or just the operational reality that the carrier has been tuned for your call volume over years and the institutional knowledge around it doesn't transfer easily.

To be fair, some organizations find that evaluating the carrier relationship is actually a useful forcing function. If the telephony infrastructure hasn't been reviewed in three or four years, the BYOT decision process has a way of surfacing costs and redundancies that were just sitting there quietly.

But that should be a deliberate choice, not something that happens because the Agentforce rollout pushed the question to the surface. The organizations that handle this well tend to separate the AI agent evaluation from the carrier evaluation - running them as related but distinct workstreams rather than collapsing them into a single implementation sprint.

Framework for Deciding Whether BYOT Is the Right Path

There's no universal answer here, but there are patterns in the organizations that tend to get the most out of BYOT configurations.

1. Existing carrier contracts with significant remaining term - If you're twelve months into a five-year agreement with meaningful volume commitments, the cost of unwinding that is real and often underweighted in ROI models for new platform deployments.
2. Regulatory environments where carrier provenance matters - Financial services, healthcare, and government-adjacent deployments sometimes have requirements about which carriers can handle specific call types. Not universal, but worth a compliance review before assuming the native Salesforce voice path is available.
3. High-volume environments with existing quality tuning - A contact center running several hundred concurrent calls that has spent time optimizing codec selection, jitter handling, and failover routing is sitting on operational knowledge that doesn't transfer automatically. The time cost of rebuilding that on a new carrier path is usually higher than planners expect.
4. Organizations with mature CTI integrations already in place - If agents are already working inside a Salesforce CTI softphone environment, layering Agentforce into that existing connection is often technically cleaner than migrating the whole stack.

The Agentforce BYOT Decision Isn't Just a Telephony Call

Worth noting: the decision to use Agentforce BYOT ends up being as much a procurement and vendor management question as a technical one. Your carrier, the CTI platform vendor, Salesforce, your internal network team - each of them has a real stake in how the connection gets designed, who's on the hook for each SLA layer, and frankly who picks up the phone when something breaks in production and nobody can immediately tell whose layer it broke in.

That multi-vendor accountability structure is where deployments that look clean on paper can get complicated quickly. Nobody is going to volunteer to own the problem if there's a gap between the carrier layer and the Agentforce layer during an incident. Getting that accountability mapped before go-live - not after - is one of the things that actually separates smoother rollouts from the ones that spend six months in post-launch firefighting.

This Is Still Early, and That's Not a Disclaimer

Agentforce itself is relatively new in production-scale voice deployments. The ecosystem of certified BYOT connectors, tested reference architectures, and documented edge cases is still building out. That's not a reason to wait—in fact, organizations deploying it now are developing real institutional knowledge about what works when building the best AI voice agent experiences, and that advantage compounds over time.

But it does mean that the implementation quality varies substantially depending on which partners and which carrier combinations are in play. The pattern most teams don't anticipate is how much of the work lands on integration, QA, and change management rather than on the Agentforce configuration itself. The AI part, genuinely, tends to be the easier part. What the process actually stress-tests is whether your telephony infrastructure was as well-documented and understood as everyone assumed it was.

Whether the industry develops standardized BYOT reference architectures quickly enough to smooth that out for later adopters - or whether every organization keeps essentially figuring this out on its own - is a question that's genuinely still open right now.