3.2.3. Managing Prompts: Amazon Bedrock Prompt Management

First Principle: In production, a prompt is part of the application's logic. Like code, it needs a place to live, a way to test changes safely, and a way to ship a known-good version while work on the next one continues.

Amazon Bedrock Prompt Management lets you create, edit, test and save reusable prompts, together with the model (or inference profile or agent) and inference settings they run with.

Key constructs:

• Variable: a placeholder in the prompt, such as {{customer_name}}. You supply its value when you test the prompt or when the application invokes it, so one prompt can serve many use cases.
• Prompt variant: an alternative configuration of the same prompt: a different message, a different model, or different inference settings. You can run variants side by side and keep the one whose output fits best.
• Prompt builder: the Amazon Bedrock console tool for creating, editing and testing prompts and their variants visually.
• Draft version: saving a prompt creates the draft, the working copy you keep iterating on.
• Version: a point-in-time snapshot of the draft, created when you are satisfied with a configuration. Versions are numbered from 1.

Versioning strategy:

1. Iterate on the draft, testing variants and variable values.
2. When a configuration passes testing, create a version.
3. Point the application at that specific version. It can call the version by its ARN through model inference (for example, the Converse API, supplying variable values), or use the prompt in a prompt node in Amazon Bedrock Flows.
4. Keep editing the draft. Production is unaffected until you create a new version and deliberately move the application to it.
5. Compare versions in the console to see exactly what changed, and switch back to an earlier version if a change underperforms.

When an application calls a managed prompt this way, settings such as the system prompt, inference configuration and tool configuration come from Prompt Management rather than from the request, which keeps them under version control.

Related features: Prompt Management can optimize a prompt (Bedrock rewrites it for a chosen model and shows the result beside the original), and you can enable prompt caching for a managed prompt on supported models.

What Prompt Management does not do: it does not train or fine-tune models, it does not store customers' conversation history, and a version fixes the prompt's configuration, not the model's output. FM responses remain nondeterministic.

Scenario: A team's developers edit the support-assistant prompt several times a day while experimenting. Last week an unfinished edit reached customers because the application always read the latest prompt text.

Reflection Question: How would creating versions, and pinning the application to a tested version, have prevented this, and how would the team roll back if a new version performed worse?

💡 Tip: Draft = work in progress. Version = what production runs. Variants = compare configurations. Variables = reuse one prompt with different values.