Amazon Lex vs AI Agent in Amazon Connect: Which to Use for Voice

Searches for 'Amazon Lex vs AI agent' assume two products compete. In Amazon Connect they do not. AWS states that conversational AI bots built in the Connect admin website are powered by Amazon Lex, and that includes the bots that hand the conversation to an AI agent. Lex does the speech recognition and the bot plumbing. The question is what decides the reply.

There are three answers, and each is switched on through a Lex intent:

1. Your own intents, slots and fulfilment: a classic Lex bot where you define what the caller can ask for and what happens next.
2. A Connect AI agent, through the agent assist intent (AMAZON.QinConnectIntent): an LLM-driven agent managed inside Amazon Connect.
3. A Bedrock agent, through AMAZON.BedrockAgentIntent: an agent you build in Amazon Bedrock and attach to the bot.

This guide compares them against the AWS documentation we checked on 10 November 2026. If you have not built a voice agent yet, start with How to Add an AI Voice Agent to Amazon Connect, then come back here to choose the brain.

This is the original model. AWS describes a bot as a set of intents. Each intent has a name, sample utterances that show how a caller might express it, and a way to fulfil it. Slots are the values the bot must collect before it can act, such as a date or an account number, and AWS recommends a Lambda function for fulfilment. Every bot also has a fallback intent for requests it cannot classify.

Lex also offers Assisted NLU, which AWS says uses LLMs to improve intent classification and slot resolution, but only within the intents and slots you configured. It makes a classic bot more forgiving. It does not make it open-ended.

Classic intents fit best when the set of things a caller can do is small and each one has a clear sequence: check a balance, confirm an appointment, verify an identity before anything else. You can read the whole dialogue off the configuration, which makes testing and sign-off simpler.

You enable a Connect AI agent in a Lex bot with the agent assist intent. AWS documents two generations of self-service built on it, and the difference matters.

• Legacy self-service: the AI agent has built-in tools such as QUESTION, ESCALATION, CONVERSATION, COMPLETE and FOLLOW_UP_QUESTION. When it picks a custom tool, control returns to the contact flow, which reads the Tool session attribute and branches. AWS marks this version as not receiving new feature updates.
• Agentic self-service: an orchestrator AI agent reasons across several steps, calls MCP tools to act on backend systems, and keeps the conversation going until the issue is resolved or it needs to escalate. It returns control to the flow only through a Return to Control tool, and Complete and Escalate are included by default.

AWS recommends agentic self-service for new implementations. To set it up, you create an orchestrator agent by copying SelfServiceOrchestrator, give it a security profile, add tools, set it as the default self-service agent, create a Conversational AI bot with the agent assist intent, and route to it from a Get customer input block. Orchestrator replies must be wrapped in message tags or the caller will not see them. Our step-by-step setup guide walks through each of these.

The security profile point is easy to miss and valuable. The agent can only use the tools its profile allows, the same way a human agent's access is controlled, so you can give an AI agent read access to orders without refund rights.

Lex also offers AMAZON.BedrockAgentIntent. You give it a Bedrock agent ID and alias, and optionally a Bedrock knowledge base. When the bot recognises the intent, the conversation stays with the agent, and the caller's messages are relayed to it, until the agent marks the conversation finished. Only then does Lex take control back and follow the next step you defined.

The documented requirements are specific. Generative AI must be turned on for the bot locale. The Bedrock agent must have User Input set to enabled under additional settings, because that is what lets it ask follow-up questions. AWS notes that only some Anthropic Claude models are currently supported for the optional model setting. The agent's answer, and details of the action group inputs, are written to session and request attributes your flow can read.

Choose this when the agent logic already lives in Bedrock, for example because you use multi-agent collaboration, existing action groups or a Bedrock knowledge base, and you want the phone channel to reuse it. The trade is that you own more: the agent's instructions, its permissions and its evaluation.

Several documented restrictions make the choice for you before preference comes into it.

• AMAZON.QinConnectIntent cannot be used in the same bot locale as AMAZON.QnAIntent or AMAZON.BedrockAgentIntent. You cannot run a Connect AI agent and a Bedrock agent in one locale of one bot.
• Each bot locale can have only one agent assist intent, and the Amazon Q in Connect domain it uses must be in the same AWS Region as the Lex bot.
• The agent assist toggle in the Connect admin website works for bots created there. For a bot created elsewhere, you update the intent in the Lex console.
• For a language other than US English, AWS says you must customise the self-service prompts so the agent replies in that language.
• The Set voice language must match the Lex bot locale, or Get customer input errors.
• MCP tools called by a Connect AI agent have a 30-second timeout, so anything slower needs an asynchronous design.

If you need both approaches, the workable pattern is separate bots, or separate locales, with the contact flow deciding which one a call reaches. That keeps each bot's configuration simple and makes it obvious in the logs which one handled the call.

All three start the same way: a Get customer input block that invokes your Lex bot. What happens after it differs, and this is where most of the real build effort sits.

• Classic Lex: the bot collects slots and runs your fulfilment Lambda. The flow continues from the block's outputs, usually with a Check contact attributes block or intent-based branches. You decide the exact dialogue, so you also write every prompt and error path.
• Connect AI agent, legacy: add the Connect assistant block, then Get customer input. After the agent's turn, a Check contact attributes block with namespace Lex, key Session attributes and session attribute key Tool tells you which tool it chose. Route COMPLETE to the end, ESCALATION to a queue, and a custom tool such as a booking handoff to its own branch. AWS notes that ESCALATION takes the Error branch of Get customer input.
• Connect AI agent, agentic: the same Get customer input block, then a Check contact attributes block on the Default output, reading the Tool session attribute. Add a condition for each Return to Control tool: Complete goes to Disconnect, Escalate goes to Set working queue and Transfer to queue, and any custom tool goes to its own logic. Connect the No match output somewhere safe, such as a transfer to a person.
• Bedrock agent: Get customer input invokes the bot, the Bedrock agent runs the conversation until it finishes, and the flow reads the attributes Lex stored. Build explicit handling for the case where the agent does not finish, because the caller is otherwise left inside the agent's turn.

A practical rule for all three: wire the failure path before the happy path. A call that reaches a person with a summary is a success. A call that goes silent or loops is the failure that costs you a customer.

Your flow can only react to what the bot returns, so it is worth knowing what each one stores.

The session attributes are your audit trail as much as your routing signal. Decide up front which of them you will store against the contact record, because you will want them the first time someone asks why a call went the way it did.

Agentic self-service lets you replace the default Escalate tool with one that captures context, so the person who picks up the call does not start from zero. AWS publishes this input schema as an example, with a reason category, a summary, the customer's intent and their sentiment:

{
  "type": "object",
  "properties": {
    "customerIntent": { "type": "string", "description": "A brief phrase describing what the customer wants to accomplish" },
    "sentiment": { "type": "string", "enum": ["positive", "neutral", "frustrated"] },
    "escalationSummary": { "type": "string", "maxLength": 500 },
    "escalationReason": {
      "type": "string",
      "enum": ["complex_request", "technical_issue", "customer_frustration", "policy_exception", "out_of_scope", "other"]
    }
  },
  "required": ["escalationReason", "escalationSummary", "customerIntent", "sentiment"]
}

Remove the default Escalate tool, create a Return to Control tool with this name and schema, describe in its instructions when to use it, and copy the four values to contact attributes in the flow. The enumerated reasons also give you something to count: after a month you can see whether callers escalate because of policy exceptions or because the agent could not understand them, which points at very different fixes.

To see the difference, take a single call: a patient phones to move tomorrow's appointment to Thursday afternoon.

The classic design is the most predictable and the least flexible. The two agent designs absorb messy phrasing well but need good tools, a clear prompt and a tested failure path. Which trade you want depends on how costly a wrong action is in your business, not on which technology is newer.

If you already run the legacy AI agent, AWS's guidance is to use agentic self-service for new implementations, so a migration plan is worth drawing up even if you do not act on it now. We have not found a published one-click migration, so treat this as a sensible order of work rather than an AWS procedure.

1. List the custom tools in your legacy prompt, such as a booking handoff, and what each branch in your flow does after it.
2. Decide which become MCP tools the agent calls directly, and which stay as Return to Control hand-offs because they need fixed, auditable steps.
3. Create a security profile that allows only the MCP tools you chose.
4. Create the orchestrator agent from SelfServiceOrchestrator and move your instructions across. Remember that orchestrator replies must be wrapped in message tags.
5. Use Constant tools to stand in for backend calls while you tune the conversation, then swap in the real MCP tools.
6. Run the new bot beside the old one on a test number, compare outcomes on the same call set, and only then move the production number.

Keep the legacy configuration in place until the new one has handled real traffic without surprises. Rolling back a phone number to the previous flow is quick. Rebuilding a configuration you deleted is not.

None of these is automatically safer. A badly scoped Lambda in a classic bot can do as much damage as an over-permissive agent. What changes is where you look: in the classic design you review the dialogue, and in the agent designs you review the permissions and the tools.

Our own default for a new voice agent that takes calls and acts on systems is agentic self-service with tight tools, plus a classic intent for any step where the wording and sequence must be exact. That is a judgement from builds we have done, not an AWS recommendation, so test it against your own call types.

A common worry is that an AI agent will improvise on a sensitive step. The agentic design gives you a clean answer. Give the agent a Return to Control tool for each hand-off, such as VerifyIdentity or TakePayment. When it invokes one, the AI conversation ends, the tool name and its parameters are stored as Lex session attributes, and your flow routes to the fixed part. Whether the caller then returns to the agent is a flow design choice, and one to test, because we did not find AWS documentation describing how context carries across the return.

This keeps the exact wording, validation and logging of regulated steps under your control, and leaves the open conversation to the model. It also gives you a natural place to record what the agent passed on, which helps when you review calls.

Most of these are configuration mismatches rather than model problems, which is good news: they are quick to fix once you know where to look.

Do not pick from a feature table. Take twenty real calls, or scripted versions of them, and run each approach against the same set. Score three things: did the caller reach the right outcome, did it take a sensible number of turns, and did it hand off to a person at the right moment. Include awkward calls: a caller who changes their mind, one who gives a number slowly, one who asks for something out of scope.

Then listen on a real phone line. A design that reads well in the test console can feel slow on a call. If latency is your worry, see How to Measure AI Voice Agent Latency in Amazon Connect for a turn-by-turn method, How to Add an AI Voice Agent to Amazon Connect for the voice and speech settings, and the architecture and build guide for where the time goes. To have this designed and evaluated for your contact centre, see our AI voice agent development service.