The Amazon Bedrock Converse API provides a common conversational interface across supported foundation models. Instead of building a separate request shape for every provider, an application can send messages, system prompts, shared inference parameters, tool configuration, guardrail configuration, and request metadata through Converse or ConverseStream. Model-specific parameters are still available when needed, but the main application contract can remain more consistent.<\/p>\n
Within Generative AI on AWS<\/a>, Converse is the lower-level orchestration path for teams that want to own conversation state, tool execution, retries, and application logic rather than using a fully managed agent runtime.<\/p>\n The benefit is control. The trade-off is that the application becomes responsible for the loop around the model.<\/p>\n A Converse request includes the model identifier plus message history and optional system instructions. Messages are structured by role and content block rather than being one giant prompt string.<\/p>\n This structure makes multi-turn state explicit. The application decides which previous messages are included, how long conversation history is retained, and whether old context is summarized or removed. Converse does not turn the model into an authoritative state store by itself.<\/p>\n System prompts should contain stable behavioral instructions, while business facts that can change should usually be retrieved from current data sources.<\/p>\n The Portability should still be tested. Two models can accept the same conversation structure and produce different tool-selection quality, token behavior, context limits, or safety characteristics.<\/p>\n The existing foundation model selection<\/a> article is useful context because API compatibility is not the same thing as workload equivalence.<\/p>\n Converse can include tool specifications that describe callable functions to the model. When the model decides a tool is required, the response includes a tool-use request. The application executes the tool and returns the result in a later message so the model can continue.<\/p>\n This gives the application complete control over execution. It can validate arguments, check authorization, require approval, apply idempotency, or decline the tool call before any side effect occurs.<\/p>\n The planned Bedrock Tool Use Streaming<\/a> article covers the streaming path, where tool-use events and text can arrive incrementally.<\/p>\n The model response includes a stop reason that tells the client why generation ended. Tool use, normal completion, length limits, and other outcomes should be handled explicitly rather than inferred from text.<\/p>\n When the stop reason indicates tool use, the application should execute the requested tool according to policy and then continue the conversation with the tool result. When generation reaches a token or length boundary, the application may need a different recovery path.<\/p>\n A robust Converse loop is therefore a state machine around structured response fields, not a regex that searches generated text for phrases such as \u201ccall API.\u201d<\/p>\n Converse supports Bedrock Guardrails through This means a team should not assume that enabling a guardrail automatically sanitizes every piece of data moving through the tool loop. Guardrails protect the content they are configured to assess; tool security still requires schema validation, authorization, and output handling.<\/p>\n The existing AI guardrails and content safety<\/a> article is directly relevant.<\/p>\n Retries should therefore distinguish \u201cno request reached the service\u201d from \u201cgeneration started but the client lost the stream.\u201d Replaying automatically can double model cost and, in a tool loop, can cause a second logical action if the application is not careful.<\/p>\n The client should propagate cancellation where possible and record whether a stream completed normally.<\/p>\n Converse requests can include metadata that is useful for filtering invocation logs. Applications should use stable correlation values such as environment, feature version, experiment, or tenant classification without putting sensitive content into metadata fields unnecessarily.<\/p>\n This makes it easier to compare model performance across releases or route production incidents back to one application version. The same correlation identifier can also be carried into tool traces and gateway logs.<\/p>\nMessages and system prompts form the conversational contract<\/h3>\n
Shared inference parameters improve model portability<\/h3>\n
inferenceConfig<\/code> field provides common generation controls, while additionalModelRequestFields<\/code> can pass provider-specific parameters. This lets an application share a large part of its invocation code across models without pretending every model has identical features.<\/p>\nTool configuration enables client-side function calling<\/h3>\n
Stop reasons should drive the application state machine<\/h3>\n
Guardrails must be configured with awareness of tool fields<\/h3>\n
guardrailConfig<\/code>, including streaming configurations. AWS documentation also makes an important distinction: a guardrail applied to Converse does not automatically evaluate every tool field. Tool definitions, tool-call arguments, and tool results have specific evaluation behavior and may require application-side controls.<\/p>\nConverseStream changes cancellation and retry behavior<\/h3>\n
ConverseStream<\/code> returns response events incrementally. Streaming improves perceived latency, but it means the client can disconnect after the model has already consumed tokens or generated part of a tool request.<\/p>\nRequest metadata helps connect invocation to observability<\/h3>\n