Amazon Bedrock AgentCore Prompt Optimization Turns Agent Traces Into Tested Changes

Amazon has moved agent prompt tuning beyond manual editing, but its strongest result also exposes a difficult production tradeoff. Amazon Bedrock AgentCore prompt optimization now uses evaluated traces to recommend system prompt changes, screen them, and validate promising variants before promotion.

The workflow connects AgentCore Observability, evaluations, recommendations, configuration bundles, and controlled A/B tests. That matters because a plausible rewrite is not necessarily a better production prompt. It must improve the chosen metric without weakening safety instructions, copying test examples, or growing into an unmanageable policy document.

AWS reported its technical design and benchmark results on September 16, 2026. Its Single Agent Reflector favored short optimization cycles, while an experimental Sub-Agent Reflector achieved the highest reported scores. The comparison places AWS beside established approaches such as GEPA and MIPROv2, but the more important contest is between automated recommendations and the manual prompt-tuning process many teams still use.

Amazon Bedrock AgentCore Prompt Optimization Closes the Testing Loop

The central change is not automated rewriting alone. AgentCore connects a proposed prompt change to evidence, versioning, evaluation, and controlled promotion.

A system prompt defines an agent’s role, operating constraints, tool behavior, and decision rules. Small wording changes can affect whether the agent asks for clarification, selects the right tool, or stops after reaching its goal. Those changes can also create unexpected failures elsewhere.

Teams have traditionally handled this problem through manual diagnosis. An engineer reviews long execution traces, finds a possible failure pattern, edits the prompt, and reruns selected tests. That process can work during prototyping, but it becomes difficult to repeat across changing models, tools, data, and user behavior.

AgentCore optimization formalizes that loop. According to the technical analysis, an evaluator first assigns rewards to completed agent traces. The optimizer then examines successful and unsuccessful behavior before proposing a revised system prompt and explaining its reasoning.

The evaluator is not a neutral component. It defines the behavior the optimization process will reward. AWS supports built-in, custom language-model judges, and code-based evaluators, provided they return a numerical signal.

For a transactional agent, the selected target might be goal completion. An open-ended assistant might instead optimize for helpfulness. A domain-specific agent can use a custom evaluator when generic criteria do not capture the desired behavior.

That choice creates the article’s central tension. Automated optimization can search more consistently than a person reviewing scattered logs. However, it can only improve the behavior represented by its traces, evaluator, and validation process.

AWS explicitly warns that recommendations are generated by language models and require review. Its recommendation guide also states that the selected evaluator determines the direction of optimization.

This means a recommendation is not an authoritative correction. It is a testable hypothesis about how the current prompt should change.

AgentCore provides configuration bundles to make that hypothesis operational. A bundle is an immutable snapshot containing items such as the system prompt, model identifier, and tool descriptions. Teams can compare versions without embedding every behavioral change directly in application code.

The platform’s A/B testing layer can then split traffic between two variants through AgentCore Gateway. Online evaluations score sessions, and the system reports whether the observed difference reaches statistical significance.

That sequence is more consequential than a text generator producing a revised instruction. It turns prompt editing into a release process with evidence before and after the change.

The workflow also pressures teams that treat prompts as informal configuration. Once prompts affect tool permissions, customer outcomes, and business processes, undocumented edits become an operational risk. Versioned recommendations and controlled tests raise expectations for how agent behavior should be managed.

The Reflector Reads Traces as a Working Dataset

AWS avoids squeezing every trace into one prompt. Its reflector receives file-based access and decides which evidence deserves closer inspection.

The reasoning component behind the optimizer is called an agentic reflector. It reviews evaluated behavior, identifies patterns separating successful runs from failures, and proposes targeted configuration edits.

Agent traces can include user messages, model reasoning, tool calls, tool responses, intermediate state, and evaluator feedback. Even a few dozen detailed trajectories can exceed a model’s context window. Simply pasting everything into one analysis prompt would force truncation or aggressive summarization.

AWS instead writes the evaluated traces to a directory available to the reflector. The reflector receives shell access and instructions to investigate the evidence. It can list files, search recurring terms, compare outputs, and open selected traces.

This design treats the trace corpus as an external working memory. The model does not need to hold every execution in its active context simultaneously. It retrieves evidence when a developing hypothesis requires it.

The reflector might begin with the score distribution, identify unusually weak runs, and compare them with successful executions of similar tasks. It can then inspect the point where behavior diverged, such as a wrong tool choice or an unnecessary additional action.

AWS says it does not impose a fixed trace-summary pipeline. The reflector chooses which files, comparisons, and failure patterns matter. That flexibility can preserve details that a generic summarizer might remove before analysis begins.

It also creates reproducibility questions. Two reflector runs might inspect different evidence or prioritize different patterns. The final proposal can depend on the reflector model, the available tools, the evaluator output, and the sampled trace set.

AgentCore addresses part of that uncertainty by attaching an explanation to the proposed change. A reviewer can compare the current and revised prompts while examining the trace patterns that motivated the edit.

The explanation is important, but it is not proof. A model can produce a convincing rationale for a weak recommendation. Offline evaluation and controlled production testing still carry the evidentiary burden.

The Single Agent Reflector runs this investigation through one agent. It surveys the trace collection, drills into selected segments, compares wins and failures, and returns one coherent set of edits.

Each optimization epoch repeats a defined cycle: score the traces, reflect on the evidence, and accept only edits that pass the guardrails. Teams can run more epochs when further quality gains justify additional optimization time.

The design favors synthesis. One reflector retains the full investigative thread and can connect patterns found across several traces. However, early observations can shape what it examines next.

AWS describes a possible failure mode in which one pass concentrates on patterns in the first five to ten traces it opens. Rare problems elsewhere in the corpus can remain hidden, especially when the trace set contains several unrelated task types.

This is where the Sub-Agent Reflector changes the mechanism. Rather than assigning the complete corpus to one investigator, an orchestrator delegates individual traces to independent sub-agents.

Each sub-agent performs three levels of analysis. It first records the reward, difficulty, and outcome. It then locates the decision where the trajectory left the preferred path. Finally, it diagnoses the failure and proposes a corrective rule.

The orchestrator collects those findings, merges repeated observations, and generalizes them into configuration changes. Independent contexts reduce the chance that one early theory will influence every trace review.

The Sub-Agent Reflector therefore spends more computation to broaden failure coverage. Its architecture resembles a review team whose members inspect separate incidents before a lead editor combines their conclusions.

AWS released this approach as an experimental feature in the open-source Strands project. It is not presented as the default managed optimizer. The Single Agent Reflector remains the production recommendation engine described for AgentCore optimization.

Single Agent and Sub-Agent Reflector Results Split Speed From Quality

AWS’s benchmark results do not identify one universal winner. They separate the fastest useful optimizer from the method with the highest reported quality ceiling.

AWS evaluated both reflectors on AppWorld and WebShop. AppWorld tests agents across simulated applications and interconnected tasks, while WebShop evaluates agents completing shopping goals through website interactions.

The company compared its methods with GEPA and MIPROv2. Both are established prompt-optimization approaches available through the broader DSPy ecosystem.

MIPROv2 creates candidate instructions and examples, then uses Bayesian optimization to search combinations. GEPA uses language-model reflection over trajectories and feedback, evolving prompts through repeated proposals and selection.

That competitive context matters because trace-based reflection did not begin with AgentCore. The GEPA research describes an optimizer that diagnoses trajectories in natural language and evolves prompt candidates. The DSPy optimizer guide also documents MIPROv2 and GEPA as distinct optimization strategies.

AWS tested the four approaches across multiple configurations and reported the best observed result for each method. It scanned sample counts from 5 to 50 and epochs or iterations from 1 to 10. Opus 4.6 served as the reflector model, while Sonnet 4.5 was the task model.

On AppWorld, the unoptimized baseline had a 72.62 percent success rate. GEPA reached 79.63 percent after 100 turns and 108 minutes. MIPROv2 reached 74.40 percent after 100 turns and 216 minutes.

The Single Agent Reflector reached 81.55 percent using 20 turns and six minutes. AWS characterized that runtime as an 18-fold speed increase over GEPA and a 36-fold increase over MIPROv2 for a comparable or better result.

The Sub-Agent Reflector reached 95.83 percent on the same benchmark. It used 100 turns and took 193 minutes. That was the highest reported AppWorld score, but it required the same turn count as the two baselines and far more time than the single-reflector run.

The WebShop results showed a narrower quality spread. Its baseline reward was 75.03 percent. GEPA reached 74.77 percent after 50 turns and 48 minutes, while MIPROv2 reached 72.12 percent after 25 turns and 60 minutes.

The Single Agent Reflector reached 78.31 percent with five turns and one minute. The Sub-Agent Reflector reached 79.15 percent with 200 turns and approximately 20 minutes.

Those figures make the operational choice unusually clear.

For fast iteration, the Single Agent Reflector produced the best reported quality-to-time balance. It exceeded the comparison methods on both reported metrics while using the fewest turns and the shortest wall-clock time.

For maximum benchmark performance, the Sub-Agent Reflector won both tasks. Its largest advantage appeared on AppWorld, where distributed inspection likely had more varied failure patterns to uncover.

The WebShop result complicates the quality story. The sub-agent method spent 200 turns to gain 0.84 percentage points over the single-agent result. That difference can matter in high-volume or high-value workflows, but many teams will question whether it justifies the extra optimization work.

The benchmarks also support a broader conclusion about agent evaluation. A method that looks efficient on one environment might need greater trace coverage on another. AppWorld and WebShop represent different task structures, so one score cannot establish universal superiority.

AppWorld itself contains hundreds of tasks across simulated applications, as described in its benchmark paper. That diversity makes it useful for testing multi-step behavior, but it remains a controlled environment.

Production traces bring messier inputs, changing interfaces, incomplete goals, and organization-specific constraints. Users can abandon tasks, provide contradictory instructions, or expect behavior that the evaluator never encoded.

AWS also reported each method’s best result after sweeping configurations. That is a legitimate experimental presentation, but it does not show how reliably a team will select the best settings in advance. Search cost and configuration sensitivity matter when optimization becomes a recurring production process.

The published numbers should therefore be read as evidence that the reflector designs are competitive on two public tasks. They should not be treated as a guarantee that an agent will improve by the same margin after deployment.

Automated Prompt Tuning Puts Manual Review Under Pressure

AgentCore’s real opponent is the unstructured editing loop where engineers change prompts, rerun a few examples, and promote whatever looks better.

Manual prompt tuning remains common because it is accessible. A developer can inspect one failed conversation, add an instruction, and test the same scenario again. The feedback arrives quickly, and the change often appears intuitive.

That process becomes less reliable as the prompt accumulates exceptions. A rule added for one failure can conflict with an earlier constraint. Another edit can fix a tool-selection problem while making the agent overly cautious elsewhere.

The result is often prompt bloat. The system prompt becomes a collection of incident-specific patches rather than a consistent behavioral policy. Longer prompts can increase inference overhead and make conflicts harder to detect.

Automated optimizers face the same failure mode. They can learn to add more qualifications whenever a trace reveals a new error. A higher evaluator score does not automatically mean the revised prompt is clearer or more general.

AWS applies three rubric-based guardrails before accepting a candidate. First, it rejects a configuration that grows more than 20 percent over the previous version and asks the optimizer to tighten the revision.

Second, it screens candidates against safety standards. This check targets revisions that might soften restrictions while chasing a task-completion score.

Third, it prohibits candidates from reusing exact phrases found in the optimization traces. That rule reduces the risk of memorizing surface details from the examples instead of extracting a transferable instruction.

These guardrails reveal what Amazon expects to go wrong. An optimizer can produce an accurate but oversized prompt, weaken safety boundaries, or overfit to its evidence. The platform is designed around those risks rather than assuming reflection will avoid them.

The evaluator remains the most important pressure point. If it rewards task completion without penalizing unnecessary disclosure, unsafe actions, or poor user experience, the optimizer has an incomplete target.

AWS’s broader optimization workflow addresses this through offline tests and online experiments. Still, neither mechanism repairs a badly chosen metric by itself.

A goal-success evaluator can favor an agent that completes a booking efficiently. It might not detect whether the agent explained a restrictive cancellation rule clearly. A helpfulness judge can reward an elaborate answer that slows a time-sensitive workflow.

Human review therefore shifts rather than disappears. Reviewers no longer need to invent every candidate prompt manually, but they must judge the evidence, evaluator, proposed change, and test design.

This changes the skills required from agent teams. Prompt writing remains useful, yet evaluation design and trace governance become equally important. Teams need to know which behavior is measurable, which failures are absent, and which changes require additional safety review.

Configuration bundles also bring prompts closer to conventional release engineering. A team can retain immutable versions, compare behavior, and promote a validated configuration without redeploying the full agent application.

That separation helps organizations manage agent behavior across environments. It also creates a new governance question: who can approve a prompt change when the configuration controls tool use, data access, or customer-facing decisions?

An engineer might own system reliability, while a security team owns access policies. Product teams may define desired behavior, and legal teams may govern required disclosures. A recommendation workflow needs approval boundaries that reflect those responsibilities.

The same issue applies beyond prompts. AWS says trace evidence can identify weak tool descriptions and reusable skills. Those components can materially change behavior even when the core system prompt stays fixed.

Optimizing all three together could uncover larger gains. It could also make attribution harder. If a new prompt, tool description, and skill package enter one test variant, teams may not know which change produced the result.

This is where disciplined experimentation matters. A controlled test should isolate meaningful changes when practical, define stopping criteria, and preserve a rollback path.

Organizations already building searchable knowledge workflows face a related challenge. Better retrieval cannot compensate for an agent whose prompt misstates when to search, which evidence to trust, or when to ask for clarification.

AgentCore optimization can help identify those behavioral failures from traces. It does not decide the organization’s acceptable risk or information policy.

The Benchmark Gains Still Depend on the Evidence Pipeline

The optimizer can only generalize from what the traces and evaluator reveal, so production coverage matters more than an impressive isolated score.

AWS recommends starting with 10 to 50 diverse traces. That range gives the reflector enough variation to find patterns without immediately creating an unwieldy analysis job.

The word “diverse” carries more weight than the count. Fifty nearly identical successful runs provide less diagnostic value than a smaller set spanning different tasks, difficulty levels, tools, outcomes, and user behaviors.

Rare failures present a particular challenge. A production agent might mishandle a sensitive request once in several thousand sessions. A random trace sample can omit that case, while an average reward can conceal it.

The Sub-Agent Reflector offers one response by inspecting traces independently. It can give a minority failure mode a dedicated context rather than letting frequent patterns dominate one reflector’s attention.

However, independence does not solve missing evidence. No analysis method can diagnose a failure absent from the collected traces. Teams still need purposeful sampling, targeted tests, and incident-driven evaluation sets.

Free-text feedback can add useful context. AWS says the reflector can read evaluator rationales, human annotations, or user complaints stored with the trace. That information may explain why a numerically similar failure deserves different treatment.

It also introduces another source of inconsistency. Human labels can disagree, evaluator rationales can be unreliable, and user complaints may reflect preferences rather than policy violations.

Trace handling creates privacy and security concerns as well. Agent runs can contain personal information, proprietary data, tool outputs, and hidden operational details. A filesystem-based analysis design needs appropriate access controls, retention rules, and redaction practices.

The published technical post focuses on optimization mechanics and benchmark performance. It does not provide a general answer for every organization’s trace-governance obligations.

Model dependence is another uncertainty. AWS used Opus 4.6 for reflection and Sonnet 4.5 for task execution in the reported experiments. Different reflector models can vary in investigative depth, tool use, and ability to synthesize conflicting evidence.

A future model update can change both the agent’s baseline behavior and the optimizer’s recommendations. Teams should rerun representative evaluations when either component changes.

Benchmark transfer also remains unproven. AppWorld and WebShop test useful agent behaviors, but neither represents every enterprise workflow. A customer-support agent, coding agent, or regulated decision assistant can fail through very different mechanisms.

The 95.83 percent AppWorld result is therefore notable but bounded. AWS says the Sub-Agent Reflector reached that score under its reported sweep. Independent replications across other agent frameworks and task models would strengthen the claim.

GEPA and MIPROv2 also should not be dismissed based on two comparisons. Their own configuration choices, optimization budgets, program structures, and intended use cases can differ from AgentCore’s managed workflow.

The practical question is not whether one optimizer wins a universal ranking. It is whether a method produces dependable improvements under a team’s constraints.

A useful production test should ask whether the candidate improves held-out tasks, retains safety requirements, avoids regressions, and performs consistently across user segments. Latency and operating cost also belong in that assessment.

Online A/B testing adds real traffic, but teams must use it carefully. High-risk behavior should not reach users merely because the platform can split traffic. Offline gates and expert review should determine which variants qualify for live exposure.

Statistical significance does not replace practical significance either. A small measured improvement can be statistically credible yet operationally irrelevant. Conversely, a rare safety regression may matter even when it barely changes the average score.

AgentCore’s validation model is strongest when organizations treat promotion as a policy decision. The optimizer proposes, the evidence filters, and accountable owners decide.

Three Signals Will Show Whether AgentCore Optimization Transfers to Production

The next test is not another isolated benchmark. It is whether teams can repeat the improvement loop across changing agents without accumulating hidden regressions.

The first signal is broader evaluation across models, agent frameworks, and real workflows. AWS’s results used one reflector model, one task model, and two public benchmarks. Replications should show whether the Single Agent Reflector keeps its speed advantage and whether sub-agents retain their quality edge.

Consistent results would strengthen the claim that file-based reflection is a general optimization pattern. Large variation would suggest that model choice, trace format, or task structure matters more than the reflector architecture itself.

The second signal is evidence of sustained production adoption. Teams should report whether optimized prompts continue performing after traffic, tools, and user behavior change.

A candidate can win an initial A/B test and then degrade as the environment shifts. Repeated evaluation cycles, rollback rates, and the lifespan of promoted configurations would reveal more than a one-time score.

The third signal is expansion beyond system prompts. AWS says trace analysis can guide changes to tool descriptions and reusable skills. Those recommendations would move AgentCore closer to optimizing the broader agent configuration.

That expansion would strengthen the product’s value if teams can attribute improvements and preserve safety boundaries. It would weaken the case if combined changes become difficult to review, test, or explain.

For builders, the immediate action is straightforward. Treat Amazon Bedrock AgentCore prompt optimization as an evidence-producing release workflow, not an automatic approval system. Start with a representative trace set, define an evaluator that reflects the real objective, and reserve unseen cases for validation.

Then compare the recommendation against the current configuration through offline evaluation before considering live traffic. Review prompt growth, safety language, sensitive data handling, and regressions outside the target metric.

The reflector benchmarks show that automated analysis can outperform slower search methods under AWS’s test conditions. The lasting advantage will depend on whether organizations can make the surrounding measurement system equally disciplined. What behavior would your evaluator reward today, and which costly failure would it still fail to see?