More of the discovery calls I’m in now start from the same starting point: the client wants a voice AI agent in the IVR, not another DTMF tree. “Press 1 for billing, press 2 for…” is increasingly something to retire rather than extend – the assumption is that the caller should just say what they need, in whatever words they’d use with a person, and the system should understand it. That’s a good instinct, and the technology has genuinely caught up to it. But it skips past a question most people don’t realize they’re skipping: deciding to put an AI agent in the IVR is not the same decision as deciding which platform’s AI does the understanding.
The setup is usually the same. Salesforce is the system of record, Amazon Connect is the telephony layer, and somewhere in that stack there’s supposed to be an AI agent replacing the old menu tree. The question that actually needs answering is: does that agent live in Connect, or in Salesforce?
I’ve actually argued both sides of this on this blog. In Agentic AI with MCP: Amazon Connect & Salesforce, I made the case for centering the agent in Amazon Connect, with Salesforce and billing and field service sitting downstream as MCP-connected tools. In Salesforce Omni-Channel Unified Routing in a multi-national support center, the whole piece assumes Salesforce is the place that decides who handles a request. Those aren’t actually contradictory, but I don’t think I’ve ever said clearly why – so here’s the attempt.
Two different jobs, wearing one name
“Where does the AI agent live” is really two separate questions that get collapsed into one because they happen on the same phone call.
The first is who reasons over the conversation – who’s deciding what to ask next, when enough information has been gathered, when to call out to a backend system, when the caller has actually said what they need. Call this the reasoning layer.
The second is who decides where the request goes next – which queue, which skill, which human or AI specialist actually handles it, once the reasoning layer has worked out what’s needed. Call this the routing layer.
My MCP post was about the first question. My Unified Routing post was about the second. They can have different answers on the same call, and in most of the multi-system builds I’ve worked on recently, they do.
The routing layer has one honest answer
Start with routing, because it’s the less interesting decision. Salesforce Omni-Channel Unified Routing is explicit about its own job: it’s the final allocator of all agent work, voice included, across every channel – chat, case, email, phone. Skills-based routing, capacity, language, all resolved in one place. Amazon Connect can capture a call, run its own IVR, even run its own AI conversation – but the moment it’s time to decide who actually answers, Salesforce doesn’t support running its own Unified Routing alongside Connect’s native routing in the same contact center. You pick one authority. If Salesforce is your system of record and your agents – human and AI – are managed there, it should be that one.
Practically, this means Amazon Connect gets told the answer rather than working it out: a Routing contact attribute set to true, a Set Routing Criteria block placed before any Lambda invoke so Connect can’t jump ahead of Salesforce’s decision, and a holding queue that maps to Salesforce’s queue model. None of that changes no matter which system did the reasoning upstream of it.
The reasoning layer is the real decision, and it’s gotten more interesting
This is where the interesting choice actually sits, and it’s changed shape since I wrote the MCP post. Two credible answers exist today, and neither is a fallback for the other.
Agentforce Voice, Salesforce’s own conversational layer, uses the same Atlas Reasoning Engine that already decides which specialist agent should handle a text conversation on the website. Put an Agentforce Voice agent in the IVR and you get one orchestration layer, one skills model, and one place your team edits agent behavior – regardless of whether the customer started on the phone or the web widget. It’s natively grounded in Salesforce data with no extra plumbing.
Amazon Connect’s own agentic self-service, on the other hand, has moved a long way past the Lex-bot pattern most people still picture when they think “Connect IVR.” The old pattern – Lex intents, a Lambda round-trip, Amazon Transcribe into a bot, Amazon Polly back out – is explicitly legacy now. What replaced it is a genuine orchestrator (an AI agent that reasons across multiple turns and calls out to MCP tools mid-conversation, only returning control through an explicit Complete or Escalate action), paired with Amazon Nova Sonic doing speech-to-speech directly – one model, audio in, audio out, no separate transcription and synthesis hop, which is what gives Connect’s newer “Agentic Voice” its natural turn-taking and real barge-in. Reaching into Salesforce from that side happens through a Bedrock AgentCore Gateway acting as an MCP bridge – the same mechanism I described in the MCP post, just with a name and a vendor behind it now.
So the honest update to that earlier post: the architecture I described – agent in Connect, Salesforce as a downstream tool – is real and AWS has since built first-party support for exactly that pattern. It’s not the only good answer anymore, though. It’s one of two.
What that actually looks like on a call
Take a mid-sized insurer with contact centers in three countries, Salesforce as the case system, and a claims process that touches policy details, a third-party assessor’s scheduling system, and – for anything above a certain claim value – a manual approval queue. A customer calls to report a car accident.
If the reasoning layer sits in Agentforce Voice, the call is a Voice Call record from the first second, the same Atlas-orchestrated agent that already handles claims questions on the website picks up the conversation, and every action it takes – pulling the policy, checking coverage, drafting the claim – happens against Salesforce data with no separate integration to maintain. The tradeoff shows up if the assessor-scheduling system and the approval workflow live entirely outside Salesforce: the agent either needs those exposed as Salesforce-side actions, or the call still ends up bouncing to a human for anything the CRM alone can’t resolve.
Are you thinking of upgrading your contact center?
If the reasoning layer sits in Connect instead, the orchestrator can reach the policy system, the assessor’s scheduler, and the approval workflow as equal MCP tools from the start – Salesforce is one of several systems it calls into rather than the home base. That’s the stronger fit for a claim that genuinely spans four systems in one conversation. The tradeoff is that Salesforce’s own skills and routing logic now only sees the call once the orchestrator hands it off, so anything the orchestrator worked out along the way has to survive that handoff deliberately, rather than being native to where the call lived the whole time.
Neither of these is wrong. They’re optimized for a different shape of conversation, and most contact centers have both shapes of call arriving on the same number.
How to actually decide
I’d use Agentforce Voice as the default when Salesforce is genuinely the center of the org’s customer experience – when the same agent, or the same family of specialist agents, already handles web chat, and you want one place managing skills, language, and escalation logic rather than two. It’s the simpler build for anyone already living inside Salesforce’s tooling, and it keeps the story from the Unified Routing post fully intact: one routing brain, fed by one reasoning layer, regardless of channel.
I’d reach for Connect’s agentic self-service instead in three situations. First, language or voice-quality coverage: Agentforce Voice’s language list is narrower than Salesforce’s text-based Agentforce, and it’s been expanding one release at a time, while Nova Sonic and Connect’s Agentic Voice have been adding languages independently on their own schedule – worth checking both lists against what you actually need before committing either way, and it’s not unusual to end up covering some languages one way and some the other while the gap closes. Second, when the request genuinely spans more than Salesforce – the utility company example from the MCP post, where a single call needs billing, metering, and field service as well as CRM, and Salesforce is one tool among several rather than the hub. That’s also usually the case where the multiplier effect I wrote about there does the most work, because each additional system the orchestrator can reach adds resolution paths a Salesforce-only agent can’t reach without its own separate integration for each one. Third, when the client’s contact center strategy is deliberately AWS-first, with Salesforce kept as the case system of record rather than the thing that owns the conversation – increasingly common where Amazon Connect was the incumbent platform and Salesforce arrived later, or where a merger left two contact center stacks and Connect became the consolidation point.
There’s a cost dimension too, though it rarely decides the question on its own. Agentforce Voice usage rolls into Salesforce’s own consumption model; Connect’s Agentic Voice and Nova Sonic are billed on AWS’s side, per minute, alongside whatever Bedrock model calls the orchestrator makes. For a contact center already deep into one vendor’s pricing agreement, that alone can tip a genuinely close call – it’s just not a reason to override a real architectural mismatch in either direction.
What I wouldn’t do, in either direction, is let the reasoning layer end up split across both systems on the same call – an Agentforce Voice session and a Connect orchestrator both trying to drive the same turn is the same failure mode as the routing conflict above, just one layer up. Pick which system owns the dialogue, and let the other be a tool it calls into, not a second conversation running in parallel.
The multi-language wrinkle
For the multi-national contact centers I wrote about in the Unified Routing post, there’s a specific trap worth naming: solving language at the wrong layer. Whichever system reasons over the call, the resolved language needs to land as a Salesforce skill – not just a Connect contact attribute, not just something the AI agent “knows” for the duration of the conversation. Unified Routing matches human capacity against skills. A language that only exists as a session variable inside Connect, or inside the AI agent’s own context, never reaches that decision, and the customer who just spent two minutes establishing they need Dutch gets queued to whichever agent is free next.
The same discipline applies to whatever the reasoning layer resolves along the way – intent, sentiment, verified identity. If Connect’s orchestrator ends the call with an Escalate tool call carrying a structured summary, that payload has to be mapped into Salesforce’s routing attributes and skills at handoff, or the human agent’s screen-pop is missing exactly the context the AI agent already worked out.
Where this leaves the build
Reasoning and routing are two different questions, and treating them as one is what makes this decision feel harder than it is. Routing has one right home if Salesforce is your system of record: Omni-Channel Unified Routing, full stop, whatever ran before it. Reasoning has two legitimate homes, and the right one depends on how centered the build actually is on Salesforce versus how many other systems a single conversation genuinely needs to touch.
That’s also the conversation I keep having with clients evaluating this: not “which vendor’s AI is better,” but which of these two questions is actually driving the design decision they’re stuck on – and once that’s separated out, most of the “Connect or Salesforce” debates resolve themselves in about ten minutes.
By Nico Claes – last updated August 26, 2026
