GEPA-Curator: Curated Learning for Self Improving Agents
Authors: Zack Yu, Nicholas Lee, Minjae Lee, Lakshya Agarwal, Luca Manolache, Wonjun Kang, Matei Zaharia, Michael W. Mahoney, Kurt Keutzer, Sehoon Kim, Amir Gholami
Large Language Models (LLMs) are increasingly used in multi-turn agentic workloads that require sustained interaction with complex environments. Existing reflective prompt optimizers such as GEPA learn from failed rollouts, but agentic failures can also come from prompt weaknesses, harness limitations, stochastic execution, or noisy judges. We argue that such failures may not provide useful learning signal, and may even be harmful; and thus it is essential to curate which tasks are provided to the prompt optimizer for better performance. We introduce GEPA-Curator, a framework that augments the prompt optimizer to select which agent experiences should shape prompt optimization. In particular, GEPA-Curator consists of two components: task curation, which filters out tasks that are likely to provide noisy or unreliable learning signals, and prior success retrieval, which selectively retrieves past successful trajectories for a task and provides them as additional context to the prompt optimizer. We evaluate GEPA-Curator on GoBrowse, ALFWorld, AppWorld, and τ-bench, using both Gemini 3.1 Pro and Claude Opus 5 as optimizer models. GEPA-Curator matches or exceeds the mean performance of both baselines, with gains of up to 20.7% over GEPA and 21.2% over ACE.
Figures & tables
Figure 1: GEPA-Curator system diagram. The prompt optimizer takes in a minibatch of tasks at each iteration and invokes the actor agent to execute them and performs reflective prompt optimization based on the resulting trajectories. The Curator augments the prompt optimizer by acting as an outer-loop process which traverses through the training dataset and constructs each minibatch to pass into the prompt optimizer. The Curator reads past execution trajectories for each task sampled from the training dataset and decides to run the task if doing so is likely to provide useful optimization signal (Section 3.1 ). The Curator can also pass prior successful trajectories for failed tasks as context to the prompt optimizer as a trusted reference example (Section 3.2 ). Once the curated training batch of selected tasks and successful context is constructed, it is passed to the prompt optimizer for execution and optimization. The resulting trajectories and evaluation outcomes are then written back to the task history for use in subsequent curation rounds.
Optimizer Model
Method
GitLab
Shopping
Shopping Admin
Reddit
Overall
Gemini 3.1 Pro
Seed
78.2± 2.5
73.5± 11.8
65.2± 6.2
72.6± 2.2
72.4± 2.4
GEPA
82.1± 2.7
83.8± 2.5
71.5± 2.0
77.6± 2.3
78.7± 0.6
GEPA-Curator
84.6± 1.5
85.8± 3.5
73.1± 1.9
85.0± 1.8
82.1± 1.7
Claude Opus 5
Seed
79.6± 2.3
73.9± 2.5
67.7± 2.9
71.3± 1.0
73.1± 1.8
GEPA
82.5± 1.8
80.5± 3.2
72.9± 2.4
81.9± 1.5
79.5± 1.2
GEPA-Curator
83.1± 3.9
86.5± 3.9
80.3± 2.9
88.2± 1.6
84.5± 1.0
Table 1: Comparison of the success rate (% with std) on 4 different domains (GitLab, Shopping, Shopping Admin, and Reddit) of the GoBrowse benchmark on the WebArena environment. We evaluate using seed prompt, as well as the prompt optimized by GEPA, and GEPA-Curator over held-out test set. GEPA-Curator exceeds the success rate of all baseline methods across the evaluated settings.
Optimizer Model
Method
ALFWorld
AppWorld Test-N
AppWorld Test-C
τ -bench
–
Seed
66.9± 2.4
8.9± 2.8
5.6± 0.5
52.0± 4.2
Gemini 3.1 Pro
GEPA
82.4± 2.9
38.0± 2.3
27.8± 2.1
75.4± 5.2
ACE
90.1± 1.3
55.7± 1.8
34.5± 1.4
80.6± 6.6
GEPA-Curator
91.8± 1.4
58.7± 1.9
46.2± 2.1
84.0± 4.8
Claude Opus 5
GEPA
95.8± 1.4
52.9± 5.7
32.5± 2.7
82.9± 2.0
ACE
89.7± 2.7
61.2± 1.7
33.4± 0.8
61.7± 5.9
Table 2: Comparison of the success rate (% with std) on additional agentic benchmarks: ALFWorld, AppWorld, and τ -bench. We evaluate using seed prompt, as well as the prompt optimized by GEPA, ACE, and GEPA-Curator over held-out test set. GEPA-Curator exceeds the success rate of all baseline methods across the evaluated settings with only one tie.
Method
Success (%)
Seed
78.2± 2.5
GEPA
82.8± 1.6
w/o Pareto selection
82.5± 1.9
GEPA-Curator (full)
88.6± 2.0
Task curation only
84.2± 2.9
Prior success retrieval only
84.7± 3.1
Table 3: Ablation results (% with std) on 200 GitLab tasks.
Figure 2: GEPA validation curves when Optimizable tasks are mixed with Easy , Impossible , or Flaky tasks. Curves are evaluated on the training set every four iterations and report tasks solved within each 16-task group; labels mark initial, peak, and final performance.
Method
Success (%)
GEPA
66.2
Numerical curriculum
62.5
Task curation only
67.4
GEPA-Curator
70.2
Table 4: Success rate (%) on the dataset composition with Flaky tasks, averaged over five evaluations of each optimized prompt. Task curation only omits prior success retrieval, whereas GEPA-Curator uses both components.
Figure 3: Diagnoses made by the Curator across the 1,581 GoBrowse training tasks and the primary causes assigned to impossible and evaluator-flaky tasks. Eight tasks received both impossible and flaky diagnoses because their diagnoses changed across iterations. The overview counts these overlaps as impossible, leaving 57 unique flaky-only tasks, while panel (c) includes 65 flaky diagnoses.
Table 8
Method
GitLab
Shopping
Shopping Admin
Reddit
GEPA-Curator
84.6± 1.5
85.8± 3.5
73.1± 1.9
85.0± 1.8
Efficient GEPA-Curator
83.8± 2.4
85.1± 1.4
73.3± 1.6
86.8± 2.8
Method
ALFWorld
AppWorld Test-N
AppWorld Test-C
τ -bench
GEPA-Curator
91.8± 1.4
58.7± 1.9
46.2± 2.1
84.0± 4.8
Efficient GEPA-Curator
90.0± 1.0
67.1± 3.9
56.3± 1.5
84.0± 3.3
Table 7: Comparison between GEPA-Curator and Efficient GEPA-Curator of the success rate (% with std) on 4 different domains (GitLab, Shopping, Shopping Admin, and Reddit) of the GoBrowse benchmark on the WebArena environment and ALFWorld, AppWorld Test-N, AppWorld Test-C, and τ -bench.
Method
GitLab
Shopping
Shopping Admin
Reddit
Overall
Overall Acc.
GEPA
144.01
156.10
152.05
141.89
594.05
78.7
GEPA-Curator
210.64
186.46
201.27
178.51
776.88
82.3
Table 8: Estimated total optimization costs in USD. GEPA-Curator uses the efficiency-optimized version. AppWorld Test-N and Test-C share one optimization run. Overall Acc. (%) averages the four WebArena websites or the four non-WebArena evaluation settings, counting AppWorld Test-N and Test-C separately. The component breakdown is in Appendix D .
Appendix figures & tables8 assets
Supplementary material from the paper’s appendix.
Appendix
Website
Training tasks
Impossible
Flaky
GitLab
432
6(1.4%)
14(3.2%)
Shopping
351
5(1.4%)
16(4.6%)
Shopping Admin
449
4(0.9%)
17(3.8%)
Reddit
349
3(0.9%)
18(5.2%)
Overall
1,581
18(1.1%)
65(4.1%)
Appendix
Table 9: Tasks that the Curator deemed impossible or flaky at any point during optimization. Counts in the two diagnosis columns are not mutually exclusive.
Primary cause
Tasks
Share
Harness/environment limitation
12
66.7%
Faulty or underspecified task
4
22.2%
Speculative diagnosis
1
5.6%
Reversed after revisit
1
5.6%
Total
18
100%
Appendix
Table 10: Primary causes of tasks that the Curator deemed impossible during optimization. Diagnoses are counted if they occurred at any point in the task history.
Primary cause
Tasks
Share
Harness/environment limitation
19
29.2%
Faulty or underspecified task
30
46.2%
Speculative diagnosis
7
10.8%
Reversed after revisit
5
7.7%
Reliable success with occasional false negatives
4
6.2%
Total
65
100%
Appendix
Table 11: Primary causes of tasks that the Curator deemed to have a flaky or broken evaluator. False negatives denote cases where reliable success behavior was sometimes rejected under harsher or shifting evaluation criteria.
Curator diagnosis
Early
Middle
Late
Mastered
3.13
5.18
5.81
Impossible
5.50
7.67
8.75
Flaky
1.33
5.00
3.92
Appendix
Table 12: Mean length of the completed skip streak immediately preceding a task rerun, grouped by rerun phase. Open streaks and reruns in partial final epochs are excluded.
Early
Middle
Late
Website
Paired
No hist.
Abst.
Paired
No hist.
Abst.
Paired
No hist.
Abst.
GitLab
5/144
111/144
28/144
174/296
51/296
71/296
88/132
18/132
26/132
Shopping
22/169
109/169
38/169
206/273
55/273
12/273
58/94
31/94
5/94
Shopping Admin
5/235
211/235
19/235
32/387
249/387
106/387
86/375
192/375
97/375
Reddit
18/180
119/180
43/180
194/267
29/267
44/267
167/193
6/193
20/193
Overall
6.9%
75.5%
17.6%
49.6%
31.4%
19.1%
50.3%
31.1%
18.6%
Appendix
Table 13: Historical-success pairing among failed reflection instances. Paired indicates that a historical success was selected and supplied to reflection; No hist. (No history) indicates that the task had no prior successful trajectory; and Abst. (Abstention) indicates that a non-empty success pool existed but the Curator selected no anchor. Training iterations are divided into approximately equal thirds separately for each website.
Website
Eligible
Relevant selection
Meaningful abstention
Either
GitLab
155
3(1.9%)
10(6.5%)
12(7.7%)
Shopping
144
5(3.5%)
9(6.3%)
13(9.0%)
Shopping Admin
102
4(3.9%)
24(23.5%)
27(26.5%)
Reddit
153
5(3.3%)
7(4.6%)
12(7.8%)
Overall
554
17(3.1%)
50(9.0%)
64(11.6%)
Appendix
Table 14: Task-level analysis of the Curator’s use of historical success states. Eligible tasks are those for which a failed rollout entered reflection while the task had a non-empty historical success pool. Either is the deduplicated union of relevant selection and meaningful abstention.
Benchmark
Method
Rollout
Reflector
Curator
Total
GoBrowse GitLab
GEPA
133.20
10.81
–
144.01
GEPA-Curator
161.38
24.47
24.80
210.64
GoBrowse Shopping
GEPA
147.41
8.69
–
156.10
GEPA-Curator
138.30
22.78
25.38
186.46
GoBrowse Shopping Admin
GEPA
140.69
11.36
–
152.05
GEPA-Curator
150.58
26.10
24.60
201.27
Appendix
Table 15: Estimated optimization costs in USD, separated into rollouts, reflection, and curation. Rollout costs include WebArena judge calls. Overall rows sum the costs within each benchmark group. Totals are computed before rounding. For ACE, the Reflector column combines reflection and playbook curation. GEPA-Curator refers to the version optimized for efficiency. The Curator column covers task scheduling and success anchor updates.
AIME 2025
IFBench
HoVer
HotpotQA
Seed
27.3
36.9
35.3
42.3
GEPA
64.7
45.2
51.0
66.3
GEPA-Curator
65.3
45.9
55.3
65.0
Appendix
Table 16: Test performance (%) on QA benchmarks from the GEPA evaluation suite.
LLM agents in interactive environments are highly sensitive to their prompts, yet prompt engineering remains a manual, task-specific process. We introduce an automated prompt optimization framework for LLM agents that decomposes the observation-to-action pipeline into a goal-conditioned descriptor agent and an action selection agent, and iteratively refines each module's prompt through an LLM-driven evolutionary loop guided by environment returns. We propose a behavior analyzer to attribute episode outcomes to specific prompt components, and a mutator to propose targeted revisions to the prompt, before validating them through environment rollouts. We evaluate on all five BabyAI tasks in the BALROG benchmark, comparing our pipeline against BALROG's RobustCoTAgent under both plain and guided prompt initializations. Optimization improves performance consistently across tasks and conditions, without requiring updates to the model weights. On PutNext, a multi-step coordination task where the RobustCoTAgent achieves 0% success, our framework reaches up to 72.5% success rate using the same underlying LLM with optimized prompts. These results suggest that a multi-agent framework, combined with automatic prompt optimization, enhances LLMs without the need for fine-tuning or extensive human supervision.
Prompt optimizers automate the search for prompts that improve language-model performance, but existing methods rely on a predefined optimization procedure: the algorithm determines which candidates to explore and how the search progresses, while the language model generates or refines prompt proposals. We introduce RLMOpt, a prompt optimizer that makes the search policy itself language-model-driven through a recursive language model (RLM). The RLM agent operates over a tool-based environment, inspecting task information, analyzing failures, generating candidates, allocating evaluation budget, and deciding when to stop. A deterministic harness complements the agent by enforcing objective scoring, Pareto-based selection, and regression constraints. We evaluate RLMOpt across four benchmarks spanning structured clinical information extraction (Chia), multi-hop question answering (HotpotQA), verifiable instruction following (IFBench-2025), and multi-turn tool-calling agents (BFCL). In a matched comparison at a single seed, RLMOpt obtains the best held-out score on all four benchmarks and leads the four-task mean (0.610 against 0.589 for GEPA). Repeating each benchmark across seeds yields 11 matched benchmark-seed comparisons, in which RLMOpt outperforms GEPA in 9 cases. Across all 11 runs, it never produced a prompt that underperformed its seed, whereas GEPA fell below its starting point twice. It is also more efficient, achieving these results with fewer search rollouts while producing prompts that are 27-79% the size of those produced by GEPA. Our results further show that optimization gains are determined primarily by the headroom available in the seed prompt, rather than by the search budget. Efficient optimization therefore depends on reaching the available headroom reliably and with minimal search
Large language model (LLM) agents require post-training methods that can improve long-horizon decision making from environment feedback. However, existing agentic post-training pipelines often treat data curation as a fixed preprocessing step, focusing mainly on data augmentation while neglecting filtering, refinement, and adaptation to downstream failures. We propose CurateEvo, a failure-driven dynamic evolution framework for agentic post-training data curation. CurateEvo represents the curation strategy as executable code and iteratively rewrites it using failed trajectories from a held-out development set. At each epoch, the evolved strategy transforms a fixed raw corpus into supervised fine-tuning data, reinforcement learning data, and an inference-time memory bank. The evolution process first improves effectiveness by diagnosing recurring failure modes and augmenting, filtering, or refining data accordingly, and then improves efficiency by pruning redundant or low-utility training turns under a cost-aware objective. Experiments on ACEBench-Agent, BFCL-V4, and τ^2-Bench under both labeled and wild-data settings show that CurateEvo consistently outperforms prior curation methods, improving average scores by 3.2 and 2.7 points, respectively. Further analyses demonstrate that CurateEvo is compatible with different post-training recipes and substantially reduces curation overhead.