# Built-in intents For common actions, you can use the standard built-in intents library. To create an intent from a built-in intent, choose a built-intent in the console, and give it a new name. The new intent has the configuration of the base intent, such as the sample utterances. In the current implementation, you can't do the following: + Add or remove sample utterances from the base intent + Configure slots for built-in intents **To add a built-in intent to a bot** 1. Sign in to the AWS Management Console and open the Amazon Lex console at [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/). 1. Choose the bot to add the built-in intent to. 1. In the left menu, choose the language and then choose **Intents**. 1. Choose **Add intent**, and then choose **Use built-in intent**. 1. In **Built-in intent**, choose the intent to use. 1. Give the intent a name, and then choose **Add**. 1. Use the intent editor to configure the intent as required for your bot. **Topics** + [AMAZON.BedrockAgentIntent](built-in-intent-bedrockagent.md) + [AMAZON.CancelIntent](built-in-intent-cancel.md) + [AMAZON.FallbackIntent](built-in-intent-fallback.md) + [AMAZON.HelpIntent](built-in-intent-help.md) + [AMAZON.KendraSearchIntent](built-in-intent-kendra-search.md) + [AMAZON.PauseIntent](built-in-intent-pause.md) + [AMAZON.QnAIntent](built-in-intent-qna.md) + [AMAZON.QnAIntent (multiple use support)](built-in-intent-qna-multi.md) + [AMAZON.QinConnectIntent](built-in-intent-qinconnect.md) + [AMAZON.RepeatIntent](built-in-intent-repeat.md) + [AMAZON.ResumeIntent](built-in-intent-resume.md) + [AMAZON.StartOverIntent](built-in-intent-start-over.md) + [AMAZON.StopIntent](built-in-intent-stop.md) # AMAZON.BedrockAgentIntent **Note** Before you can take advantage of the generative AI features, you must fulfill the following prerequisites For information about pricing for using Amazon Bedrock, see [Amazon Bedrock pricing](https://aws.amazon.com/bedrock/pricing/). Turn on the generative AI capabilities for your bot locale. To do so, follow the steps at [Optimize Lex V2 bot creation and performance by using generative AI](generative-features.md). Activates Amazon Bedrock Agents that are defined in the intent to respond to customer requests and activate agentic workflows to achieve the task defined. This feature is available in all Amazon Lex V2 supported locales and all commercial regions where both Amazon Lex V2 and Amazon Bedrock Agents are present. If this intent is overriding `FallbackIntent`, the intent is activated when an utterance is not classified into any of the other intents present in the bot, otherwise it is only activated when an utterance is classified into this intent. It’s important to note that this intent will not be activated for missed utterances when eliciting a slot value. Once recognized by your Amazon Lex V2 bot, the `AMAZON.BedrockAgentIntent`, activates the defined `BedrockAgent` or `BedrockKnowledgeBase` to respond to the customer. If you are using Amazon Bedrock Agents, the conversation stays in the `BedrockAgentIntent` and the user requests are relayed to Agents, until the Amazon Bedrock Agent determines that the conversation is marked `FINISH`. Only after that, Amazon Lex V2 assumes control of the conversation and adheres to next steps defined in the `AMAZON.BedrockAgentIntent`. Responds to customer questions by using an Amazon Bedrock Agents and Knowledge Bases to answer customer questions and provide detailed responses. **Warning** You can't use the `AMAZON.BedrockAgentIntent` without sample utterances, `AMAZON.QnAIntent` without sample utterances and the `AMAZON.KendraSearchIntent` in the same bot locale. If you select this intent, you configure the following fields and then select Add to add the intent. + Amazon Bedrock Agent Id - The identifier of the Amazon Bedrock Agent. Choose the Bedrock Agent that you want to use. + Amazon Bedrock Agent Alias Id - The Alias identifier of the Amazon Bedrock Agent. **Important** When creating the Amazon Bedrock Agent to be used with Amazon Lex V2, verify that **User Input** under **Additional Settings** is `ENABLED`. This setting is critical to allow Agents to ask clarifying or follow-up questions, and it allows Amazon Lex V2 to delegate back to Agents to complete the corresponding task. (Optional) You can also add a BedrockAgentIntent with these options: + Amazon Bedrock model - Choose the provider and foundation model to use for this intent. Currently, some Anthropic Claude models are supported. + Amazon Bedrock Knowledge Base - If you choose this option, specify the ID of the Amazon Bedrock Knowledge Base. You can find the ID by checking the details page of the Amazon Bedrock Knowledge Base in the console, or by sending a `GetKnowledgeBase` request. The responses from the BedrockAgentIntent will be stored into the session and request attributes as shown below: + `x-amz-lex:bedrock-agent-search-response` – The response from the Amazon Bedrock Agent to the question or utterance. + `x-amz-lex:bedrock-knowledge-base-search-response-source` – Points to the document, or list of documents, used to generate the response if using the Amazon Bedrock Knowledge Base configuration. + `x-amz-lex:bedrock-agent-action-group-invocation-input` - Object containing input values collected by the agent action group. For more information on agent action groups, see ActionGroupInvocationInput. + `x-amz-lex:bedrock-agent-knowledge-base-lookup-input` - Object containing the Amazon Bedrock Knowledge Base lookup related details. + `x-amz-lex:bedrock-agent-agent-collaborator-details` – Object containing details of the input and output from the sub agents that were invoked as part of Multi-agent collaboration invocations. For more information, see [Using BedrockAgentIntent to use a Bedrock Agent in Amazon Lex](https://docs.aws.amazon.com/lexv2/latest/dg/bedrock-agent-intent.html). # AMAZON.CancelIntent Responds to words and phrases that indicate the user wants to cancel the current interaction. Your application can use this intent to remove slot type values and other attributes before ending the interaction with the user. Common utterances: + cancel + never mind + forget it # AMAZON.FallbackIntent When a user's input to an intent isn't what a bot expects, you can configure Amazon Lex V2 to invoke a *fallback intent*. For example, if the user input "I'd like to order candy" doesn't match an intent in your `OrderFlowers` bot, Amazon Lex V2 invokes the fallback intent to handle the response. The built-in `AMAZON.FallbackIntent` intent type is added to your bot automatically when you create a bot using the console or when you add a locale to a bot using the [CreateBotLocale](https://docs.aws.amazon.com/lexv2/latest/APIReference/API_CreateBotLocale.html) operation. Invoking a fallback intent uses two steps. In the first step the fallback intent is matched based on the input from the user. When the fallback intent is matched, the way the bot behaves depends on the number of retries configured for a prompt. Amazon Lex V2 matches the fallback intent in these situations: + The user's input to an intent doesn't match the input that the bot expects + Audio input is noise, or text input isn't recognized as words. + The user's input is ambiguous and Amazon Lex V2 can't determine which intent to invoke. The fallback intent is invoked when: + An intent doesn't recognize the user input as a slot value after the configured number of tries. + An intent doesn't recognize the user input as a response to a confirmation prompt after the configured number of tries. You can't add the following to a fallback intent: + Utterances + Slots + A confirmation prompt ## Using a Lambda Function with a Fallback Intent When a fallback intent is invoked, the response depends on the setting of the `fulfillmentCodeHook` parameter to the [CreateIntent](https://docs.aws.amazon.com/lexv2/latest/APIReference/API_CreateIntent.html) operation. The bot does one of the following: + Returns the intent information to the client application. + Calls the alias's validation and fulfillment Lambda function. It calls the function with the session variables that are set for the session. For more information about setting the response when a fallback intent is invoked, see the `fulfillmentCodeHook` parameter of the [CreateIntent](https://docs.aws.amazon.com/lexv2/latest/APIReference/API_CreateIntent.html) operation. If you use the Lambda function with your fallback intent, you can use this function to call another intent or to perform some form of communication with the user, such as collecting a callback number or opening a session with a customer service representative. A fallback intent can be invoked multiple times in the same session. For example, suppose that your Lambda function uses the `ElicitIntent` dialog action to prompt the user for a different intent. If Amazon Lex V2 can't infer the user's intent after the configured number of tries, it invokes the fallback intent again. It also invokes the fallback intent when the user doesn't respond with a valid slot value after the configured number of tries. You can configure your Lambda function to keep track of the number of times that the fallback intent is called using a session variable. Your Lambda function can take a different action if it is called more times than the threshold that you set in your Lambda function. For more information about session variables, see [Setting session attributes for your Lex V2 bot](context-mgmt-session-attribs.md). # AMAZON.HelpIntent Responds to words or phrases that indicate the user needs help while interacting with your bot. When this intent is invoked, you can configure your Lambda function or application to provide information about the your bot's capabilities, ask follow up questions about areas of help, or hand the interaction over to a human agent. Common utterances: + help + help me + can you help me # AMAZON.KendraSearchIntent To search documents that you have indexed with Amazon Kendra, use the `AMAZON.KendraSearchIntent` intent. When Amazon Lex V2 can't determine the next action in a conversation with the user, it triggers the search intent. The `AMAZON.KendraSearchIntent` is available only in the English (US) (en-US) locale and in the US East (N. Virginia), US West (Oregon) and Europe (Ireland) Regions. Amazon Kendra is a machine-learning-based search service that indexes natural language documents such as PDF documents or Microsoft Word files. It can search indexed documents and return the following types of responses to a question: + An answer + An entry from a FAQ that might answer the question + A document that is related to the question For an example of using the `AMAZON.KendraSearchIntent`, see [Example: Creating a FAQ Bot for an Amazon Kendra Index](faq-bot-kendra-search.md). If you configure an `AMAZON.KendraSearchIntent` intent for your bot, Amazon Lex V2 calls the intent whenever it can't determine the user utterance for an intent. If there is no response from Amazon Kendra, the conversation continues as configured in the bot. **Note** Amazon Lex V2 currently does not support the `AMAZON.KendraSearchIntent` during slot elicitation. If Amazon Lex V2 can't determine the user utterance for a slot, it calls the `AMAZON.FallbackIntent`. When you use the `AMAZON.KendraSearchIntent` with the `AMAZON.FallbackIntent` in the same bot, Amazon Lex V2 uses the intents as follows: 1. Amazon Lex V2 calls the `AMAZON.KendraSearchIntent`. The intent calls the Amazon Kendra `Query` operation. 1. If Amazon Kendra returns a response, Amazon Lex V2 displays the result to the user. 1. If there is no response from Amazon Kendra, Amazon Lex V2 re-prompts the user. The next action depends on response from the user. + If the response from the user contains an utterance that Amazon Lex V2 recognizes, such as filling a slot value or confirming an intent, the conversation with the user proceeds as configured for the bot. + If the response from the user does not contain an utterance that Amazon Lex V2 recognizes, Amazon Lex V2 makes another call to the `Query` operation. 1. If there is no response after the configured number of retries, Amazon Lex V2 calls the `AMAZON.FallbackIntent` and ends the conversation with the user. There are three ways to use the `AMAZON.KendraSearchIntent` to make a request to Amazon Kendra: + Let the search intent make the request for you. Amazon Lex V2 calls Amazon Kendra with the user's utterance as the search string. When you create the intent, you can define a query filter string that limits the number of responses that Amazon Kendra returns. Amazon Lex V2 uses the filter in the query request. + Add additional query parameters to the request to narrow the search results using your Lambda function. You add a `kendraQueryFilterString` field that contains Amazon Kendra query parameters to the `delegate` dialog action. When you add query parameters to the request with the Lambda function, they take precedence over the query filter that you defined when you created the intent. + Create a new query using the Lambda function. You can create a complete Amazon Kendra query request that Amazon Lex V2 sends. You specify the query in the `kendraQueryRequestPayload` field in the `delegate` dialog action. The `kendraQueryRequestPayload` field takes precedence over the `kendraQueryFilterString` field. To specify the `queryFilterString` parameter when you create a bot, or to specify the `kendraQueryFilterString` field when you call the `delegate` action in a dialog Lambda function, you specify a string that is used as the attribute filter for the Amazon Kendra query. If the string isn't a valid attribute filter, you'll get an `InvalidBotConfigException` exception at runtime. For more information about attribute filters, see [Using document attributes to filter queries](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering) in the *Amazon Kendra Developer Guide*. To have control over the query that Amazon Lex V2 sends to Amazon Kendra, you can specify a query in the `kendraQueryRequestPayload`field in your Lambda function. If the query isn't valid, Amazon Lex V2 returns an `InvalidLambdaResponseException` exception. For more information, see the [Query operation](https://docs.aws.amazon.com/kendra/latest/dg/API_Query.html) in the *Amazon Kendra Developer Guide*. For an example of how to use the `AMAZON.KendraSearchIntent`, see [Example: Creating a FAQ Bot for an Amazon Kendra Index](faq-bot-kendra-search.md). ## IAM Policy for Amazon Kendra Search To use the `AMAZON.KendraSearchIntent` intent, you must use a role that provides AWS Identity and Access Management (IAM) policies that enable Amazon Lex V2 to assume a runtime role that has permission to call the Amazon Kendra `Query` intent. The IAM settings that you use depend on whether you create the `AMAZON.KendraSearchIntent` using the Amazon Lex V2 console, or using an AWS SDK or the AWS Command Line Interface (AWS CLI). When you use the console, you can choose between adding permission to call Amazon Kendra to the Amazon Lex V2 service-linked role or using a role specifically for calling the Amazon Kendra `Query` operation. When you use the AWS CLI or an SDK to create the intent, you must use a role specifically for calling the `Query` operation. ### Attaching Permissions You can use the console to attach permissions to access the Amazon Kendra `Query` operation to the default Amazon Lex V2 service-linked role. When you attach permissions to the service-linked role, you don't have to create and manage a runtime role specifically to connect to the Amazon Kendra index. The user, role, or group that you use to access the Amazon Lex V2 console must have permissions to manage role policies. Attach the following IAM policy to the console access role. When you grant these permissions, the role has permissions to change the existing service-linked role policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:AttachRolePolicy", "iam:PutRolePolicy", "iam:GetRolePolicy" ], "Resource": "arn:aws:iam::*:role/aws-service-role/lexv2.amazonaws.com/AWSServiceRoleForLexBots*" }, { "Effect": "Allow", "Action": "iam:ListRoles", "Resource": "*" } ] } ``` ------ ### Specifying a Role You can use the console, the AWS CLI, or the API to specify a runtime role to use when calling the Amazon Kendra `Query` operation. The user, role, or group that you use to specify the runtime role must have the `iam:PassRole` permission. The following policy defines the permission. You can use the `iam:AssociatedResourceArn` and `iam:PassedToService` condition context keys to further limit the scope of the permissions. For more information, see [ IAM and AWS STS Condition Context Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html) in the *AWS Identity and Access Management User Guide*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/role" } ] } ``` ------ The runtime role that Amazon Lex V2 needs to use to call Amazon Kendra must have the `kendra:Query` permissions. When you use an existing IAM role for permission to call the Amazon Kendra `Query` operation, the role must have the following policy attached. You can use the IAM console, the IAM API, or the AWS CLI to create a policy and attach it to a role. These instructions use the AWS CLI to create the role and policies. **Note** The following code is formatted for Linux and MacOS. For Windows, replace the Linux line continuation character (\$1) with a caret (^). **To add Query operation permission to a role** 1. Create a document called **KendraQueryPolicy.json** in the current directory, add the following code to it, and save it 1. In the AWS CLI, run the following command to create the IAM policy for running the Amazon Kendra `Query` operation. ``` aws iam create-policy \ --policy-name query-policy-name \ --policy-document file://KendraQueryPolicy.json ``` 1. Attach the policy to the IAM role that you are using to call the `Query` operation. ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::account-id:policy/query-policy-name --role-name role-name ``` You can choose to update the Amazon Lex V2 service-linked role or to use a role that you created when you create the `AMAZON.KendraSearchIntent` for your bot. The following procedure shows how to choose the IAM role to use. **To specify the runtime role for AMAZON.KendraSearchIntent** 1. Sign in to the AWS Management Console and open the Amazon Lex console at [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/). 1. Choose the bot that you want to add the `AMAZON.KendraSearchIntent` to. 1. Choose the plus (\$1) next to **Intents**. 1. In **Add intent**, choose **Search existing intents**. 1. In **Search intents**, enter **AMAZON.KendraSearchIntent** and then choose **Add**. 1. In **Copy built-in intent**, enter a name for the intent, such as **KendraSearchIntent**, and then choose **Add**. 1. Open the **Amazon Kendra query** section. 1. For **IAM role** choose one of the following options: + To update the Amazon Lex V2 service-linked role to enable your bot to query Amazon Kendra indexes, choose **Add Amazon Kendra permissions**. + To use a role that has permission to call the Amazon Kendra `Query` operation, choose **Use an existing role**. ## Using Request and Session Attributes as Filters To filter the response from Amazon Kendra to items related to current conversation, use session and request attributes as filters by adding the `queryFilterString` parameter when you create your bot. You specify a placeholder for the attribute when you create the intent, and then Amazon Lex V2 substitutes a value before it calls Amazon Kendra. For more information about request attributes, see [Setting request attributes for your Lex V2 bot](context-mgmt-request-attribs.md). For more information about session attributes, see [Setting session attributes for your Lex V2 bot](context-mgmt-session-attribs.md). The following is an example of a `queryFilterString` parameter that uses a string to filter the Amazon Kendra query. ``` "{"equalsTo": {"key": "City", "value": {"stringValue": "Seattle"}}}" ``` The following is an example of a `queryFilterString` parameter that uses a session attribute called `"SourceURI"` to filter the Amazon Kendra query. ``` "{"equalsTo": {"key": "SourceURI","value": {"stringValue": "[FileURL]"}}}" ``` The following is an example of a `queryFilterString` parameter that uses a request attribute called `"DepartmentName"` to filter the Amazon Kendra query. ``` "{"equalsTo": {"key": "Department","value": {"stringValue": "((DepartmentName))"}}}" ``` The `AMAZON.KendraSearchInteng` filters use the same format as the Amazon Kendra search filters. For more information, see [Using document attributes to filter search results](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering) in the *Amazon Kendra developer guide*. The query filter string used with the `AMAZON.KendraSearchIntent` must use lower-case letters for the first letter of each filter. For example, the following is a valid query filter for the `AMAZON.KendraSearchIntent`. ``` { "andAllFilters": [ { "equalsTo": { "key": "City", "value": { "stringValue": "Seattle" } } }, { "equalsTo": { "key": "State", "value": { "stringValue": "Washington" } } } ] } ``` ## Using the Search Response Amazon Kendra returns the response to a search in a response from the intent's `IntentClosingSetting` statement. The intent must have a `closingResponse` statement unless a Lambda function produces a closing response message. Amazon Kendra has five types of responses. + The following two responses require an FAQ to be set up for your Amazon Kendra index. For more details, see [Adding questions and answers directly to a index](https://docs.aws.amazon.com/kendra/latest/dg/in-creating-faq.html). + `x-amz-lex:kendra-search-response-question_answer-question-` – The question from a FAQ that matches the search. + `x-amz-lex:kendra-search-response-question_answer-answer-` – The answer from a FAQ that matches the search. + The following three responses require a data source to be set up for your Amazon Kendra index. For more details, see [Creating a data source](https://docs.aws.amazon.com/kendra/latest/dg/data-source.html). + `x-amz-lex:kendra-search-response-document-` – An excerpt from a document in the index that is related to the text of the utterance. + `x-amz-lex:kendra-search-response-document-link-` – The URL of a document in the index that is related to the text of the utterance. + `x-amz-lex:kendra-search-response-answer-` – An excerpt from a document in the index that answers the question. The responses are returned in `request` attributes. There can be up to five responses for each attribute, numbered 1 through 5. For more information about responses, see [Types of response](https://docs.aws.amazon.com/kendra/latest/dg/response-types.html) in the *Amazon Kendra Developer Guide*. The `closingResponse` statement must have one or more message groups. Each message group contains one or more messages. Each message can contain one or more placeholder variables that are replaced by request attributes in the response from Amazon Kendra. There must be at least one message in the message group where all of the variables in the message are replaced by request attribute values in the runtime response, or there must be a message in the group with no placeholder variables. The request attributes are set off with double parentheses ("((" "))"). The following message group messages match any response from Amazon Kendra: + “I found a FAQ question for you: ((x-amz-lex:kendra-search-response-question\$1answer-question-1)), and the answer is ((x-amz-lex:kendra-search-response-question\$1answer-answer-1))” + “I found an excerpt from a helpful document: ((x-amz-lex:kendra-search-response-document-1))” + “I think the answer to your questions is ((x-amz-lex:kendra-search-response-answer-1))” ## Using a Lambda Function to Manage the Request and Response The `AMAZON.KendraSearchIntent` intent can use your dialog code hook and fulfillment code hook to manage the request to Amazon Kendra and the response. Use the dialog code hook Lambda function when you want to modify the query that you send to Amazon Kendra, and the fulfillment code hook Lambda function when you want to modify the response. ### Creating a Query with the Dialog Code Hook You can use the dialog code hook to create a query to send to Amazon Kendra. Using the dialog code hook is optional. If you don't specify a dialog code hook, Amazon Lex V2 constructs a query from the user utterance and uses the `queryFilterString` that you provided when you configured the intent, if you provided one. You can use two fields in the dialog code hook response to modify the request to Amazon Kendra: + `kendraQueryFilterString` – Use this string to specify attribute filters for the Amazon Kendra request. You can filter the query using any of the index fields defined in your index. For the structure of the filter string, see [Using document attributes to filter queries](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering) in the *Amazon Kendra Developer Guide*. If the specified filter string isn't valid, you will get an `InvalidLambdaResponseException` exception. The `kendraQueryFilterString` string overrides any query string specified in the `queryFilterString` configured for the intent. + `kendraQueryRequestPayload` – Use this string to specify an Amazon Kendra query. Your query can use any of the features of Amazon Kendra. If you don't specify a valid query, you get a `InvalidLambdaResponseException` exception. For more information, see [Query](https://docs.aws.amazon.com/kendra/latest/dg/API_Query.html) in the *Amazon Kendra Developer Guide*. After you have created the filter or query string, you send the response to Amazon Lex V2 with the `dialogAction` field of the response set to `delegate`. Amazon Lex V2 sends the query to Amazon Kendra and then returns the query response to the fulfillment code hook. ### Using the Fulfillment Code Hook for the Response After Amazon Lex V2 sends a query to Amazon Kendra, the query response is returned to the `AMAZON.KendraSearchIntent` fulfillment Lambda function. The input event to the code hook contains the complete response from Amazon Kendra. The query data is in the same structure as the one returned by the Amazon Kendra `Query` operation. For more information, see [ Query response syntax](https://docs.aws.amazon.com/kendra/latest/dg/API_Query.html#API_Query_ResponseSyntax) in the *Amazon Kendra Developer Guide*. The fulfillment code hook is optional. If one does not exist, or if the code hook doesn't return a message in the response, Amazon Lex V2 uses the `closingResponse` statement for responses. # Example: Creating a FAQ Bot for an Amazon Kendra Index This example creates an Amazon Lex V2 bot that uses an Amazon Kendra index to provide answers to users' questions. The FAQ bot manages the dialog for the user. It uses the `AMAZON.KendraSearchIntent` intent to query the index and to present the response to the user. Here is a summary of how you will create your FAQ bot using an Amazon Kendra index: 1. Create a bot that your customers will interact with to get answers from your bot. 1. Create a custom intent. Because the `AMAZON.KendraSearchIntent` and `AMAZON.FallbackIntent` are backup intents, your bot requires at least one other intent that must contain least one utterance. This intent enables your bot to build, but is not used otherwise. Your FAQ bot will therefore contain at least three intents, as in the image below: ![\[A Kendra FAQ bot with three intents\]](http://docs.aws.amazon.com/lexv2/latest/dg/images/kendra-faqbot/kendra-intents.png) 1. Add the `AMAZON.KendraSearchIntent` intent to your bot and configure it to work with your [Amazon Kendra index](https://docs.aws.amazon.com/kendra/latest/dg/create-index.html). 1. Test the bot by making a query and verifying that the results from your Amazon Kendra index are documents that answer the query. **Prerequisites** Before you can use this example, you need to create an Amazon Kendra index. For more information, see [Getting started with the Amazon Kendra console](https://docs.aws.amazon.com/kendra/latest/dg/gs-console.html) in the *Amazon Kendra Developer Guide*. For this example, choose the sample dataset (**Sample AWS documentation**) as your data source. **To create a FAQ bot:** 1. Sign in to the AWS Management Console and open the Amazon Lex console at [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/). 1. In the navigation pane, choose **Bots**. 1. Choose **Create bot**. 1. For the **Creation method**, choose **Create a blank bot**. 1. In the **Bot configuration** section, give the bot a name that indicates its purpose, such as **KendraTestBot**, and an optional description. The name must be unique in your account. 1. In the **IAM Permissions** section, choose **Create a role with basic Amazon Lex permissions**. This will create an [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) role with the permissions that Amazon Lex V2 needs to run your bot. 1. In the **Children's Online Privacy Protection Act (COPPA)** section, choose **No**. 1. In the **Idle session timeout** and **Advanced settings** sections, leave the default settings and choose **Next**. 1. Now you are in the **Add language to bot** section. In the menu under **Voice interaction**, select **None. This is only a text based application**. Leave the default settings for the remaining fields. 1. Choose **Done**. Amazon Lex V2 creates your bot and a default intent called **NewIntent**, and takes you to the page to configure this intent To successfully build a bot, you must create at least one intent that is separate from the `AMAZON.FallbackIntent` and the `AMAZON.KendraSearchIntent`. This intent is required to build your Amazon Lex V2 bot, but isn't used for the FAQ response. This intent must contain at least one sample utterance and the utterance must not apply to any of the questions that your customer asks. **To create the required intent:** 1. In the **Intent details** section, give the intent a name, such as **RequiredIntent**. 1. In the **Sample utterances** section, type an utterance in the box next to **Add utterance**, such as **Required utterance**. Then choose **Add utterance**. 1. Choose **Save intent**. Create the intent to search an Amazon Kendra index and the response message that it should return. **To create an AMAZON.KendraSearchIntent intent and response message:** 1. Select **Back to intents list** in the navigation pane to return to the **Intents** page for your bot. Choose **Add intent** and select **Use built-in intent** from the dropdown menu. 1. In the box that pops up, select the menu under **Built-in intent.** Enter **AMAZON.KendraSearchIntent** in the search bar and then choose it from the list. 1. Give the intent a name, such as **KendraSearchIntent**. 1. From the **Amazon Kendra index** dropdown menu, choose the index that you want the intent to search. The index that you created in the **Prerequisites** section should be available. 1. Select **Add**. 1. In the intent editor, scroll down to the **Fulfillment** section, select the right arrow to expand the section, and add the following message in the box under **On successful fulfillment**: ``` I found a link to a document that could help you: ((x-amz-lex:kendra-search-response-document-link-1)). ``` ![\[Add the fulfillment response\]](http://docs.aws.amazon.com/lexv2/latest/dg/images/kendra-faqbot/kendra-fulfillment-response.gif) For more information about the Amazon Kendra Search Response, see [ Using the Search Response](https://docs.aws.amazon.com/lexv2/latest/dg/built-in-intent-kendra-search.html#kendra-search-response). 1. Choose **Save intent**, and then choose **Build** to build the bot. When the bot is ready, the banner at the top of the screen turns green and displays a success message. Finally, use the console test window to test responses from your bot. **To test your FAQ bot:** 1. After the bot is successfully built, choose **Test**. 1. Enter **What is Amazon Kendra?** in the console test window. Verify that the bot responds with a link. 1. For more information about configuring `AMAZON.KendraSearchIntent`, see [https://docs.aws.amazon.com/lexv2/latest/dg/built-in-intent-kendra-search.html](https://docs.aws.amazon.com/lexv2/latest/dg/built-in-intent-kendra-search.html) and [KendraConfiguration](https://docs.aws.amazon.com/lexv2/latest/APIReference/API_KendraConfiguration.html). # AMAZON.PauseIntent Responds to words and phrases that enable the user to pause an interaction with a bot so that they can return to it later. Your Lambda function or application needs to save intent data in session variables, or you need to use the [GetSession](https://docs.aws.amazon.com/lexv2/latest/APIReference/API_runtime_GetSession.html) operation to retrieve intent data when you resume the current intent. Common utterances: + pause + pause that # AMAZON.QnAIntent **Note** Before you can take advantage of the generative AI features, you must fulfill the following prerequisites For information about pricing for using Amazon Bedrock, see [Amazon Bedrock pricing](https://aws.amazon.com/bedrock/pricing/). Turn on the generative AI capabilities for your bot locale. To do so, follow the steps at [Optimize Lex V2 bot creation and performance by using generative AI](generative-features.md). Responds to customer questions by using an Amazon Bedrock FM to search and summarize FAQ responses. This intent is activated when an utterance is not classified into any of the other intents present in the bot. Note that this intent will not be activated for missed utterances when eliciting a slot value. Once recognized, the `AMAZON.QnAIntent`, uses the specified Amazon Bedrock model to search the configured Amazon Bedrock Knowledge Base and respond to the customer question. **Warning** You can't use the `AMAZON.QnAIntent` and the `AMAZON.KendraSearchIntent` in the same bot locale. The following knowledge store options are available. You must have already created the knowledge store and indexed the documents within it. + OpenSearch Service domain – Contains indexed documents. To create a domain, follow the steps at [Creating and managing Amazon OpenSearch Service domains](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html). + Amazon Kendra index – Contains indexed FAQ documents. To create a Amazon Kendra index, follow the steps at [Creating an index](https://docs.aws.amazon.com/kendra/latest/dg/create-index.html). + Amazon Bedrock Knowledge Base – Contains indexed data sources. To set up a Amazon Bedrock Knowledge Base, follow the steps at [Building a Knowledge Base](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html). If you select this intent, you configure the following fields and then select **Add** to add the intent. + **Bedrock model** – Choose the provider and foundation model to use for this intent. Make sure to check the latest available models and the deprecation schedule and plan migrations accordingly. For more information, see [Model lifecycle](https://docs.aws.amazon.com/bedrock/latest/userguide/model-lifecycle.html#versions-for-eol). + **Knowledge store** – Choose the source from which you want the model pull information from to answer customer questions. The following sources are available. + **OpenSearch** – Configure the following fields. + **Domain endpoint** – Provide the domain endpoint that you made for the domain or that was provided to you after domain creation. + **Index name** – Provide the index to search. For more information, see [Indexing data in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/indexing.html). + Choose how you want to return the response to the customer. + **Exact response** – When this option is enabled, the value in the Answer field is used as is for the bot response. The configured Amazon Bedrock foundation model is used to select the exact answer content as-is, without any content synthesis or summarization. Specify the name of the question and answer fields that were configured in the OpenSearch database. + **Include fields** – Returns an answer generated by the model using the fields you specify. Specify the name of up to five fields that were configured in the OpenSearch database. Use a semicolon (;) to separate fields. + **Amazon Kendra** – Configure the following fields. + **Amazon Kendra index** – Select the Amazon Kendra index that you want your bot to search. + **Amazon Kendra filter** – To create a filter, select this checkbox. For more information on the Amazon Kendra search filter JSON format, see [Using document attributes to filter search results](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering). + **Exact response** – To let your bot return the exact response returned by Amazon Kendra, select this checkbox. Otherwise, the Amazon Bedrock model you select generates a response based on the results. **Note** To use this feature, you must first add FAQ questions to your index by following the steps at [Adding frequently asked questions (FAQs) to an index](https://docs.aws.amazon.com/kendra/latest/dg/in-creating-faq.html). + **Amazon Bedrock Knowledge Base** – If you choose this option, specify the ID of the Amazon Bedrock Knowledge Base. You can find the ID by checking the details page of the Amazon Bedrock Knowledge Base in the console, or by sending a [GetKnowledgeBase](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_GetKnowledgeBase.html) request. + **Exact response** – When this option is enabled, the value in the Answer field is used as is for the bot response. The configured Amazon Bedrock foundation model is used to select the exact answer content as-is, without any content synthesis or summarization. To use exact response for Amazon Bedrock Knowledge Base you need to do the following: + Create individual JSON files with each file containing an answer field that contains the exact response that needs to be returned to end-user. + When indexing these documents in Bedrock Knowledge Base, select **Chunking strategy** as **No Chunking**.. + Define the answer field in Amazon Lex V2, as the Answer field in the Bedrock Knowledge Base. The responses from the QnAIntent will be stored into the request attributes as shown below: + `x-amz-lex:qnA-search-response` – The response from the QnAIntent to the question or utterance. + `x-amz-lex:qnA-search-response-source` – Points to the document or list of documents used to generate the response. + `x-amz-lex:qna-additional-context` – The additional context used by the QnAIntent to generate the response. **Additional model configurations** When AMAZON.QnAIntent is invoked it uses a default prompt template that combines instructions and context with the user query to construct the prompt that’s sent to the model for response generation. You can also provide a custom prompt or update the default prompt to match your requirements. You can engineer the prompt template with the following tools: **Prompt placeholders** – Pre-defined variables in AMAZON.QnAIntent for Amazon Bedrock that are dynamically filled in at runtime during the bedrock call. In the system prompt, you can see these placeholders surrounded by the `$` symbol. The following list describes the placeholders you can use: | Variable | Replaced by | Model | Required? | | --- | --- | --- | --- | | \$1query\$1results\$1 | The retrieved results for the user query from the Knowledge Store | Selected Bedrock Model | Yes | | \$1output\$1instruction\$1 | Underlying instructions for formatting the response generation and citations. Differs by model. If you define your own formatting instructions, we suggest that you remove this placeholder. | Selected Bedrock Model | No | | \$1additional\$1context\$1 | The additional context used by the QnAIntent to generate the response | Selected Bedrock Model | No | | \$1locale\$1 | The language in which the bot will answer customer queries | Selected Bedrock Model | No | **Default prompt** being used is: ``` $query_results$ $additional_context$ Please only follow the instructions in tags below. Given the conversation history, and : (1) first, identify the user query intent and classify it as one of the categories: FAQ_QUERY, OTHER_QUERY, GIBBERISH, GREETINGS, AFFIRMATION, CHITCHAT, or MISC; (2) second, if the intent is FAQ_QUERY, predict the most relevant grounding passage(s) by providing the passage id(s) or output CANNOTANSWER; (3) then, generate a concise, to-the-point FAQ-style response in $locale$ locale ONLY USING the grounding content in and ; or output CANNOTANSWER if the user query/request cannot be directly answered with the grounding content. DO NOT mention about the grounding passages such as ids or other meta data; do not create new content not presented in . Do NOT respond to query that is ill-intented or off-topic; (4) lastly, provide the confidence level of the above prediction as LOW, MID or HIGH. $output_instruction$ ``` **\$1output\$1instruction\$1** is replaced with: ``` Give your final response in the following form: FAQ_QUERY or OTHER_QUERY or GIBBERISH or GREETINGS or AFFIRMATION or CHITCHAT or MISC a concise FAQ-style response or CANNOTANSWER passage_id or CANNOTANSWER LOW or MID or HIGH ``` **Note** If you decide not to use the default instructions, then whatever output the LLM provides will be returned as-is back to the end user. The output instructions need to contain and tags and instructions for the LLM to return the passageIds to provide the response and source attribution. **Additional context support through session attributes** You can pass additional context to the `AMAZON.QnAIntent` at runtime through the session attribute `x-amz-lex:qna-additional-context`. This allows you to provide supplementary information that the model can use alongside the knowledge store results when generating a response. The additional context is inserted into the prompt template through the `$additional_context$` placeholder. **Example:** ``` {"sessionAttributes": {"x-amz-lex:qna-additional-context":"Our support hours are Monday through Friday, 8AM-8PM EST"}} ``` **Amazon Bedrock Knowledge Base metadata filtering support through session attributes** You can pass the Amazon Bedrock Knowledge Base metadata filters as part of session attribute `x-amz-lex:bkb-retrieval-filter`. ``` {"sessionAttributes":{"x-amz-lex:bkb-retrieval-filter":"{\"equals\":{\"key\":\"insurancetype\",\"value\":\"farmers\"}} ``` **Note** You need to use the Amazon Bedrock Knowledge Base as the Data store for the QnAIntent to use this filter. For more information, see [https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-config.html#:~:text=Metadata%20and%20filtering](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-config.html#:~:text=Metadata%20and%20filtering) **Inference configurations** You can define the inference configurations that will be used when making the call to LLM using session attribute: + temperature: type Integer + topP + maxTokens **Example:** ``` {"sessionAttributes":{"x-amz-lex:llm-text-inference-config":"{\"temperature\":0,\"topP\":1,\"maxTokens\":200}"}} ``` **Bedrock Guardrails support through build-time and session attributes** + By using the Console at Buildtime – Provide the GuardrailsIdentifier and the GuardrailsVersion. Learn more under the Additional Model Configurations section. + By using Session attributes – You can also define the Guardrails configuration using the session attributes: `x-amz-lex:bedrock-guardrails-identifier` and `x-amz-lex:bedrock-guardrails-version`. For more information on using Bedrock Guardrails, see [ Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html). # AMAZON.QnAIntent (multiple use support) You can choose to have multiple AMAZON.QnAIntents within a locale. Amazon Lex V2 support up to 5 AMAZON.QnAIntents within a bot locale. AMAZON.QnAIntent can be triggered if one of the following cases is true: + If a bot locale contains only 1 AMAZON.QnAIntent and that intent does not contain sample utterances, then it is activated when an utterance is not classified into any of the other intents present in the bot. This intent is activated when an utterance is not classified into any of the other intents present in the bot. Note that this intent will not be activated for missed utterances when eliciting a slot value. **Note** If the response from the FM is unsatisfactory or the call to the FM fails, Amazon Lex V2 then invokes the `AMAZON.FallbackIntent`. + If AMAZON.QnAIntent does contain sample utterances, then it is only activated when Amazon Lex V2 recognizes that the user wants to initiate that intent based on user input. **Note** If the response from the FM is unsatisfactory or the call to the FM fails, Amazon Lex V2 invokes the failure next step, defined in the fulfillment block. **Note** If `botLocale` has more than 1 AMAZON.QnAIntent, then each AMAZON.QnAIntent needs to have at least 1 sample utterance. # AMAZON.QinConnectIntent **Note** To use generative AI capabilities using Amazon Q In Connect, you must complete the following pre-requisites: Navigate to the Amazon Connect console and create your instance, if you don't have one already, see [Get started with Amazon Connect](https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-get-started.html). Enable Amazon Q in Connect for your instance, see [Enable Amazon Q in Connect for your instance](https://docs.aws.amazon.com/connect/latest/adminguide/enable-q.html). AMAZON.QinConnectIntent responds to customer questions by using the LLM-enhanced evolution of Amazon Connect Wisdom that delivers real-time recommendations to help contact center customers and agents resolve customer issues quickly and accurately. This intent is activated when an utterance is not classified into any of the other intents present in the bot. Note that this intent will not be activated for missed utterances when eliciting a slot value. Once recognized, the AMAZON.QinConnectIntent, uses the specified Q in Connect domain to search the configured Amazon Bedrock Knowledge Base and respond to the customer question. **Note** You cannot use AMAZON.QinConnectIntent along with AMAZON.QnAIntent in the same bot locale. If you select another language besides U.S. English, you must customize the self-service prompts (`SELF_SERVICE_PRE_PROCESSING` and `SELF_SERVICE_ANSWER_GENERATION`) to respond in the specified language. For more information on how to customize your prompt, see [Customize Amazon Q in Connect](https://docs.aws.amazon.com/connect/latest/adminguide/customize-q.html#ai-prompts-customize-q). If you select this intent, you need to configure the following fields and then select **Save Intent** to add the intent to the bot. + Amazon Q In Connect Configuration - Provide the Amazon Resource Name (ARN) of the Amazon Q in Connect assistant. Assistant ARN Pattern: `^arn:[a-z-]*?:wisdom:[a-z0-9-]*?:[0-9]{12}:[a-z-]*?/[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}(?:/[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}){0,2}$>`. The responses from the QinConnectIntent will be stored into the request attributes as shown below: + `x-amz-lex:q-in-connect-response` – The response from QinConnectIntent to the question or utterance. **Session Attributes Returned from QinConnectIntent** Interaction with the QinConnect intent provides additional data about conversation through session attributes. 1. `x-amz-lex:q-in-connect:session-arn` – An unique identifier for the session created with Amazon Q In Connect during the conversation. 1. `x-amz-lex:q-in-connect:conversation-status` – The current status of the conversation with QinConnect assistant or domain. There are three values possible for this status: + `CLOSED` + `READY` + `PROCESSING` 1. `x-amz-lex:q-in-connect:conversation-status-reason` – Provides the reason for the current status reported with above attribute. The possible reasons are as follows: + `SUCCESS` – Indicates customer has nothing left to ask and question has been answered successfully. + `FAILED` – Indicates a failure while answering the customer's question. These are mostly due to failures to understand the customer's question. + `REJECTED` – Indicates that the assistant is rejecting to answer customer question, and recommending that the question be handled outside of the bot interaction, such as talking to person or agent, to get more information. **Note** When a bot with QinConnectIntent is invoked during customer interactions driven by an Amazon Connect instance, your session arn needs to be created and passed from the Amazon Connect instance. To create a session, Amazon Connect Flows could be configured with Amazon Q in Connect step. **Limitations** + You cannot use AMAZON.QinConnectIntent along with intents without specific utterances such as AMAZON.QnAIntent, AMAZON.BedrockAgentIntent in the same bot locale. + When a bot with QinConnectIntent is invoked during a customer interactions driven by an Amazon Connect instance, your session arn needs to be created and passed from the Amazon Connect instance. To create a session, Amazon Connect Flows could be configured with Amazon Q In Connect step. + There can be no more than one AMAZON.QinConnectIntent per bot locale. + The Amazon Q in Connect domain used with AMAZON.QinConnectIntent must be in the same AWS Region as the Amazon Lex V2 bot. **Permissions** If the QinConnect Intent is used in an Amazon Lex V2 bot, and the bot is using a Service Linked Role (SLR), the Amazon Lex V2 service has the permissions to update the appropriate policies on the role to integrate it with the Q in Connect assistant. If the bot is using a custom IAM role, then the user would need to manually add these permissions to their IAM role. The Service Linked Role will get updated with the following permissions if the QinConnect intent gets added. A new policy will be added for QinConnect access: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Sid": "QInConnectAssistantPolicy", "Action": [ "wisdom:CreateSession", "wisdom:GetAssistant" ], "Resource": [ "arn:aws:wisdom:*:accountId:assistant/assistantId", "arn:aws:wisdom:*:accountId:assistant/assistantId/*" ] }, { "Effect": "Allow", "Sid": "QInConnectSessionsPolicy", "Action": [ "wisdom:SendMessage", "wisdom:GetNextMessage" ], "Resource": [ "arn:aws:wisdom:*:accountId:session/assistantId/*" ] }, { "Sid": "QInConnectKmsCMKPolicy", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:region:accountId:key/keyId" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "accountId", "kms:ViaService": "wisdom.region.amazonaws.com", "kms:EncryptionContext:aws:wisdom:assistant:arn": ["arn:aws:wisdom:region:accountId:assistant/assistantId"] } } } ] } ``` **Note** The `QInConnectKmsCMKPolicy` statement is only required if you are using a customer managed KMS key with the Amazon Q in Connect assistant. **Trust Policy** ``` { "Effect": "Allow", "Sid": "LexV2InternalTrustPolicy", "Principal": { "Service": "lexv2.aws.internal" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "accountId" }, "ArnLike": { "aws:SourceArn": "arn:aws:lex:*:accountId:bot-alias/botId/*" } } } ``` # AMAZON.RepeatIntent Responds to words and phrases that enable the user to repeat the previous message. Your application needs to use a Lambda function to save the previous intent information in session variables, or you need to use the [GetSession](https://docs.aws.amazon.com/lexv2/latest/APIReference/API_runtime_GetSession.html) operation to get the previous intent information. Common utterances: + repeat + say that again + repeat that # AMAZON.ResumeIntent Responds to words and phrases the enable the user to resume a previously paused intent. You Lambda function or application must manage the information required to resume the previous intent. Common utterances: + resume + continue + keep going # AMAZON.StartOverIntent Responds to words and phrases that enable the user to stop processing the current intent and start over from the beginning. You can use your Lambda function or the `PutSession` operation to elicit the first slot value again. Common utterances: + start over + restart + start again # AMAZON.StopIntent Responds to words and phrases that indicate that the user wants to stop processing the current intent and end the interaction with a bot. Your Lambda function or application should clear any existing attributes and slot type values and then end the interaction. Common utterances: + stop + off + shut up