Bedrock's New Prompt Optimizer Rewrites and Re-Scores Prompts Across Five Models at Once

You hand the system a prompt template, sample inputs, optional ground-truth answers and an evaluation metric. AWS describes what follows as a reinforcement-learning-style feedback loop: the optimizer runs the template through the model, scores the responses against your metric, rewrites the prompt, and scores again, repeating until the metric converges. Model weights never change; only the prompt does. The job returns the original and optimized prompts, evaluation scores, per-sample time to first token, and a operational load estimate.

The catch that AWS flags itself is prompt length. Across its four example jobs, every optimized prompt used more input tokens, with the increase ranging from roughly 7% to several times the original. A better score can therefore arrive with higher input operational load or different latency, which is why AWS treats time to first token as a directional signal to confirm with repeated measurement rather than a settled number.

Only one evaluation method is allowed per template, and the choice shapes what the optimizer chases:

• An AWS Lambda function for concrete metrics such as accuracy, F1, ROUGE or JSON matching, where you supply the scoring logic.
• LLM-as-a-Judge for open-ended work such as summarization, reasoning or generation, using a rubric and a judge model.
• Steering criteria — up to five natural-language rules — for goals like brand voice, response format or safety constraints.

The feature also handles multimodal inputs, accepting PNG, JPG, JPEG, GIF, WebP and PDF files referenced through Amazon S3 URIs. Per job, the limits are 10 templates, 100 evaluation samples per template, five models, 20 text variables per template, 100 multimodal files per sample and five steering criteria per template.

AWS publishes example gains and is unusually direct about their weight: they come from four real jobs run in US East (N. Virginia), each on just five evaluation samples, and the company calls them single-run tutorial results to be read as illustrative, not as benchmarks. The numbers are eye-catching — a NESTFUL function-calling run where accuracy climbed from 0.267 to 0.647, and an XSum summarization run where the quality score rose from 0.550 to 0.743 — but five samples cannot establish how a prompt generalizes.

That gap is the real story. The launch turns prompt migration into a repeatable, instrumented workflow instead of a manual rewrite project, and it makes the quality-latency-operational load trade-off visible before a customer-facing system changes. What it does not do is prove those optimized prompts hold up on hundreds or thousands of messy production examples, or remove the need for versioning, rollback and approval gates once prompts are being generated by a machine. The useful gains to watch for are customer results at production scale — and evidence that an optimized prompt performs beyond the handful of samples used to produce it.