Six Lessons for Reliable Agent Optimizer Gains on Harder Agents

Authors: Abi Komma, Charles Kim, Luffy Chen, Vivek Bhadauria, Morteza Ziyadi, Victor Dibia, Ilya Matiach

What happens when you push agent optimizer to its limits - larger datasets, tool-calling agents, and hybrid evaluators? We found that the optimizer is as good as what surrounds it. Here's what we learned from five harder experiments.

1/ Turning up the difficulty 

In our previous post, we showed agent optimizer in Foundry Agent Service improving all six prompt agents we tested. Those experiments used smaller datasets and focused mainly on system instructions. 

For this round we explored harder conditions. The datasets are larger and more diverse, the evaluation signals are richer, and several of them are now hosted agents with tool-calling. We also let the optimizer edit tool descriptions, not just system prompts. These conditions showed that the optimizer is only one part of the outcome. The search budget, the evaluator, and especially what the reflection model sees all shape what the loop learns. With a capable reflection model in place, the quality of the evidence it receives matters as much as the search itself. 

We tested five agents across instruction-following, multi-hop retrieval, financial reasoning, math-expression calculation, and customer-support policy. The training and validation sets are several times larger than in the first post. All experiments ran gpt-4o-mini as the agent and gpt-5 as the reflector. The one exception is FinQA, where we also tested a stronger agent model. 

Two Mathbot experiments test the impact of a hybrid evaluator. Both variants return a deterministic exact-match score. In the plain variant, that score is all the reflector gets, along with the user request and final response. In the hybrid variant, the evaluator also returns a reason field that carries the tool trace and an LLM-judge diagnosis of what went wrong. This lets the reflector spend its effort on finding patterns across failures instead of first working out what each failure was. 

2/ Results, and what drove them 

The completed experiments each showed improvement at this larger scale, and the runs also made clear what the optimizer needs around it to produce those gains. 

Figure 1. Before and after agent optimizer across experiments.

IFBench tests precise instruction following. Each prompt adds verifiable output constraints, such as a word limit or a required keyword count, and a checker verifies that the response satisfies every one. It had the most room to improve and moved the most, with agent optimizer changing only the system instruction.  

In HOVER, the agent verifies a claim by searching Wikipedia across multiple hops, since the evidence is spread over as many as four articles, and then labels the claim as supported or not. Label accuracy on this hosted tool-calling agent improved by 4 points.  

The clearest lesson came from what the reflector could see. Mathbot is a controlled tool-repair experiment. We deliberately broke the seed description of its calculator tool and let the optimizer change only that description, so the +97 point jump reflects a repair from a broken starting point. On hosted agents, one way we showed the reflector better evidence is through the evaluator. We built a custom endpoint evaluator in Foundry that supplies this evidence. It returns a deterministic exact-match score plus a short reason that carries a compact tool trace and a one-line diagnosis. With that evidence in place, agent optimizer lifted the hosted run to 98.5%.  

The airline support agent showed the same pattern on a more realistic hosted task. Its hybrid endpoint evaluator scored each answer on the action taken, the eligibility decision, and the resolution, and returned a short reason explaining the failure. Agent optimizer raised accuracy from 80.2% to 89.2%. 

FinQA was the one case where a better prompt was not enough. Its evaluator gives rich feedback, a deterministic score plus a diagnosis of the exact rule each run missed, yet on gpt-4o-mini the score held at about 68.5% before and after optimization: the optimizer wrote good advice about units, signs, and rounding, but the agent could not do the math to use it. A stronger agent was what helped. Swapping in gpt-5 turned the same advice into a gain of about +4 points, and when we let the optimizer choose the model itself from gpt-4o-mini, gpt-4.1, and gpt-5, it picked gpt-5 for its best candidate, adding about +3.5 points. When agent capability is the ceiling, prompt rewriting hits diminishing returns; the fix is to let the optimizer upgrade the model. 

3/ Six lessons for your own runs 

Given a sound setup, the optimizer found better instructions and tool descriptions. How much it improved depended on the setup around it. Here is what we learned. 

1. What the reflector sees decides the outcome. The reflector can only fix what it can see. Mathbot went from 1.5% to 98.5% with the tool trace in view and stayed at 1.5% without it. Route the tool names, arguments, outputs, and errors that explain the score into reflection. Do not dump the whole raw trace. Long traces add noise, so select and clean the useful steps.
2. Give a reliable and informative score.  Code-based evaluators provide deterministic scores, but pass-or-fail results often do not explain what went wrong. Prompt-based evaluators use an LLM judge to return both a score and a reason, giving the reflector more useful feedback, though the result can hallucinate or carry bias. If you need both reliability and an explanation, an endpoint-based evaluator can combine them. Code determines the score, and the LLM explains the failure. Because endpoint-based evaluators require more setup, use this hybrid signal only when it is useful. Validate any evaluator with null, random, and prompt-injection controls before relying on it. Strong results on these controls may indicate benchmark leakage.
3. Use a capable reflection model. The reflector reads each failure and writes the next instruction, so it does the hardest reasoning in the loop. A weak model there produces weak edits even from good evidence. The agent can often run on a smaller model, but not always. When the task itself is reasoning-heavy, its capability sets the ceiling too, so match each model to the job. 
4. Keep a real and current validation set. Small sets are noisy, and a gain on them is hard to trust. Keep the set close to your production distribution and refresh it over time. Mining cases from production traces is a practical way to do both.
5. Give the search enough budget. The search explores only as many candidates as max-candidates allows, and a useful win sometimes appears late in the run. A small budget can end the search before the best candidate surfaces. At the same time, watch for prompt bloat as edits accumulate over longer runs. If the optimized prompt grows too long, it can hurt the agent's performance in other ways.
6. Fix the tools and the system first. A better tool description helps only when the tool itself works. If the implementation is wrong, no wording change can repair the agent. The same holds for a stale corpus, a wrong evaluator, or bad data. Optimization refines a working system. It does not rescue a broken one. Today, agent optimizer edits instructions and tool descriptions, and it can also select a model from a list you provide, while leaving the underlying tools and schemas unchanged. A future, more dynamic system could modify the tools and schemas themselves to reach deeper faults, but that requires tighter supervision to keep edits aligned with the task.

4/ What comes next 

Our first experiments showed agent optimizer improving prompt agents. This second round shows the gains continuing with larger evaluation datasets, hosted tool-calling agents, and hybrid evaluation. The hard work is building the infrastructure, evaluators, and evidence pipelines that make each search more effective. The experiments taught us as much about the loop around the optimizer as about the optimizer itself. The next round of investigations will focus on two areas. 

1. Lowering the starting cost. Today a customer needs a curated dataset and a validated evaluator before the first optimization run. We are testing workflows that generate starting assets from production traces, so teams can begin with less upfront work. 
2. Richer loop control.  The current loop optimizes a fixed set of artifacts with fixed evidence. We are exploring whether the developer or the loop itself can select what to change or add, such as new skills, and what context to show the reflector, making the whole process more dynamic. 

The goal is a safe, repeating cycle. Collect traces, build datasets, validate evaluators, optimize, check for regressions, get human approval, deploy, and monitor. 

Figure 2. Optimization is one step inside a larger, repeating loop. The gains still depend on the evaluators, data, and checks around it, and a person approves each change.

Microsoft Foundry provides a managed platform for the whole loop. It covers building prompt and hosted agents, connecting tools, tracing and observability, evaluation, content safety, and managed deployment and scaling. Agent optimizer drives the optimization step, and it works best when it is well connected to the rest. Good traces to learn from, trustworthy evaluators to score against, and safety and deployment checks around each change. 

5/ Learn more 

Ready to try agent optimizer on your own agents? Pick the path that fits you:

• Start now: Optimize a prompt agent in 5 minutes
• Understand the tool: Agent optimizer overview
• New to agents? Start with the agents overview
• Want the full context?: How agent optimizer performed in our previous tests
• Prefer video? Watch the Build session