Foundation Model Integration and Application Development
Core concepts
Candidates must understand how Amazon Bedrock exposes foundation models through a unified InvokeModel and Converse API, how the Converse API normalizes message roles and tool definitions across providers, and how inference parameters (temperature, topP, maxTokens, stopSequences) interact. Know the difference between synchronous invocation, streaming responses, and asynchronous batch inference. Understand tool use (function calling): the model returns a tool-use block, your code executes the function, then you return a tool-result block in the next turn. Know the Agents for Amazon Bedrock action groups and knowledge bases, and when a simple orchestration loop suffices instead.
Traps
- Assuming
temperatureandtopPare interchangeable; questions often describe needing deterministic output and expecttemperaturenear zero, not atopPchange alone. - Forgetting that streaming does not reduce total token cost, only perceived latency.
- Confusing model invocation logging with application-level tracing.
- Believing a single prompt can reliably enforce JSON schema; structured output often requires tool use or validation layers.
- Mixing up provisioned throughput (reserved capacity) with on-demand quotas.
Worked example
A team needs a chatbot that calls an order-lookup function and streams answers. Rule of thumb: use the Converse API with a tool configuration, loop until stopReason is tool_use, execute the function, append the result, and re-invoke; stream to the client for latency, and validate final JSON before returning it.
Rule of thumb
Design for statelessness: pass conversation history explicitly each turn, and keep orchestration logic outside the model.