Cloud / Amazon Lex Interview questions

Amazon Lex is an AWS service for building conversational interfaces, meaning chatbots and voice bots that accept typed or spoken input. It is built on the same family of technology that powers Alexa, so you don't have to train your own speech or language models.

Under the hood it combines automatic speech recognition (ASR), which turns audio into text, with natural language understanding (NLU), which works out what the user wants. You define the intents and slots, and Lex manages the dialog and hands the result to your backend.

Common uses are self-service IVR with Amazon Connect, booking and FAQ bots on websites, and voice features inside mobile apps. It is serverless and billed per request.

A Lex V2 bot is a hierarchy. The bot holds one or more locales (languages), and each locale holds the intents that describe what users can ask for.

• Intent: one action the user wants, such as BookHotel.
• Sample utterances: phrases that teach the NLU model how users express that intent.
• Slots and slot types: the parameters Lex must collect, and the kind of value each one accepts.
• Prompts and responses: what the bot says to ask for a slot, confirm, or close out.
• Code hooks: optional Lambda functions for validation and fulfillment.
• Version and alias: how you freeze and deploy a tested bot.

flowchart TD
  B[Bot] --> L["Locale e.g. en_US"]
  L --> I[Intent]
  I --> U["Sample utterances"]
  I --> S[Slots]
  S --> T["Slot types"]
  I --> P["Prompts and responses"]
  I --> H["Lambda code hooks"]
  B --> V[Version]
  V --> AL[Alias]

An intent represents a single action a user wants to carry out, for example CheckOrderStatus, BookAppointment or ResetPassword. A bot is simply a collection of intents.

Each intent bundles together its sample utterances, the slots needed to complete the action, the prompts Lex uses to collect them, and what should happen on fulfillment, either a closing message or a Lambda call.

At runtime, Lex's NLU model scores the user's input against every intent and picks the best match. Keep intents focused. One intent per business action is easier to tune than one oversized intent with ten optional slots.

An utterance is what the user says or types, such as "I need a room in Denver for Friday". The sample utterances you add to an intent are examples that train the NLU model, not a list of phrases it must match word for word.

You can embed slots in curly braces so Lex learns where the values appear:

Book a room in {City}
I want to stay in {City} from {CheckInDate}
Reserve a hotel

Provide varied phrasing, and avoid identical or near-identical utterances in different intents because that creates ambiguity. Lambda receives the raw text as inputTranscript.

A slot is a piece of data an intent needs before it can be fulfilled, like a city, a date or an account number. Think of slots as the parameters of the intent.

Every slot has a name, a slot type, and usually an elicitation prompt. If a slot is marked required and the user hasn't provided it, Lex asks for it until it gets a valid value or runs out of retries.

Lex also fills slots from the first utterance when it can, so "Book a room in Denver" skips the city question.

A slot type defines what values a slot can accept. Lex V2 offers several kinds:

• Built-in: ready-made types such as AMAZON.Number, AMAZON.Date, AMAZON.Time, AMAZON.City, AMAZON.PhoneNumber, AMAZON.EmailAddress and AMAZON.AlphaNumeric.
• Custom: a list of values you define, optionally with synonyms, for example RoomType with Single, Double, Suite.
• Regular expression: matches a pattern like ORD-[0-9]{6}, handy for order or ticket IDs.
• Composite: groups several sub-slots into one, such as an address.

For custom types you also choose a resolution strategy: expand values lets Lex accept similar values, while restrict to slot values only accepts what you listed.

Built-in intents are prebuilt intents that cover common conversational moves, so you don't have to write them from scratch. They carry a set of default utterances, and you decide what the bot does when one fires.

• AMAZON.FallbackIntent: input that matches nothing else.
• AMAZON.HelpIntent, CancelIntent, StopIntent: "help", "cancel", "stop".
• AMAZON.YesIntent, NoIntent: simple confirmations.
• AMAZON.RepeatIntent, StartOverIntent, PauseIntent, ResumeIntent: dialog control.
• AMAZON.KendraSearchIntent and AMAZON.QnAIntent: answer questions from a knowledge source.

New V2 bots start with the fallback intent already added.

AMAZON.FallbackIntent is the safety net. Lex invokes it when the user's input doesn't match any other intent with a confidence at or above the bot's NLU confidence threshold.

A good fallback response doesn't just say "sorry". It can rephrase the question, list what the bot can do, count how many times the user has failed in a row, and after two or three misses hand the conversation to a human agent.

You can't add sample utterances to this intent, since its whole job is to catch what the other intents don't. You can attach a Lambda function to it to log the missed text, which is a cheap way to find new intents to build.

Every bot has a working copy called DRAFT. When it's ready you publish a version, an immutable numbered snapshot (1, 2, 3 and so on). An alias is a named pointer to a version, like dev, test or prod.

Clients call the alias, not the version, so you can promote a new version by repointing the alias without touching the application. Aliases also hold per-locale settings such as the Lambda function and conversation logging.

In the console the flow looks like this:

1. Choose Create bot and pick a creation method: traditional, describe it in natural language, or start from transcripts.
2. Name the bot, pick or create the IAM runtime role, answer the COPPA question, and set the idle session timeout.
3. Choose the language, the voice for speech output, and the NLU confidence threshold.
4. Add intents, sample utterances, slots and slot types.
5. Click Build, then test in the built-in test window.
6. Create a version, attach it to an alias, and connect a channel or call the runtime API.

You can do the same through the AWS CLI, SDKs, CloudFormation or CDK.

A locale is a language and region pairing, such as en_US, en_GB, es_US or fr_FR. In Lex V2 a single bot can contain several locales, and each one has its own intents, utterances, slot types and prompts.

The locale also controls the voice used for spoken replies and the NLU confidence threshold. You build and test each locale separately, but versions and aliases are shared across the whole bot. Adding a language later doesn't disturb the locales that already work.

Prompts and responses are the messages your bot sends. A prompt asks the user for something, like a slot value or a yes/no confirmation. A response tells them something, such as the closing message after fulfillment.

Each one is built from a message group. You can add several message variations so the bot doesn't sound robotic, and Lex picks one at random. Messages can be plain text, SSML for voice, a custom payload, or an image response card with buttons.

Elicitation prompts also carry a maximum number of retries and an option to let callers interrupt the prompt while it is being spoken.

Session attributes are key-value pairs that hold context for the whole conversation, like a customer ID, a language preference, or how many times the fallback intent has fired. They live in sessionState.sessionAttributes.

Lex doesn't change them itself. Your client sets the initial values on a request, your Lambda function can read and modify them, and Lex carries them forward on every later turn of the same session.

"sessionState": {
  "sessionAttributes": {
    "customerId": "C-1042",
    "failCount": "1"
  }
}

Values are strings, so serialize numbers and objects before storing them. Keep them small and non-sensitive, since they travel with every request and can end up in logs.

A confirmation prompt asks the user to approve the collected slot values before the intent is fulfilled, for example "I'll book a double room in Denver for 2 nights. Is that right?". It is most valuable for actions that cost money or can't easily be undone.

If the user says yes, Lex proceeds to fulfillment. If they say no, Lex plays the declination response and the intent ends without fulfilling. Your Lambda function sees the outcome as confirmationState: Confirmed, Denied or None.

Skip confirmation for harmless read-only intents like "what are your opening hours".

A code hook is a Lambda function that Lex calls during a conversation so you can run your own logic. There are two kinds:

• Dialog code hook: called on turns while the intent is being collected, to validate slot values, set defaults or steer the conversation.
• Fulfillment code hook: called once the intent is ready, to do the real work like saving a booking or calling an API.

One Lambda function is attached per bot alias and locale, and it receives invocationSource set to DialogCodeHook or FulfillmentCodeHook so it knows which phase it is in. Without a hook, Lex can only play static messages.

Applications talk to a live bot through the Lex V2 runtime service (lexv2-runtime). The main calls are:

• RecognizeText: send a text message, get the bot reply back.
• RecognizeUtterance: send an audio or text input in one request and receive text and optionally audio.
• StartConversation: bidirectional streaming over HTTP/2 for real-time voice.
• GetSession, PutSession, DeleteSession: read, set or end the session state.

Bot building and management use a separate API, lexv2-models. Your app only needs runtime permissions, so keep model-management rights for your deployment pipeline.

Conversation logs capture what users and the bot said so you can debug and improve the bot. They are configured per alias and come in two forms:

• Text logs go to Amazon CloudWatch Logs.
• Audio logs go to an Amazon S3 bucket.

Both can be encrypted with an AWS KMS key. Lex needs an IAM role with permission to write to the destination. If a slot holds sensitive data, turn on slot obfuscation so the value is masked in the logs. Review the logs regularly for missed utterances, since they are the best source of new training phrases.

The idle session timeout decides how long Lex keeps a conversation's state after the last user input. When it expires, the session, including slot values and session attributes, is discarded and the next message starts a fresh conversation.

The default is 5 minutes (300 seconds) and you can set anything from 1 minute up to 24 hours. A short value suits a phone IVR. A longer one suits a web chat where users step away and come back.

Choose carefully: too short and users lose their half-filled booking, too long and stale context lingers.

The Automated Chatbot Designer builds a starting bot from your existing conversation transcripts instead of from a blank page. You point it at transcripts in Amazon S3, such as contact center call logs, and it analyzes them to propose intents, sample utterances and slots.

You then review the suggestions, accept the ones that make sense, and add them to the bot. It saves a lot of discovery time when you already have thousands of real calls.

It gives you a draft, not a finished bot, so you still need to tidy the intents, write the responses and test.

Amazon Connect uses Lex to understand callers in a contact flow. The setup is:

1. In the Connect console, open Flows and add the Lex V2 bot alias to your Connect instance.
2. In the contact flow designer, add a Get customer input block and choose the bot, alias and locale.
3. Branch on the returned intent name, for example to a queue or to a self-service path.
4. Read slot values and session attributes from the Lex attributes in later blocks.

Callers can speak or press keypad digits, which Lex receives as DTMF. Send them to an agent from the fallback path when the bot can't help.

Lex V2 is the current generation, rebuilt with a simpler structure and newer features. V1 is the legacy service, so new projects should start on V2 and V1 bots should be planned for migration. Check the AWS documentation for V1's current support status before relying on it.

The two have separate APIs and console areas, so an existing V1 bot must be exported and re-imported or rebuilt in V2.

Both are Lambda calls, but they run at different moments and do different jobs.

If you only need to do something at the end, you can skip the dialog hook entirely. If you enable it, remember it fires on every turn and adds a bit of latency each time.

For each input Lex's NLU model scores the text against every intent in the locale and produces a ranked list called interpretations, each with a confidence score between 0 and 1.

If the top score is at or above the locale's NLU confidence threshold (default 0.40), that intent becomes the active one. If not, Lex routes to AMAZON.FallbackIntent.

Your Lambda hook receives the whole interpretations list, so it can see runner-up intents and their scores. That is useful when two intents are close and you'd rather ask a clarifying question than guess.

Raising the threshold gives fewer wrong matches but more fallbacks. Lowering it does the opposite.

Both are key-value maps, but their lifetime is different.

Lex reserves the x-amz-lex: prefix for its own request attributes, so don't use that prefix for your own keys. A handy habit: put anything the next turn needs in session attributes, and anything only this call needs in request attributes. Neither map is a database, so use DynamoDB or similar for data that must outlive the session.

This setting is the slot value resolution strategy and it controls how strictly Lex matches input to your list.

Expand values lets Lex use the list as training examples and still accept similar values it wasn't given. If your RoomType list has "Suite" and the user says "Penthouse", Lex may capture it and return the original text.

Restrict to slot values only accepts the values and synonyms you listed. Anything else is treated as not recognized and Lex re-prompts.

Choose restrict when your backend can handle only a fixed set, such as product codes or department names. Choose expand when the list is representative, like cities or product names users may phrase freely.

Lex needs a resource-based policy on the Lambda function that lets the Lex V2 service principal invoke it. Without it, the build may succeed but runtime calls fail with an access denied error.

The console adds the permission for you when you pick the function on the alias. From the CLI you can add it yourself and scope it to one bot alias:

aws lambda add-permission \
  --function-name BookingHandler \
  --statement-id lex-invoke \
  --action lambda:InvokeFunction \
  --principal lexv2.amazonaws.com \
  --source-arn arn:aws:lex:us-east-1:111122223333:bot-alias/BOTID/ALIASID

Scoping with --source-arn stops other bots in the account from calling your function. If you create the alias with CloudFormation, add the same permission as an AWS::Lambda::Permission resource so it is never forgotten. Also give the function enough timeout for your slowest backend call.

Basic validation comes from the slot type itself: a built-in type like AMAZON.Date, a regex type, or a restricted custom list. For business rules such as "check-in must be in the future", use the dialog code hook.

The Lambda function inspects the slot, and if it's invalid it clears the value and tells Lex to ask again with ElicitSlot:

def invalid_date(event):
    return {
      "sessionState": {
        "dialogAction": {"type": "ElicitSlot", "slotToElicit": "CheckInDate"},
        "intent": {"name": "BookHotel", "state": "InProgress",
                   "slots": {"CheckInDate": None}}
      },
      "messages": [{"contentType": "PlainText",
                    "content": "That date is in the past. Which day will you arrive?"}]
    }

Return Delegate when all values pass so Lex continues the normal flow. Also cap how many times you re-ask, otherwise a user who keeps giving a bad date is stuck in a loop. After the limit, send them to a fallback path or a human agent.

Conditional branching lets you change what the bot does next based on a condition, without writing Lambda code. You add a condition at a point in the intent, such as after a slot is filled or after fulfillment, and define the next step for it.

Conditions are expressions on slot values, session attributes or the intent's state, for example [RoomType] = "Suite". A branch can play a response, jump to another slot or intent, or end the conversation. A default branch covers every case where no condition matched.

Use it for simple routing like "if the cabin is Business, ask about lounge access". Move to Lambda when the decision needs an API lookup or complex logic.

Contexts let you control which intents can fire at a given point, so a follow-up like "yes, cancel it" only matches after the right intent has run.

• An intent can set an output context when it completes, with a lifetime in turns or seconds.
• Another intent can require that context as an input context. Lex only considers it while the context is active.

For example, OrderStatus sets an output context named order_lookup for 5 turns. A CancelOrder intent with that input context only becomes eligible during those 5 turns.

This keeps similar-sounding intents from stealing each other's utterances and also reduces false matches on short phrases like "yes" or "that one".

A composite slot type groups several related sub-slots into one structured value. The classic example is an address made of street, city and postal code, or a date range made of a start and an end.

Use one when users tend to give the whole thing in a single breath, like "send it to 12 Main Street, Austin, 78701". Lex can capture all the parts at once instead of asking three separate questions, and your Lambda receives them together.

Don't use a composite slot when the parts are usually given separately or when they have different validation and prompting needs. Plain individual slots are easier to tune in that case.

A multi-valued slot can hold more than one value from a single turn. If the slot is Toppings and the user says "pepperoni, mushrooms and olives", Lex captures all three instead of keeping just one.

You switch it on in the slot settings by allowing multiple values. In the Lambda event the slot then arrives with a list shape, where each entry is its own value:

"Toppings": {
  "shape": "List",
  "value": {"originalValue": "pepperoni, mushrooms and olives"},
  "values": [
    {"shape": "Scalar", "value": {"interpretedValue": "pepperoni"}},
    {"shape": "Scalar", "value": {"interpretedValue": "mushrooms"}},
    {"shape": "Scalar", "value": {"interpretedValue": "olives"}}
  ]
}

Your code must then loop over the list rather than read one scalar value. A single-valued slot still arrives as a scalar, so check the shape before reading it. Decide up front how to treat duplicates, such as the same topping said twice.

DTMF lets phone callers press keypad digits instead of speaking, which is handy for card numbers, PINs and noisy environments. It is configured per prompt, alongside the audio settings.

The DTMF specification has four parts:

• End character: the key that says "I'm done", commonly #.
• Deletion character: the key that clears what was typed, commonly *.
• Max length: the number of digits after which input is accepted automatically.
• End timeout: how many milliseconds of silence mean the caller has finished.

DTMF only works when the channel carries it, which in practice means Amazon Connect or another telephony integration. Plain web chat has no keypad to press.

Both send user input to a bot and return the next message, but they differ in input type and how data is carried.

For continuous, real-time voice where the caller can interrupt, use StartConversation instead, which streams audio in both directions. Both calls take the bot ID, alias ID, locale ID and a session ID you choose, which is how Lex ties turns together. Reuse the same session ID for the whole conversation.

The usual approach is to keep one bot definition in code, publish a version when it passes tests, and move an alias to it.

1. Define the bot with CloudFormation (AWS::Lex::Bot) or CDK, or export it as a ZIP and keep that in source control.
2. Deploy to a dev account and build the locale.
3. Run regression tests, for example with the Lex test workbench.
4. Create a numbered version, then point the test alias at it.
5. After sign-off, repoint prod.

Keep Lambda ARNs, log groups and KMS keys as parameters, since they differ per environment. Rolling back is as simple as pointing the alias at the previous version.

flowchart LR
  G["Bot in source control"] --> D["Deploy to dev"]
  D --> T["Run test sets"]
  T --> V["Publish numbered version"]
  V --> A1["Point test alias"]
  A1 --> A2["Point prod alias after approval"]

Lex uses the built-in AMAZON.KendraSearchIntent to answer questions from an Amazon Kendra index, such as your help center or policy documents, without you writing an intent for every question.

When a user's input doesn't match any of your own intents, Lex can query the Kendra index and reply with the best FAQ answer, a document excerpt or a suggested document link. You choose the index, an optional query filter and the response format. The bot's IAM role must be allowed to call Kendra.

The approach works well for long-tail questions. Keep your own intents for transactions, like changing a booking, where you need slots and fulfillment.

Treat it in layers:

• Access: use least-privilege IAM for who can call the runtime and manage the bot, and scope Lambda invocation to the alias.
• In the logs: turn on slot obfuscation for card numbers, SSNs and similar, and encrypt text and audio logs with a KMS key.
• In transit: Lex API calls use TLS with Signature Version 4.
• In your code: don't print slot values to CloudWatch from Lambda, and avoid keeping them in session attributes longer than needed.
• Policy: declare the COPPA setting correctly, and review AWS Artifact for current compliance programs such as HIPAA eligibility.

You can also use an AWS Organizations AI services opt-out policy if you don't want content used to improve AWS AI services.

They share technology but target different experiences.

Pick Lex when the bot lives in your product or contact center. Pick the Alexa Skills Kit when you want to reach people through Alexa-enabled devices.

One turn runs from the user's input to the bot's reply. If the input is audio, Lex first transcribes it with ASR. The text is then passed to the NLU model, which ranks the intents and fills any slots it can detect.

If a dialog code hook is enabled, Lex calls Lambda with the interpretations and current session state. Lambda can accept the proposed step, re-ask for a slot, or move to confirmation. Lex then picks the next prompt: ask for the next missing slot, ask for confirmation, or proceed.

Once all required slots are filled and confirmed, Lex calls the fulfillment code hook, takes its result, and sends the closing message back. If the reply is spoken, Amazon Polly voices create the audio.

sequenceDiagram
  participant U as User or app
  participant L as Amazon Lex
  participant F as Lambda dialog hook
  participant E as Lambda fulfillment hook
  U->>L: Text or audio input
  L->>L: ASR (if audio) then NLU intent and slots
  L->>F: Event with interpretations and session state
  F-->>L: dialogAction (Delegate or ElicitSlot)
  L-->>U: Prompt for next slot or confirmation
  U->>L: Next input
  L->>E: Fulfillment event when slots are complete
  E-->>L: Close with state Fulfilled
  L-->>U: Closing message (text or Polly audio)

Lex sends your function an event and expects a response that tells it what to do next. The event includes invocationSource, inputTranscript, interpretations, proposedNextState and sessionState with the intent, slots and attributes.

The response steers the conversation through sessionState.dialogAction.type:

{
  "sessionState": {
    "dialogAction": {"type": "Close"},
    "intent": {"name": "BookHotel", "state": "Fulfilled"}
  },
  "messages": [{"contentType": "PlainText",
                "content": "Your room is booked."}]
}

Always echo back the slots and session attributes you want kept, because Lex uses what you return as the new state. Lambda can also return several messages in one reply, for example a confirmation sentence followed by a follow-up question.

While Lex is collecting a slot, it first tries to read the user's reply as the answer to that slot. If the reply doesn't fit and another intent scores above the confidence threshold, Lex treats it as a request to switch intents.

For example, a user booking a hotel says "actually, what's my order status?". The active intent becomes OrderStatus and Lex starts collecting its slots.

A dialog code hook sees what Lex proposes in proposedNextState. It can accept the switch with Delegate, or hold the user in the current intent by returning ElicitSlot or ConfirmIntent.

Don't assume the earlier intent's slots come back automatically. If you want to resume the booking later, save the values in session attributes before allowing the switch.

A normal fulfillment Lambda call is synchronous and has a short response window, so a slow backend can leave the caller in silence or cause a timeout. There are two ways to deal with it.

1. Fulfillment progress updates. Configure a start message such as "Let me check that for you", and optional update messages that repeat while the function is still running. Lex keeps the conversation alive and plays them until Lambda returns. This is aimed at voice, so confirm that your channel supports it.

2. Go asynchronous. Have Lambda start the work in Step Functions or push a message to SQS, then return immediately with a message like "I'll text you when it's done". Store a job ID in a session attribute if the user may ask about it later.

Pick progress updates when the wait is a few seconds to a minute and the caller expects an answer on the line. Pick the async route when the task can take minutes, or when the result is delivered by another channel.

Most accuracy problems come from the training phrases rather than from Lex itself.

1. Add varied utterances. Use real wording from logs or transcripts, including short, long and messy phrasing.
2. Remove overlap. If two intents share near-identical utterances, merge them or sharpen the difference.
3. Mix slot and non-slot utterances so Lex learns both "book a room" and "book a room in {City}".
4. Keep intents balanced. One intent with 80 utterances and another with 3 skews matching.
5. Use contexts to limit which intents are eligible at a given step.
6. Tune the threshold after looking at how scores are distributed.
7. Test with a fixed test set after each change and review missed utterances from production.

Rebuild the locale after any change, otherwise you're still testing the old model.

Work from the evidence outward.

1. Read the transcripts. Check the conversation logs. For voice, is the transcription itself wrong, or is the text fine but unmatched?
2. Look at the scores. In the Lambda event, interpretations shows the top candidates. Many scores just under the threshold suggest a threshold or training issue.
3. Confirm the build. Make sure the locale was rebuilt and that the alias points at the version you think it does.
4. Check for overlap. Two similar intents can split the score so neither passes.
5. Check slot types. A restricted custom slot that rejects a valid value may re-prompt repeatedly and look like a failing bot.
6. Check the language. Users speaking another language than the locale will always miss.

Fix the highest-volume missed phrases first, add them to the right intent, rebuild, and rerun your test set.

The Test Workbench lets you run repeatable regression tests on a bot instead of typing phrases into the test window by hand.

You create a test set, a file of inputs with the intent and slot values you expect. Test sets can use text, and also recorded audio when you want to test speech recognition. You then run a test execution against a chosen bot alias and locale.

The results show pass or fail per input along with overall accuracy for intents and slots, so you can see exactly which utterances regressed after a change.

Run it before publishing a new version and keep the test set in source control next to the bot definition. It is a good gate in a CI pipeline.

Spoken codes like "B7X-4Q2" are hard for ASR because letters sound alike, such as B, D and P. Lex V2 helps with spelling-based slot capture, where the caller spells the value letter by letter, or word by word like "B as in Bravo".

The setup:

• Use a suitable slot type such as AMAZON.AlphaNumeric, or a regex slot type if the format is fixed.
• Turn on spelling support for the slot, and make the prompt tell the caller how to speak it: "Please spell your confirmation code, one letter or number at a time."
• Add a confirmation step that reads the captured value back.
• For phone calls, accept DTMF for digits-only IDs.

Also consider validating against your backend in the dialog hook, so a wrong ID is caught immediately. Spelling support is available for selected languages, so confirm yours in the documentation.

Add one locale per language to the same bot. Each locale has its own intents, utterances, slot types, prompts and voice, but they share versions and aliases, so you deploy them together.

A few rules keep it maintainable:

• Use the same intent and slot names in every locale, so your Lambda logic doesn't branch per language.
• Write utterances natively. Machine-translated phrases rarely match how people speak.
• Localize slot type values and synonyms, such as room types or city names.
• Choose a suitable voice and NLU threshold per locale.
• In Lambda, read bot.localeId from the event to pick response text, dates and number formats.

Lex doesn't detect the user's language for you. Let the client choose the locale, or ask the caller to pick one in a menu before routing.

Both can power a conversational assistant, but they work on different principles.

They aren't exclusive. A common pattern is Lex as the voice and channel front door for structured intents, with a generative step behind it for open-ended questions.

The practical test is how much freedom you want. If a wrong action is expensive, such as moving money, prefer the explicit slots and confirmation that Lex gives you. If the task is exploratory, an agent's flexibility is worth the extra testing effort.

AMAZON.QnAIntent answers a user's question from your own content, using a foundation model to write the answer instead of returning a canned FAQ line.

You connect it to a knowledge source, such as an Amazon Bedrock knowledge base, an Amazon Kendra index or Amazon OpenSearch, and choose a Bedrock model. At runtime Lex retrieves relevant passages and the model composes a response grounded in them.

It behaves like a smarter fallback: when no transactional intent matches, the question goes to the knowledge source. You can add Bedrock guardrails to limit what the bot will say.

Keep transaction-style intents as normal intents with slots, because you want deterministic fulfillment for those. Also test the answers against your documents, since the output is only as good as the content and retrieval behind it.

flowchart LR
  U["User question"] --> N{Matches a custom intent?}
  N -- Yes --> I["Run that intent with slots and fulfillment"]
  N -- No --> Q["AMAZON.QnAIntent"]
  Q --> R["Retrieve passages from knowledge source"]
  R --> M["Bedrock model writes grounded answer"]
  M --> A["Reply to user"]

Combine three sources.

• Amazon CloudWatch metrics and alarms. Watch request volume, latency and error counts, and alarm on spikes. Monitor your fulfillment Lambda's duration and errors as well, since it is often the real bottleneck.
• Conversation logs. Text in CloudWatch Logs and audio in S3. These let you read real exchanges and find missed utterances.
• The Analytics dashboards in the Lex console. These show intents hit, utterances detected and missed, and how conversations progressed.

Track a few business KPIs on top: containment (conversations resolved without a human), fallback rate, abandonment, and average turns per task. A rising fallback rate or longer conversations are early signs that new phrasing needs to be added.

Review the top missed utterances on a regular schedule, add them to the right intent, run your test set, and release a new version.

Lex is pay-as-you-go with no upfront fee. Text and speech requests are billed per request, and streaming conversations are billed per short time segment of audio. Optional features such as the Automated Chatbot Designer and generative AI capabilities are charged separately. Check the AWS pricing page for current rates and the free tier.

Lex is only one line on the bill. Lambda, Polly, Connect telephony, Kendra and Bedrock are billed on their own.

Ways to keep cost down:

• Use text channels where voice isn't needed.
• Reduce turns per task with good prompts and multi-slot utterances.
• Don't send automated or health-check traffic to a production alias.
• Pick the cheapest suitable knowledge source and model for QnA features.

Set a budget alarm in AWS Budgets and tag the bot's resources, so a runaway loop in a client app shows up quickly instead of at month end.