Converse API tool use and chat history on Bedrock (AIP-C01)

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. A company is building an order-status assistant with the Amazon Bedrock Converse API. A GenAI developer adds a toolConfig with one toolSpec named get_order_status, whose inputSchema requires an order_id. An AWS Lambda function implements the order lookup, and the tool description names the function. In testing, questions about orders return no answer text. Each Converse response has a stopReason of tool_use and a toolUse block that contains the correct order_id. Amazon CloudWatch Logs shows that the Lambda function is never invoked. What is the cause of this issue?

   Right. In the game that’s Renown for your Implementation and Integration building.

   Not that one: D is right. In the game your Implementation and Integration building would lose a little Renown, and this question would come back later.

   Your answerA.The toolConfig does not set toolChoice, so the model is free to answer without calling the tool. The request must set toolChoice to the get_order_status tool so that the function runs.The model already requested the tool: the stop reason is tool_use and the toolUse block holds the order ID. Forcing the tool changes nothing.Your answerB.The Lambda function has no resource-based policy that allows Amazon Bedrock to invoke it. The function needs a permission statement for the bedrock.amazonaws.com service principal.The permission idea assumes Amazon Bedrock calls the function. With Converse, Bedrock only hands back the model's request; the app does the calling.Your answerC.The maxTokens value in inferenceConfig is too low for the model to finish its tool call. The request must raise maxTokens so that the model can complete the call and the answer.A response cut off by the token limit ends with the max_tokens stop reason. These responses end with tool_use and a complete toolUse block.The answerD.Amazon Bedrock returns the model's tool request to the application and does not run the tool itself. The application must invoke the Lambda function and send the result back in a toolResult block.The tool use overview (https://docs.aws.amazon.com/bedrock/latest/userguide/tool-use.html) says: "In Amazon Bedrock, the model doesn't directly call the tool."

   Show the full explanation and doc quotes

   For client-side tool use it names who runs the tool: "Your application code, after the model returns a tool-call request." So a stopReason of tool_use is the model's request, and nothing runs the Lambda function until the application does. The client-side page (https://docs.aws.amazon.com/bedrock/latest/userguide/tool-use-client-side.html) describes the loop: "in your code, you call the tool on the model's behalf", then "You then continue the conversation with the model by supplying a message with the result from the tool."

   Written from docs.aws.amazon.com/bedrock/latest/userguide/tool-use.html

2. A company's order assistant calls the Amazon Bedrock Converse API with Amazon Nova Pro and a tool named get_order_status. When the model requests the tool, the application calls an internal order service. Sometimes the order service times out. When a tool call fails, the model must learn that this specific tool request failed so that it can tell the customer or ask for a different order number. The conversation must continue in the same message history, and the history must keep each tool request that the model made together with its outcome. Which solution will meet these requirements?

   Right. In the game that’s Renown for your Implementation and Integration building.

   Not that one: A is right. In the game your Implementation and Integration building would lose a little Renown, and this question would come back later.

   The answerA.Append a user message that contains a toolResult block with the toolUseId of the failed request, a text description of the timeout, and status set to error. Call the Converse API again with the full message history.A tool's outcome, success or failure, goes back to the model in a toolResult block.Your answerB.Append a user message that contains a text content block that describes the timeout, and leave out a toolResult block for the failed request. Call the Converse API again with the full message history.The model reads a note about a timeout, but nothing ties it to the request it made. Tool outcomes travel in a toolResult block with the request's ID.Your answerC.Call the Converse API again with the same message history and with toolChoice set to the get_order_status tool, so that the model requests the tool again until the order service responds.Asking for the same tool in a loop only repeats the call. The model is never told that the first attempt failed.Your answerD.Remove the assistant message that contains the toolUse block for the failed request from the message history. Add a note to the system prompt that the order tool is unavailable, and call the Converse API again with the remaining history.Deleting the request hides the failure instead of reporting it, and the history no longer shows what the model asked for.

   Show the full explanation and doc quotes

   The ToolResultBlock reference (https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ToolResultBlock.html) defines toolUseId as "The ID of the tool request that this is the result for." and gives status the valid values success and error, a field "only supported by Amazon Nova and Anthropic Claude 3 and 4 models." Returning the timeout text with status set to error tells Nova Pro that this request failed, and the history keeps the toolUse and its toolResult side by side.

   Written from docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ToolResultBlock.html

3. A travel company is building a customer support chatbot. An AWS Lambda function receives each user message and calls the Amazon Bedrock Converse API with that message in the messages field. A chat session can last up to 20 turns. In testing, the model answers single questions well but does not know what the user said earlier in the same session. When a user asks "Can I move it to Friday?" after asking about a booking, the model asks which booking the user means. The chatbot must keep the context of each session. The company wants to add as little infrastructure as possible. Which solution will meet these requirements with the LEAST operational overhead?

   Right. In the game that’s Renown for your Implementation and Integration building.

   Not that one: B is right. In the game your Implementation and Integration building would lose a little Renown, and this question would come back later.

   Your answerA.Add a cache checkpoint after the first user message of each session so that Amazon Bedrock keeps the start of the conversation. On later turns, send only the new user message after the checkpoint in the Converse request.A cache checkpoint only speeds up a prefix that the request still sends; it does not make Amazon Bedrock remember turns that are left out.The answerB.Store the user and assistant messages of each session in an Amazon DynamoDB table keyed by session ID. On each turn, send all the stored messages in order, with their roles, in the messages field of the Converse request.The Converse API does not keep a session, so the application must send the history itself.Your answerC.Create a prompt in Amazon Bedrock Prompt Management for each session, and save a new prompt version after each turn. Pass the ARN of the latest prompt version as the model ID in the Converse request.Saving a prompt version on every turn turns a template tool into a chat log. It adds a resource per session and still does not send the turns as messages.Your answerD.Write each finished turn to an Amazon S3 bucket that is the data source of an Amazon Bedrock knowledge base. Start an ingestion job after each turn, and send each new user message to RetrieveAndGenerate.A knowledge base finds passages that look like the question. It does not replay the conversation in order, and a new turn is not searchable until ingestion finishes.

   Show the full explanation and doc quotes

   The Converse page (https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html) says "Amazon Bedrock doesn't store any text, images, or documents that you provide as content. The data is only used to generate the response." It also gives the fix: "You can maintain conversation context by including all the messages in the conversation in subsequent Converse requests and using the role field to specify whether the message is from the user or the model." A DynamoDB item per session holds those messages between Lambda invocations, which adds one table and no servers.

   Written from docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html