Your phone estate already runs on Amazon Connect, AWS now offers AI agents inside it, and someone has asked the obvious question: why buy a separate voice AI platform at all? For a team with AWS engineers on hand, that question deserves a serious answer. For a team without them, the answer depends on something the product page does not show, which is how much has to be assembled, and who looks after it once callers are on the line.
This guide is written for the Head of Customer Operations or CIO on an AWS estate. It reads the AWS Administrator Guide as it stood on 8 November 2026 and turns it into an assembly list: the parts you build, the limits that shape the call, and what London availability does and does not settle. It treats the AWS build as an operating model, and it does not quote any AWS rate; our 2026 buyer's guide carries the comparison on cost.
The boundaries are deliberate. The wider choice between an incumbent's native AI and a separate platform is covered for other estates in our Five9 alternative guide and our Genesys route map. Running NiCE Cognigy on top of Connect belongs to our Cognigy alternative guide, and the generic framing belongs to build, orchestrate or buy.
This guide is shipped by the team behind Dilr Voice, a multi-agent voice AI platform that chains specialised agents into a single phone call. Or see DATS, our five-stage AI consulting system, if the open question is where AI belongs in your operation at all.
What is Amazon Connect Customer, and what do its AI agents do?
Amazon Connect Customer is the current name for the contact-centre product AWS previously called Amazon Connect, which has become the name for a wider set of agentic AI solutions. Its AI agents are built on Amazon Bedrock and can speak directly with callers over voice, answer questions, take actions through connected tools, and escalate to a human, as well as assisting human advisers during live contacts.
The rename matters when you search the documentation, because the AWS Administrator Guide now says Connect Customer throughout while most buyers still say Amazon Connect. This guide uses both, and they mean the same product here. The page is also explicit that AI agents are built on Amazon Bedrock and can be configured in the admin website or through the API.
Two distinct jobs sit under the one label, and most confusion starts here. Agent assist supports a human adviser with recommendations during a contact. Self-service puts the AI agent on the line with the caller. They share a domain and a design surface, but some of what AWS documents applies to only one of them, and a business case that blends the two will overstate what has been checked. Everything below concerns self-service on voice, unless a sentence says agent assist.
Within self-service, AWS documents two approaches. Agentic self-service uses orchestrator AI agents that reason across steps, call tools and hold a continuous conversation, and AWS recommends it for new implementations. Legacy self-service answers from a knowledge base and hands control back to the contact flow, and AWS says that approach is not receiving new feature updates. If a partner proposal describes the legacy pattern, ask why.
What do you have to assemble before a Connect AI agent answers a call?
Amazon Connect self-service needs a stack of configured parts before a caller hears anything: a domain holding a knowledge base, an orchestrator AI agent, a security profile, tools, a prompt, a default-agent setting, a Conversational AI bot and a contact flow. AWS sets out seven high-level steps after the domain exists, so the work is a build with several owners rather than a switch your administrator turns on.
The sequence below condenses the seven steps of the AWS agentic self-service set-up, preceded by the domain creation step that all AI agents depend on.
Read that list as an ownership question, because each row tends to land with a different person. The table below is our own judgement of where the work usually falls, and the owner column is the part to argue about in your first planning session. A team that has run a structured integration roadmap before will recognise the shape.
| Part you assemble | What it decides | Likely owner after go-live (our judgement) |
|---|---|---|
| Domain and knowledge base | What the agent can cite, how often it refreshes | Knowledge manager, with AWS administrator |
| Orchestrator and prompt | Behaviour, tone, escalation wording | Conversation designer or product owner |
| Security profile | Which tools the agent may touch | AWS administrator, signed off by security |
| MCP and flow module tools | Which systems are read and written | Integration engineers |
| Conversational AI bot | The bridge between the flow and the agent | Contact-centre developer |
| Contact flow | Routing, escalation, what happens on error | Contact-centre developer |
Two details are easy to miss. AWS describes a domain as an assistant holding one knowledge base, says an instance can be associated with only one domain, and notes that several knowledge bases are reached by configuring multiple retrieve tools on the orchestrator. Knowledge files are ingested at up to 1 MB each, with prebuilt connectors for Amazon S3, SharePoint Online, Salesforce, ServiceNow and Zendesk. Anyone who has worked through a voice knowledge base design will want those limits in the first workshop, not the third.
Which AWS limits should shape your call design?
Amazon Connect documents three constraints that change how a voice agent should be designed: MCP tool calls time out after 30 seconds, orchestrator replies must use a specific message format or customers will not see them, and routing decisions return to the contact flow through session attributes. None is a defect. Each is a design input your team has to hold, test and keep working through every later change.
The MCP tools page states the 30-second timeout limit, and a tool that exceeds it does not complete. Thirty seconds is a ceiling on the tool, not a target for the conversation: a caller will not sit through it in silence. Your backends need a response time budget well inside that limit, and the agent needs something honest to say while it waits. We cover the mechanics in voice agent tool calling and masking dead air.
The reply format is the detail most likely to catch a team out. AWS marks it as important that orchestrator responses are wrapped in message tags, because otherwise customers will not see messages from the AI agent. AWS does not spell out how that failure sounds on a call, so test it on voice. A prompt edit by someone unaware of that rule can therefore break the customer experience without changing any infrastructure, so prompt changes deserve the same release discipline as code, and a golden-set regression test is the natural gate.
Routing depends on a chain of handovers. When a Return to Control tool fires, AWS stores the tool name and its inputs as Amazon Lex session attributes, and your flow reads them with a Check contact attributes block. The default tools are Complete and Escalate. Every escalation path you care about, such as a vulnerable caller or a failed identity check, ends up as a branch someone has drawn in that flow. The warm transfer design work does not disappear on AWS, it moves into your flow.
Access control is the part AWS has made comfortable for existing administrators. Connect reuses security profiles for AI agents, so you govern what an agent may do much as you govern a human adviser. For a team already running security profiles well, that is a real advantage, and one a separate platform cannot match inside your AWS console.
The same diagnostic logic underpins our AI placement diagnostic, which ranks where automation should sit before anyone commits to a build.
What does London availability settle for a UK deployment?
Amazon Connect added agentic speech-to-speech voice in Europe (London) in March 2026, with two UK English voices, so a UK team can select a London instance for the feature. That settles availability only. It does not, by itself, answer where every step of model processing happens for your configuration, and that question should go to AWS in writing before your data protection review closes.
The AWS announcement names the Amy and Brian voices for UK English. The Regions page lists Europe (London) for agentic voice, live media streaming and outbound campaigns. The Amazon Nova 2 release notes add a nuance for anyone assessing the model directly: Nova 2 Sonic is listed as available through Amazon Connect in London, and London is not among its direct availability Regions. The pages we read do not say which model a given Connect voice agent uses, so confirm that for your configuration.
The sentence to read carefully is in the set-up guide, and it concerns agent assist specifically. AWS says agent assist uses cross-region inference to select a Region for processing, and then adds:
"If you do not want your data processed in a different Region from what you selected, you can contact AWS Support."
AWS, Initial set-up for AI agents, Amazon Connect Customer Administrator Guide, read 8 November 2026
We found no equivalent sentence for voice self-service on the pages we read, which is a gap in our reading and not evidence either way. So ask the question directly, for the exact models and features in your design: does any inference for this configuration leave the Region we selected, and what changes if we ask you to stop it? The same care applies to the claim that agent assist can be used in compliance with GDPR, which AWS makes about agent assist and which names GDPR, not UK GDPR. Your UK GDPR position is yours to establish, and our guides to data residency and international transfers set out what the review needs, with the ICO's expectations covered in our UK and EU compliance guide.
Keep the inventory honest as well. AWS lists the data Connect handles, including contact metadata and phone call audio streams, plus recordings when enabled. Numbers are a separate workstream too: the UK porting requirements ask for a last invoice and a Letter of Authorization, and a UK site address for local numbers.
Can a third-party voice agent run inside Amazon Connect?
Amazon Connect can bring in an external AI agent over the Agent-to-Agent protocol, and on voice contacts that agent can take over the conversation with Connect handling speech or with its own audio. Set-up is API-only, needs SigV4-signed requests, and is unavailable on the Customer Basic tier. AWS also advises reviewing audio-streaming agents with your account team for latency and audio quality before production.
The external agent set-up page describes two collaboration modes: a collaborator that works behind the scenes and returns a result, and one that talks to the customer directly. Audio streaming runs over secure WebSocket only and uses PCM audio. This route keeps Connect as the front door and swaps the agent behind it, which is a different decision from moving the voice agent off the estate.
Vendors have already built towards this. Our ElevenLabs agents alternative guide and Decagon alternative guide record what those vendors say about reaching Amazon Connect, and they are the place to go if a named vendor is already on your list. For anyone comparing routes, the useful test is the same on each: who owns the audio path, who owns the transcript, and who is paged when a call goes silent.
Many estates will also have an older layer to retire, and the same assembly list applies to it. If you are still running touch-tone menus, our IVR migration guide covers the cutover, and a short scoping call can tell you whether that migration should come first.
When is building on Amazon Connect the right choice?
Building on Amazon Connect is the right choice when your contact centre already runs there, AWS engineers and a contact-centre developer are in post, and you want agents governed by the same security profiles as your human advisers. It also suits regulated teams that prefer one cloud supplier and one contract. In those conditions the assembly work is familiar, and a separate platform adds a supplier without removing much.
Be specific about what "already in post" means. The build above needs someone who can write and maintain flows, someone who can expose backend systems as tools, and someone who owns prompts and regression tests after launch. AWS describes its customer experience product as AI-powered with no fixed costs, which is the vendor's own description and worth modelling against your real volumes. A baseline taken before the pilot is what makes that model mean anything, and our voice AI ROI framework sets out the arithmetic.
If those people exist and have capacity, we would stay on Connect and spend the effort on design. Our AI execution office exists for the opposite case, where the skills are thin and someone senior needs to own delivery across the estate.
When does a separate call platform make more sense?
A separate call platform makes more sense when the phone work is a contained set of inbound or outbound calls, your team has no spare AWS engineering capacity, and the workload does not justify building a contact-flow practice around it. It also fits when the workload does not need to live on your contact-centre estate at all, such as an after-hours front desk or a contact-list campaign.
The trade is direct. You give up a single console and the reuse of your security profiles, and you take on another supplier, another data processing review and a handover boundary between two systems. In return, much of the call orchestration moves to the supplier, although prompts, knowledge, escalation rules and integrations still need a named owner on your side. Whether that is a good trade depends on the owner column: if most rows have no name beside them, the build will stall after launch even if it ships. Our wider enterprise voice agents guide sets out the operating questions, and orchestrators compared with platforms covers the third path of assembling your own stack on developer tools.
How does Dilr Voice differ from the Connect build for UK phone work?
Dilr Voice is a multi-agent voice AI platform where greeter, qualifier, knowledge, customer care and action agents are chained into one phone call, each with its own prompt, model and tools. Telephony runs on Twilio or Vobiz, so it is not a layer inside Amazon Connect, and no live Dilr page names a Connect integration. Teams on AWS should treat it as a separate line beside their estate.
Dilr Voice ships per-country compliance rules by default, including recording consent, DNC registry checks, opt-out recognition, permitted calling hours and full audit trails on every call. Response time is under 500 milliseconds on our own on-platform measurement, and it covers 30+ languages. Agents pass context to the next on handover. Knowledge bases are uploaded documents, chunked automatically and searched during live calls. Post-call automation updates CRM records and sends notifications without code, with HubSpot and Salesforce named live.
The honest limits matter just as much here. It will not sit inside your AWS security profiles, it will not appear in your Connect reporting, and anything that must transfer into a Connect queue needs testing as ordinary telephony on your own numbers before you rely on it. You can try Dilr Voice on a free trial with no credit card required, and hosting details for enterprise, including regional data residency options, are covered in the Dilr FAQ.
What is the best Amazon Connect AI agents alternative for UK teams in 2026?
The best Amazon Connect AI agents alternative for a UK team depends on who will own the build. Stay on Connect's own agents if AWS engineers and contact-centre developers are in post. Bring an external agent over Agent-to-Agent if Connect must stay the front door. Choose a separate platform such as Dilr Voice for contained phone work without AWS engineering capacity.
Score the options on three criteria: whether your named owners can keep the assembly running, whether the data route has been answered in writing for your configuration, and whether the phone work needs to sit on the contact-centre estate. Connect wins outright where your estate, your skills and your security model are already on AWS, and we would not argue a team out of that. Genesys and Five9 customers face a similar question on different ground, and our category overview collects those comparisons. For the commercial side, talk to our team.
Frequently asked questions
Is Amazon Connect Customer a different product from Amazon Connect?
Amazon Connect Customer is the current name for the contact-centre product previously called Amazon Connect, according to the AWS Administrator Guide. AWS now uses Amazon Connect as the name for a set of agentic AI solutions for different business functions, so older articles, partner proposals and internal documents that say Amazon Connect are usually describing what AWS now calls Connect Customer.
Does Dilr Voice integrate with Amazon Connect?
Dilr Voice does not claim an Amazon Connect integration on its live product or FAQ pages, which name Twilio and Vobiz for telephony. A team on AWS should plan Dilr Voice as a separate phone line beside the estate. Any handover into a Connect queue would need testing as an ordinary telephony transfer on the team's own numbers before anyone relies on it in production.
Does choosing the London Region keep all Amazon Connect AI processing in the UK?
Amazon Connect lists Europe (London) for agentic voice, but choosing a Region and confirming where each processing step runs are separate checks. AWS says agent assist uses cross-region inference unless you contact AWS Support. We found no equivalent statement for voice self-service in the pages we read, so UK teams should get a written answer for their exact configuration.
Want to compare this with a working line? Try Dilr Voice for phone work, read the best AI voice agent guide, see our DATS methodology, or read about our approach to placing AI inside enterprise systems.
Name the owners before you draw the flow.
30-min scoping call · No deck · Confidential. We will tell you whether your phone work belongs on Connect, beside it, or nowhere yet.
Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.