Source-linked AI summary
FlashEvolve: Accelerating Agent Self-Evolution with Asynchronous Stage Orchestration
Zhengding Hu, Mingge Lu, Zhen Wang, Jixuan Ruan, Chang Chen, Zaifeng Pan, Yue Guan, Ruiyi Wang, Zhongkai Yu, Chao Zhang, Yufei Ding
TL;DR
Agent evolution is costly because synchronized, imbalanced LLM-heavy stages limit wall-clock efficiency. FlashEvolve replaces them with asynchronous workers and queues, manages resulting staleness through version-aware policies, and adds speculative and adaptive controls. On GEPA workloads, it achieves 3.5× higher proposal throughput than synchronous GEPA on local vLLM, while also generalizing to ACE and Meta-Harness.
Problem
Synchronized and imbalanced LLM-heavy stages make agent evolution expensive in wall-clock time.
Method
FlashEvolve uses asynchronous workers and queues, artifact-version tracking, staleness-aware handling, speculative completion, and adaptive workflow control.
Results
3.5× higher proposal throughput than synchronous GEPA is achieved on local vLLM serving, with the execution model also applying to ACE and Meta-Harness.
Takeaways & Limitations
Inspectable language-space staleness can be patched or discarded, allowing stale artifacts to provide useful evolution signal rather than only delayed work.
Takeaways & Limitations
The framework supports only a limited set of evolution algorithms, and each new integration requires algorithm-specific implementation effort.
Abstract
from arXiv · showhide
LLM-based evolution has emerged as a promising way to improve agents by refining non-parametric artifacts, but its wall-clock cost remains a major bottleneck. We identify that this cost comes from synchronized stage execution and imbalance inside each LLM-heavy stage. We present FlashEvolve, an efficient framework that replaces synchronized execution with asynchronous workers and queues, allowing different stages and steps to overlap. To handle data staleness introduced by asynchrony, FlashEvolve tracks artifact versions and applies different policies to update, discard, or patch stale artifacts. Unlike weight-space staleness in asynchronous RL, language-space staleness is inspectable and repairable: a stale artifact is not just delayed work, but readable evidence that the LLM can reflect on, revise, and turn into useful evolution signal. FlashEvolve further improves throughput and token efficiency with speculative stage completion and adaptive workflow control. On GEPA workloads, FlashEvolve improves proposal throughput by $3.5\times$ on local vLLM and $4.9\times$ on API serving over synchronous GEPA. The same design also applies to ACE and Meta-Harness.
1 Introduction
Agent self-evolution refines non-parametric artifacts without weight updates, but synchronized, imbalanced LLM stages make evolution costly. FlashEvolve addresses this with asynchronous orchestration and staleness-aware artifact handling.
- Motivation: Agent self-evolution refines prompts, context, memory, harness code, and generated programs instead of updating model weights.These methods avoid the labeled trajectories and gradient updates required by supervised fine-tuning and reinforcement learning.
- Motivation: More than 2 hours are required for stable improvement on IFBench with GEPA, despite efforts to reduce the number of evolution steps.A single GEPA step takes approximately 2 minutes, while Combee parallelization stretches it to approximately 2.8 minutes.
- Efficiency bottlenecks: Sequential dependencies prevent later LLM-heavy stages from overlapping with earlier stages.Evolution stages include executing the current artifact, proposing a candidate, and evaluating it.
- Efficiency bottlenecks: Long-tailed request lengths make the slowest samples determine each stage’s completion time, reducing effective batch size and resource utilization.This imbalance affects both local serving frameworks and API-based remote calls.
- FlashEvolve: FlashEvolve connects asynchronous workers with queues so artifact execution, proposal generation, evaluation, and pool updates overlap.Its staleness-aware policies track versions and can compare, discard, or reflectively patch stale artifacts.
2 Background and Motivation
Agent evolution adapts LLM systems by refining artifacts beyond model weights, but serial stages and synchronization barriers impose substantial wall-clock costs. FlashEvolve targets these bottlenecks by converting the loop into an asynchronous streaming workflow.
- Agent evolution: Agent evolution adapts systems by refining prompts, memories, harnesses, and generated programs through LLM reflection and external evaluation.GEPA and ACE evolve prompts or contextual playbooks, while Meta-Harness and related methods evolve harnesses or generated programs.
- Motivation: 50 minutes are needed for GEPA to complete 49 IFBench steps, and 134 minutes for 411 HotpotQA steps, even with vLLM.
- Efficiency bottlenecks: Serial stage execution makes total step time the sum of stage durations, while synchronization barriers force each stage to wait for its slowest request.Stage durations are themselves highly imbalanced, and request output lengths have long-tail distributions.
- Design challenges: Asynchrony creates artifact-level staleness, while naive parallel scaling can overfeed slow stages, enlarge queues, and waste LLM work.FlashEvolve therefore must jointly manage staleness and workload balance.
- FlashEvolve: FlashEvolve uses asynchronous workers and queues to overlap stages and evolution steps while tracking artifact versions for stale-item detection.It adds staleness-aware handling, speculative completion, and adaptive workflow control.
3 FlashEvolve: Asynchronous Framework for Agent Evolution
FlashEvolve replaces synchronized evolution with queued asynchronous workers, then manages staleness, partial completion, and workload imbalance. Its design combines version-aware policies, speculative validation, and adaptive worker allocation.
- Asynchronous orchestration: Asynchronous workers connected by queues let different evolution stages and steps overlap instead of waiting for complete stage results.Queue items carry artifact state and pool version so workers can detect stale items.
- Asynchronous orchestration: Larger per-stage worker counts increase concurrency but also increase the chance that queued items use older artifact-pool states.
- Staleness-aware handling: Full Async maximizes throughput by allowing all items through, whereas Guarded Async discards items whose version gap exceeds ∆max.Guarded Async permits item i only when ∆i = v − v_i is at most ∆max.
- Staleness-aware handling: Reflective Async inspects stale items against intervening pool updates, patches useful changes against the current pool, and discards unusable ones.This reuses useful stale items while avoiding uncontrolled stale updates.
- Speculative completion: Speculative completion releases partial rollout or evaluation results after an α_spec fraction of requests, allowing downstream workers to start early.Speculative evaluation inserts a candidate only when its partial score exceeds the current pool score; full evaluation later confirms or removes it.
- Speculative completion: Validation-set reordering moves samples that pass for w consecutive rounds later, leaving more discriminative samples in the speculative prefix.FlashEvolve sets w = 3 to reduce sensitivity to one-round noise.
- Adaptive workflow control: Adaptive workflow control compares stage production rates and adjusts worker counts to reduce bottlenecks and queue overfeeding.Worker counts increase below half the median stage rate and decrease above twice the median, with changes limited to one worker per adjustment.
- Evaluation: Table 1 compares whole-system output token rate with new candidate artifact generation rate on GEPA workloads.
4 Evaluation
FlashEvolve is evaluated across GEPA, ACE, and Meta-Harness using local and API serving, with experiments covering throughput, fixed-budget evolution, long-time behavior, staleness handling, worker control, and speculative completion.
- Throughput: FlashEvolve improves LLM throughput by 3.4× over GEPA on local vLLM and 2.9× over GEPA with API-based serving.It also exceeds the best Combee setting by 1.9× locally and 1.5× for API serving.
- Throughput: FlashEvolve raises proposal throughput by 3.5× over GEPA locally and 4.9× over GEPA with API-based serving.Across settings, it sustains more than 5.9 proposals/min and reaches up to 11.4 proposals/min.
- GEPA evolution: Within 30 minutes, FlashEvolve achieves a 1.43× average normalized evolution rate across three GEPA workloads where the baseline makes measurable progress.On IFBench, the validation score rises from 87.6 to 90.6 with a 2.27× normalized evolution rate; on AIME, it reaches 15.0% versus 10.0% for GEPA and Combee.
- Long-time evolution: Over 180 minutes, FlashEvolve reaches 91% on IFBench in 39.3 minutes and reaches 66.41% on HotpotQA at 56.1 minutes while baselines remain below 65%.On IFBench, Combee reaches the same score region after 104.2 minutes and eventually approaches a similar final score.
- Staleness handling: Reflective Async reaches 94.3% on IFBench within 30 minutes, outperforming Full Async and Guarded Async in evolution efficiency.Its repairs discard task-specific formulas while distilling transferable principles such as stricter constraint checking and self-contained reasoning into prompt patches.
- Ablations: Adaptive worker control achieves the highest accepted proposal throughput, while speculative completion reaches 3.15 validations/min and improves validation score by 4.49 percentage points at α3_spec=0.25.Speculative completion is treated as optional because its accuracy and efficiency depend on αspec and dataset characteristics.
5 Conclusion
FlashEvolve accelerates agent evolution by overlapping LLM-heavy stages while using versioning and staleness-aware policies to preserve evolution semantics. Its current scope is limited, with broader algorithm and artifact coverage requiring future integration work.
- 5 Conclusion: FlashEvolve overlaps LLM-heavy stages and evolution steps using asynchronous workers, queues, artifact-pool versioning, and staleness-aware policies.Its policies update, discard, or patch stale artifacts, while speculative completion and adaptive workflow control further improve efficiency.
- 5 Conclusion: 3.5× higher proposal throughput is achieved over synchronous GEPA on local vLLM serving.
- 5 Conclusion: The execution model generalizes to context evolution with ACE and harness-code evolution with Meta-Harness.
- 5 Conclusion: FlashEvolve currently supports only a limited set of agent-evolution algorithms, and integrating each new algorithm requires algorithm-specific implementation effort.New integrations must define stages, queue items, artifact state, and update rules within the worker-and-queue abstraction.
- 5 Conclusion: Evaluation covers representative prompt, context, and harness-code evolution workloads, leaving broader algorithm and artifact coverage for future work.Planned extensions include memory, tool-use policies, generated programs, and a more general plugin interface.