PaperlayerView exact revision on arXiv

Source-linked AI summary

Evoflux: Inference-Time Evolution of Executable Tool Workflows for Compact Agents

Kushal Raj Bhandari, Ling Yue, Ching-Yun Ko, Dhaval Patel, Shaowu Pan, Pin-Yu Chen, Jianxi Gao

arXiv:2606.12674v1cs.AI

TL;DR

Compact agents must construct executable, evidence-grounded workflows, but scarce teacher traces rarely cover repairing failures over changing tool catalogs. Evoflux uses inference-time evolutionary search over typed workflow edits and raises held-out execution feasibility from roughly 3% to 17–24% across small planners.

  • Problem

    Scarce teacher-trace distillation rarely covers the recovery behavior needed for compact agents to repair executable workflows over changing tool catalogs.

  • Method

    Evoflux uses inference-time evolutionary search over typed workflow edits, execution feedback, adaptive intensity, meta-guided redesign, and diversity pruning.

  • Results

    Roughly 3% to 17–24%: Evoflux raises held-out execution feasibility across small planners, while SFT and SFT+DPO provide unreliable gains.

  • Takeaways & Limitations

    Execution-grounded search is more reliable than small-budget finetuning for compact tool agents in the evaluated setting.

  • Takeaways & Limitations

    The conclusions are scoped to MCP-Bench and the evaluated compact planners, not all deployment environments or frontier-scale tool-use systems.

Abstract

from arXiv · show

Compact language models (LMs) reduce cost, latency, and deployment risk for tool agents. Yet MCP-style tool use requires more than isolated function calling: an agent must discover tools from live catalogs, satisfy schemas, preserve dependencies across intermediate outputs, and ground final responses in executed evidence. Small planners often generate plausible workflow graphs that fail under tool resolution, parameter validation, dependency tracking, or execution. We argue that this failure mode is poorly handled by small-corpus distillation. A few hundred teacher traces can teach workflow format, but rarely cover the recovery behavior needed to repair failed plans over changing tool catalogs. We introduce Evoflux, an inference-time evolutionary search method that treats compact tool use as the repair of executable tool workflows. It evolves typed workflow graphs through structured edits, execution feedback, adaptive intensity, meta-guided redesign, and diversity pruning. On held-out MCP-Bench tasks spanning live MCP servers and 250 tools, Evoflux raises execution feasibility from roughly 3% to 17-24% across small planners. In contrast, SFT and SFT+DPO on the same search-mined data match, underperform, or collapse below zero-shot performance; ReAct reaches higher peaks, but with higher variance and token cost. These results show that execution-grounded search is more reliable under scarce teacher-trace budgets.

1 Introduction

Evoflux frames compact MCP-style tool use as executable workflow repair rather than one-shot function calling. It addresses brittle planning under changing catalogs and scarce teacher traces through inference-time evolutionary search over typed workflows and execution feedback.

  • Problem setting: MCP-style agents must construct executable workflows that discover tools, satisfy schemas, preserve intermediate dependencies, and ground responses in observed execution.This reframes tool use as building a typed program whose steps compile, execute, and carry evidence forward.
  • Motivation: Compact planners are attractive for lower cost, latency, and privacy exposure but remain brittle on the resolution, validation, and dependency demands of MCP workflows.Their generated graphs may appear plausible while failing during tool resolution, parameter validation, dependency tracking, or execution.
  • Train-versus-search tradeoff: Small-corpus finetuning may carry downside risk for compact models, motivating a comparison between weight updates and inference-time repair under scarce teacher traces.The paper studies whether compute should be spent on finetuning or online search over the actual task, catalog, and execution environment.
  • Evoflux: Evoflux evolves typed workflow graphs through structured edits, execution feedback, adaptive intensity control, meta-guided redesign, and action-hash diversity pruning.The compact model serves as a proposal operator inside a bounded execution-and-repair loop rather than generating workflows only once.
  • Evaluation: The evaluation compares zero-shot decoding, SFT, SFT followed by DPO, ReAct, and Evoflux on identical held-out MCP-Bench tasks using the same realistic small-budget corpus.This tests whether search-mined traces transfer more effectively through model weights or execution-time repair.

2 Problem Setup

The problem setup models compact tool-using agents as planners that generate typed, executable workflows from natural-language requests, live MCP catalogs, and stateful environments. Evoflux is evaluated as bounded inference-time search across deployment regimes, using a held-out split to compare execution-based performance against training configurations.

  • Problem formulation: Each query is a triple q = (x, T, E), and the planner emits a graph g that executes in E while satisfying x.Here, x is the request, T catalogs MCP servers and tools, and E is the stateful execution environment.
  • Workflow representation: A valid workflow graph contains typed tool nodes, dependency edges, optional validators, and a terminal output node.Tool nodes bind server and tool identifiers, parameter assignments, and upstream parents whose outputs feed later arguments.
  • Evaluation objective: The objective targets high-scoring workflows under a bounded inference-time search budget rather than one-shot final-workflow decoding.Training is treated as a baseline configuration rather than the central commitment.
  • Evaluation protocol: MCP-Bench is partitioned into Dsearch for search development and Deval for held-out comparisons among deployment configurations.Deval never enters training or prompt tuning, and weight updates are beneficial only if they improve execution-based performance over inference-time evolution on the same smaller model.

3 Method

Evoflux searches for executable MCP workflows at inference time by compiling, validating, and executing planner proposals, then refining them through typed edits and execution evidence. Adaptive intensity, meta guidance, and pruning balance targeted repair with broader redesign while retaining executable candidates.

  • Workflow construction: Evoflux compiles planner-proposed symbolic workflows, validates schemas and dependencies, executes feasible candidates, and scores them to drive evolutionary search.Candidates failing parsing, compilation, schema validation, dependency checks, or execution are marked infeasible with error evidence.
  • Search control: The search maintains a bounded population and best observed score, using meta guidance and pruning to alternate local repair with broader workflow redesign.The planner supplies initial and repair proposals, while execution outcomes determine which variants survive.
  • Typed edit language: Typed edits target MCP failure modes through tool swaps, parameter revisions, dependency bindings, and workflow insertions while preserving compilability.Edits address unavailable tools, schema errors, weak grounding, and missing dependencies.
  • Execution evidence: Execution evidence records node-level tool resolution, parameter validity, upstream availability, execution outcomes, malformed outputs, and downstream failures for targeted mutation.Mutation uses compressed failure context for exploitation and weighted stacked random edits for exploration.
  • Adaptive control: Adaptive intensity responds to recent progress, increasing exploration when search stalls and concentrating on stronger candidates when improvements accumulate.Independent probability draws control parent selection and exploratory versus exploitative mutation styles.

4 Results and Analysis

Evoflux improves workflow scores and execution feasibility through search, with compact planners showing distinct quality–token-cost tradeoffs. On held-out tasks, Evoflux generalizes more reliably than trained checkpoints, while ReAct can peak higher at greater variance and cost.

  • Search split: Evoflux raises every planner’s search-discovered score: sonnet-4-5 gains 1.32 points, llama3-70b gains 1.34 points, and Qwen3.5-4B rises from 1.44 to 3.35.Relative gains are largest for Qwen3.5-4B at 132%, followed by gemma-4-E2B at 90% and SmolLM3-3B at 74%.
  • Validation split: Valid Best produces the strongest validation behavior across four compact planners, while SFT and SFT+DPO remain close to Valid Init.The trained checkpoints use a single direct inference pass and occupy the lowest-cost band, but their low token use does not yield validation gains.
  • Validation split: ReAct can deliver the highest peak validation performance with a strong planner, but Evoflux provides more predictable improvements at lower token cost and variance.ReAct’s expanding trajectory history creates a rapidly increasing prompt-token burden, making the choice a deployment risk-control decision.
  • Validation split: 17% Valid Best execution success for Llama-3.2-3B recovers feasibility from roughly 3% Valid Init, while Qwen3.5-4B reaches roughly 24% from about 3%.Qwen3.5-4B’s search-split Best feasibility is roughly 58%, the highest feasibility rate in the validation comparison.
  • Validation split: SFT reaches about 5% execution success for Llama-3.2-3B, SFT+DPO falls to about 3%, and trained Qwen3.5-4B checkpoints produce essentially no feasible executions.The Qwen3.5-4B policies failed to emit usable plans and triggered heuristic fallback, so training on search-mined traces reduced validation feasibility.

5 Conclusion

Evoflux treats compact tool use as inference-time repair of executable typed workflows, addressing failures that plausible plans encounter in MCP-style environments. Held-out results favor execution-grounded search under scarce teacher-trace budgets, while identifying larger-data distillation and learned search controllers as future directions.

  • Approach: Evoflux uses a compact model as a proposal operator inside an inference-time evolutionary loop over typed workflow edits.The method targets failures in tool resolution, schema validation, dependency tracking, and execution.
  • Results: Roughly 3% to 17–24% execution feasibility is achieved by Evoflux across small planners on held-out results.This supports framing tool use as execution-grounded search rather than relying solely on training from limited traces.
  • Results: SFT and SFT+DPO on the same search-mined data provide no reliable gains and can collapse below zero-shot behavior.ReAct can reach higher peaks when the base planner sustains long trajectories, but incurs higher variance and token cost.
  • Implications: Under scarce teacher-trace budgets, spending inference compute on execution-grounded repair over the actual task and tool catalog is the more reliable lever.Future work includes larger data budgets, learned search controllers, and objectives that directly optimize the typed edit space.

Limitations

The conclusions are scoped to MCP-Bench and the evaluated compact planners, rather than all tool-use systems or deployment environments. The small-budget training comparison and execution-based evaluation leave open how larger datasets, alternative training methods, stronger judging, and broader cost reporting would change the practical picture.

  • Scope: The conclusions are limited to MCP-Bench and the compact planners evaluated, not all deployment environments or tool-use systems.The results concern compact agents under realistic budgets, and the study does not run the full deployment regimes on frontier-scale planners.
  • Training comparison: A few hundred search-mined traces were insufficient for reliable SFT or SFT+DPO gains in this setting, but this does not show distillation is inherently ineffective.Larger datasets, stronger hyperparameter sweeps, different negative construction, reinforcement learning, or applying Evoflux to trained checkpoints may change the outcome.
  • Evaluation: The evaluation depends on execution-based LLM judging and token-level cost accounting, leaving practical comparisons incomplete.Uniform stronger judging, judge-variance calibration, and reporting wallclock time, model calls, monetary cost, and tokens per solved task would sharpen comparisons with larger models or training runs.

Ethical Considerations … A.3 Growth signal and intensity

The paper addresses tool-agent safety by requiring controlled execution and privacy protections, while its search implementation compiles, checks, executes, and adaptively evolves typed workflows using recorded feedback. The implementation also supports caching, recovery, and exploration–exploitation control through growth-based intensity.

  • Ethical Considerations: Tool access can expose user data, files, APIs, and business systems, and search may amplify risk by trying multiple candidate workflows.Deployments should enforce permission checks, sandboxing, rate limits, audit logs, and safeguards for irreversible actions.
  • Ethical Considerations: Training and release traces should exclude private outputs and sensitive raw logs unless consent, access controls, and filtering are in place.Released traces are limited to research-safe derived artifacts needed to reproduce experiments.
  • A Search implementation details: The search implementation separates symbolic actions from compiled workflows, enabling edit deduplication, executable checks, stable hashes, caching, and diversity tracking.Actions retain queries, graph templates, typed edits, token costs, prompt parameters, and optional error context.
  • A.1 Action and candidate records: Candidates record workflows, scores, feasibility, execution results, planning attempts, and deterministic identifiers across initialization, evolution, and meta-guidance phases.Append-only history files support recovery after interruption.
  • A.2 Candidate construction: Each query begins with an unedited base graph that is compiled, checked for static feasibility, executed when feasible, and scored.Failures yield concise error context for retries within the configured retry budget, separating formatting errors from deeper planning failures.
  • A.3 Growth signal and intensity: The accumulated growth signal is an exponential moving average of squared improvements.This signal drives the system’s adaptive exploration intensity.
  • A.3 Growth signal and intensity: Intensity controls parent selection: higher intensity samples parents uniformly, while otherwise tournaments select among high-scoring candidates.The same probability governs whether mutation uses random typed edits instead of an LLM-proposed edit.
  • A.3 Growth signal and intensity: Low growth increases exploration, whereas strong growth favors exploitation through the search policy.Exploration uses random typed edits and exploitation uses tournament-based selection among high-scoring candidates.

A.4 Heuristic fallback method … B.1.1 Supervised Fine Tuning Dataset

The system uses a deterministic heuristic fallback when model access or repeated model calls fail, constructing a bounded sequential tool graph without language-model tokens. Its training pipeline builds executable-graph datasets, splits them with leakage controls, and uses SFT examples that clone the best observed teacher workflows rather than oracle supervision.

  • A.4 Heuristic fallback method: The fallback returns heuristic=True with token_cost set to None, providing a deterministic execution floor but not schema, semantic, or multi-hop evidence reasoning.It favors guaranteed plan construction over plan quality and uses the query, optional server hints, and registered tool catalog.
  • A.4 Heuristic fallback method: The heuristic fallback activates when provider credentials are unavailable or after three failed model-call attempts with max_retries = 2.Exceptions are retried up to max_retries before _heuristic_plan(query) is called.
  • A.4 Heuristic fallback method: It ranks registered tools by query-token overlap, adds 10 points for hinted servers, and selects at most min(self.max_steps, 3) tools.The method can still select zero-score tools when no positive overlap exists.
  • A.4 Heuristic fallback method: Selected tools form a strictly sequential dependency graph, with each later tool depending on the preceding tool.This avoids speculative branching and simplifies dependency construction under fallback conditions.
  • B Dataset Splits and Validation: Both datasets use a 0.12 validation fraction and random seed 42, while DPO splits by query identifier to keep preference pairs together.SFT records are shuffled and split directly, preventing query-level leakage for DPO.
  • B Dataset Splits and Validation: Validation measures SFT JSON syntax, schema validity, teacher-workflow node coverage, score proxy, grounding proxy, and tool appropriateness proxy.These metrics test whether smaller models emit parseable workflows resembling teacher traces and use available tool servers.
  • B.1 SFT and DPO Dataset Construction: Both datasets represent candidates as structured executable tool graphs with explicit nodes, parameters, dependencies, and a terminal output node.This aligns training targets with the executable object evaluated at test time rather than unstructured text generation.
  • B.1.1 Supervised Fine Tuning Dataset: DSFT contains 177 examples, each using the highest-scoring Sonnet workflow per query; its average positive score is 6.4146, with values ranging from 3.5833 to 10.0000.Completion-only masking computes loss on the assistant workflow, targeting syntax, graph structure, tool selection, and parameter patterns; the data is behavior cloning, not oracle supervision.

B.1.2 DPO Preference Dataset … D.1 Subskill profile before and after search on the Search Split

The paper constructs a diverse execution-based DPO preference dataset and specifies shared search and validation hyperparameters. On the search split, evolution most improves smaller planners’ tool matching and task completion, while grounding, parameter accuracy, dependency awareness, and parallelism remain weaker.

  • B.1.2 DPO Preference Dataset: Bucketed negative selection spans all 16 action buckets and diversifies rejected workflows across action patterns, tool choices, and edit histories.This broadens coverage of failures such as weak tool selection, missing parameters, poor grounding, and broken dependencies, although zero-edit negatives dominate.
  • B.1.2 DPO Preference Dataset: 624 preference pairs use higher-scoring workflows as chosen candidates and lower-scoring alternatives as hard negatives for the same task.Each record includes the prompt, chosen and rejected workflows, query identifier, scores, and score gap.
  • B.1.2 DPO Preference Dataset: The average chosen score is 6.3945 versus 3.2654 for rejected workflows, producing a mean score gap of 3.1291.The gap ranges from 1.0000 to 9.7222, and nearly all pairs lie above the diagonal in the chosen-versus-rejected scatter plot.
  • B.1.2 DPO Preference Dataset: DPO examples average 445.3 words, with a 95th-percentile total length of 624.0 words.Prompts dominate length because they contain task and tool-catalog context, while serialized chosen and rejected workflows are shorter.
  • C Hyperparameter Configuration: Tables 2–6 use default hyperparameters across five experimental stages, with the same values for search and validation unless otherwise stated.Validation disables perturbations by setting perturbation_scale=0.0.
  • D.1 Subskill profile before and after search on the Search Split: Search most clearly improves tool selection, tool appropriateness, and task completion; Qwen3.5-4B approaches the llama3-70b contour for tool appropriateness.Typed edits can repair semantic tool-matching errors when a plausible workflow skeleton already exists, while execution feedback improves partially correct final answers.
  • D.1 Subskill profile before and after search on the Search Split: Grounding and parameter accuracy improve less, while dependency awareness and parallelism show modest gains across planners.After search, smaller-agent bottlenecks increasingly involve binding correct values and preserving intermediate evidence rather than only finding plausible tools.

D.2 Subskill profile before and after search on the Validation Split

Evoflux primarily repairs executable tool-use mechanics, with gains concentrated in selection, appropriateness, parameter accuracy, and grounding. Results also vary by planner: ReAct leads Qwen3.5-4B, while training improves Llama-3.2-3B but remains below Valid Best.

  • Subskill profile: For Llama-3.2-3B, Valid Best raises the single-server overall score from 0.912 to 2.29.Tool appropriateness also climbs from 1.22 to 3.5.
  • Planner dependence: ReAct beats Valid Best for Qwen3.5-4B by 0.34 points on single-server, 0.51 on two-server, and 0.75 on three-server tasks.Across 3 servers, ReAct scores 3.95 overall versus 3.20 for Valid Best.
  • Planner dependence: Across 3 servers, ReAct scores 5.10 for tool appropriateness versus 3.88, and 5.12 for tool selection versus 4.59.Parameter accuracy is a narrow exception: ReAct scores 5.15 versus Valid Best’s 5.30 at three servers.
  • Training comparison: For Llama-3.2-3B, SFT and SFT+DPO each reach 0.956 at two servers versus 0.725 for Valid Init.At three servers, SFT reaches 1.01 and SFT+DPO 1.06 versus 0.683 for Valid Init, yet both remain below Valid Best at every tier.
  • Training comparison: Training learns some tool-call shapes but fails to internalize the adaptive repair process that produces successful workflows.This explains why trained checkpoints remain below Valid Best despite improving over Valid Init in some Llama-3.2-3B tiers.

E Graph Properties of the Workflows on the Validation Split

Workflow structure separates sequential depth from parallel width, revealing distinct strategies across planners. ReAct favors deeper trajectories, Evoflux favors broader execution-guided repair, while trained checkpoints may imitate graph shape without preserving executable dependencies.

  • E Graph Properties of the Workflows on the Validation Split: Workflow depth measures sequential dependency-chain length, while width measures parallel or branch-like actions at each workflow level.Together, these metrics distinguish chain complexity from workflow breadth.
  • E Graph Properties of the Workflows on the Validation Split: ReAct often generates the deepest workflows, especially Valid ReAct for Qwen3.5-4B, but accumulated context increases variance and token cost.Its trajectory format appends prior thoughts, tool calls, and observations to each subsequent step.
  • E Graph Properties of the Workflows on the Validation Split: Evoflux generally increases workflow width more consistently than depth, particularly on validation results.Its typed edits broaden workflows by adding or preserving evidence-gathering calls, lookup paths, and dependency-supporting steps.
  • E Graph Properties of the Workflows on the Validation Split: SFT and SFT+DPO sometimes match or slightly exceed initial workflow width, but the added structure does not yield reliable execution gains.The passages attribute this weakness to reproducing surface action patterns without preserving executable dependency structure.
  • E Graph Properties of the Workflows on the Validation Split: Workflow quality depends on how graph structure carries evidence rather than on graph size alone.ReAct spends compute on deeper trajectories, Evoflux on broader execution-guided repair, and effective workflows balance depth and width.

F Workflow Structure Analysis

Evoflux improves held-out workflow quality by repairing tool selection, argument binding, and dependency flow during inference. Validation evidence shows that this execution-guided process transfers beyond the search split, while SFT and SFT+DPO often imitate surface patterns without learning reliable workflow search.

  • Aggregate workflow structure: Evoflux improves weak initial graphs through execution-guided repair, whereas SFT and SFT+DPO often preserve shallow tool-call templates rather than reliable workflow structure.The aggregate validation trend shows Valid Best substantially outperforming trained checkpoints.
  • Representative workflows: 2.37: Evoflux repairs huge_icons_000 by starting with icon listing and search instead of irrelevant paper-search tools, though platform-usage calls still limit the score.The initial workflow scores 1.00, while Evoflux raises it to 2.37 through more task-relevant tool-family selection.
  • Representative workflows: 4.93: Evoflux repairs context7_000 by resolving library identifiers, binding them to documentation retrieval, and routing retrieved content into synthesis.The initial workflow scores 1.20; Evoflux succeeds because its edges carry usable evidence rather than merely adding calls.
  • Aggregate workflow structure: Workflow quality depends on correct tool selection, grounded argument binding, and dependency preservation, which Evoflux improves at inference time.Trained checkpoints often learn the surface shape of successful traces but fail to reproduce the adaptive repair process.
  • Validation conclusions: Both Valid Best scores exceed trained-checkpoint means by more than a factor of two, while Valid Best recovers roughly the Best score range for Llama-3.2-3B and roughly two-thirds for Qwen3.5-4B.These validation results support transfer beyond the search split.
  • Validation conclusions: SFT and SFT+DPO match or underperform Valid Init for both planners, and Qwen3.5-4B suffers complete planning collapse after training.The execution histories that produce useful inference-time variants do not encode reliable workflow search into model weights.
Loading 2606.12674v1…