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

arXiv:2606.12674 · cs.AI · Submitted 2026-06-10 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: I'm Tom.

Jane: And I'm Jane, here with Lu, Meng and our in-house large language model, Lalam.

Tom: Today's paper: "EvoFlux: Inference-Time Evolution of Executable Tool Workflows for Compact Agents".

Jane: The gist The paper introduces Evoflux, an inference-time evolutionary search method that treats compact tool use as the repair of executable tool workflows,

Tom: First, who's behind it and why it matters.

Title and authors: Tom: So, let's look at who wrote this. The title is "EvoFlux: Inference-Time Evolution of Executable Tool Workflows for Compact Agents," and the authors are Kushal Raj Bhandari, Ling Yue, Ching-Yun Ko, Dhaval Patel, Shaowu Pan, Pin-Yu Chen, and Jianxi Gao.

Jane: It's a team from Rensselaer Polytechnic Institute and IBM Research. And looking at the title again—it really emphasizes that this method happens during inference time.

Tom: Yeah, it’s about evolving workflows while the model is actually running its task. The implication is that we don't need massive amounts of data to get these agents right; we just need a way to repair their plans when they go wrong in real-time.

Lu: What's interesting about the authors’ work, especially in light of what they cite, is how they are comparing this search approach against methods like supervised finetuning and SFT plus DPO.

Meng: Because those other methods rely on training data, which can be scarce for these smaller models we deploy locally or on enterprise servers. This paper suggests that relying only on pre-training data isn't enough to fix the execution failures.

Lalam: And they show that inference-time search actually outperforms those distillation techniques when you have limited teacher traces available for training, which is a big deal for efficiency.

The paper's summary: Tom: So, what's the actual mechanism of EvoFlux? Basically, they introduce this adaptive evolutionary loop that searches for executable tool workflows at inference time. They start with a symbolic workflow proposal and then convert it into an executable one.

Jane: It sounds like it takes these symbolic plans and tries to make them work by running them through a dynamic repair process involving structured edits, execution feedback, and scoring from an LLM judge.

Tom: That's right; they use several mechanisms for evolution, including typed edits for modifying the workflow structure itself, and they have adaptive intensity control based on how well the search is progressing.

Lu: They use a growth statistic G to track progress, and that statistic determines the search intensity I; if progress stalls, it increases exploration, but if improvements accumulate, it decreases intensity.

Meng: That dynamic control sounds smart because it means you don't waste time exploring wildly when you're already close to a solution. It keeps the search focused.

Lalam: And they cap the population at K candidates and use action-hash binning to keep the best options while pruning near-duplicate workflows, which helps manage complexity.

The paper's improvements: Tom: Now let's talk about what they claim are the main improvements over existing approaches. They show that execution-grounded search is more reliable under scarce teacher-trace budgets than supervised finetuning or SFT plus DPO on the same data.

Jane: This means you can get better performance even if you only have a small amount of teacher traces to start with, which is a huge relief for many of us working with smaller models.

Lu: They also show that EvoFlux improves weak initial graphs through execution-guided repair, whereas methods like SFT and SFT plus DPO often just preserve shallow tool-call templates instead of the actual reliable workflow structure.

Meng: That makes sense because it’s about learning the actual sequence of actions needed to get a result, not just mimicking a successful output format from a dataset.

Lalam: And they show that for Llama-three point two-3B and Qwen3, the performance of their best candidate recovers roughly the same score range as the overall best performance when compared to SFT methods, which is pretty strong evidence.

Conclusion: Tom: So to wrap up, EvoFlux introduces an adaptive search procedure that treats compact tool use as a repair of executable workflows during inference time. It uses structured edits and dynamic intensity control to evolve these plans based on execution feedback.

Jane: The big implication is that we can lift the feasibility of executing these agents from maybe around three percent up to about seventeen to twenty-four percent across those small planners, which is a significant jump in practical use.

Lu: It suggests that for compact models, inference-time repair over the actual task and environment is more valuable than spending compute on weight updates during training.

Meng: From a deployment standpoint, this means we don't have to rely on massive datasets to get these agents working reliably; we can use execution-grounded search as a robust fallback when things go wrong.

Lalam: And they did point out that the method’s limitations are that it still needs a planner to generate the initial symbolic workflow, and it can't reason over schemas or multi-hop evidence with the same flexibility as model-based planners.

Tom: That sounds like a fair limitation; it’s not a complete solution for every single complex reasoning task, but it does provide that deterministic execution floor when credentials are missing or model calls fail.

Jane: So, EvoFlux is this inference-time evolutionary search method that treats compact tool use as the repair of executable tool workflows. A lot to think about before we look at what comes next in this field.

Rensselaer Polytechnic Institute · IBM Research

cs.AI

Submitted: 2026-06-10

Updated: 2026-10-14

Comments: Code is available at https://github.com/IBM/Evoflux

Code: https://github.com/IBM/Evoflux

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 90/100

The gist: The gist The paper introduces Evoflux, an inference-time evolutionary search method that treats compact tool use as the repair of executable tool workflows, showing that execution-grounded search is

Key concepts

MCP (Model Context Protocol)
This protocol standardizes how language models discover and call external tools provided by various servers. It gives compact models a structured way to interact with real-world tools, defining the interface for tool discovery and invocation.
BUILDCANDIDATE
This procedure converts a symbolic plan proposed by the model into an actual executable workflow. It performs crucial checks like resolving tool identifiers against the catalog, validating parameters against tool schemas, and ensuring the graph has no dependency errors before execution.
Typed Edit Language
This language allows EvoFlux to modify plans using specific operations such as replacing a tool entirely, correcting a parameter value, inserting a new step, or removing an unnecessary action. These typed edits are used by the system to guide targeted repairs during the evolutionary search.

Terminology

Summary

The gist The paper introduces Evoflux, an inference-time evolutionary search method that treats compact tool use as the repair of executable tool workflows, showing that execution-grounded search is more reliable under scarce teacher-trace budgets than supervised finetuning or SFT+DPO on the same data.

Problem Setup

Small language models often generate plausible workflow graphs that fail under tool resolution, parameter validation, dependency tracking, or execution The Model Context Protocol (MCP) offers a concrete interface for this class of agents by standardizing how models discover and call tools exposed by external servers Compact language models in the 1.5B to 4B range are attractive for such agents because they reduce serving cost, latency, and privacy exposure while supporting local or enterprise-controlled deployment They emit malformed JSON, select unavailable tools, omit required arguments, break dependency links, and answer from prior knowledge rather than executed evidence

Method Overview

Evoflux is an adaptive evolutionary loop that searches for executable tool workflows at inference time Given task q = (x, T, E), a planner P proposes a symbolic workflow The candidate c stores everything needed to evaluate one workflow variant The procedure BUILDCANDIDATE converts a symbolic graph into an executable workflow Scoring function f(c) maps each candidate to a scalar execution score derived from the MCP-Bench LLMJUDGE evaluator

Key Components of Evoflux

Evoflux evolves plans through several mechanisms The process involves structured edits, execution feedback, adaptive intensity control, meta-guided redesign, and action-hash diversity pruning

** Typed edit language modifies workflows through operations like Tool swaps, Parameter edits, Tool insertion, Tool removal, and Step reordering Mutation uses this evidence to choose edit locations and edit types The controller tracks recent positive progress through a growth statistic G; the intensity I increases when progress stalls and decreases when improvements accumulate Meta guidance supplies a higher-level redesign step when local mutation stops improving the population The population is capped at K candidates, and survivors are chosen using action-hash binning to preserve high-scoring candidates while reducing collapse onto near-duplicate workflows The heuristic fallback method provides a low cost safety path when the planner cannot call or successfully use the language model This fallback uses token overlap between the query and the registered tools to select at most min(self.max steps, 3) tools in a strictly sequential graph The method returns a GraphTemplate marked with heuristic=True This fallback acts as a deterministic execution floor It can keep the system moving when credentials are missing or model calls fail, but it cannot reason over schemas, task semantics, or multi-hop evidence with the same flexibility as the model-based planner The full procedure is detailed in Algorithm 2 This algorithm maintains a bounded population P, the best observed score f∗, and an adaptive growth statistic G At each step, the current growth level determines the search intensity Low growth increases exploratory mutation and may trigger meta guidance High growth concentrates search around stronger candidates through tournament-style parent selection and evidence-conditioned repair The procedure BUILDCANDIDATE converts a symbolic graph into an executable workflow It parses the graph, resolves server and tool identifiers against the catalog T, validates parameters against tool schemas, checks graph acyclicity and dependency references, and executes the workflow when static checks succeed The scoring function f(c) maps each candidate to a scalar execution score derived from the MCP-Bench LLMJUDGE evaluator Infeasible candidates receive a score of 0 For feasible candidates, the evaluator is run with stability testing enabled, invoking it five times per candidate with a freshly randomized prompt structure on each pass The scalar score drives parent selection, growth updates, population pruning, and final candidate selection The search split shows how often each planner reaches executable workflows, how much the evolutionary loop improves over the initial proposal, where the judge’s sub-dimensions change after search, and how score trades off against token cost 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 This results show that executiongrounded search is more reliable under scarce teacher-trace budgets The validation split shows that Valid Best recovers roughly the same score range as Best for Llama-3.2-3B and roughly two-thirds of the Best score for Qwen3.

Improvements for AI systems

  1. Bold header: Inference-time workflow repair for compact agents

This system can treat compact tool use as the repair of executable tool workflows by evolving typed workflow graphs through structured edits, execution feedback, adaptive intensity control, meta-guided redesign, and diversity pruning. This allows the model to recover relevant tools from a changing catalog and satisfy schemas during live inference.

  1. Bold header: Quantitative comparison of training versus search

The system can determine if it is better to spend compute on weight updates, or on inference-time repair over the actual task, catalog, and execution environment. This addresses the risk that small-corpus finetuning may carry downside risk for compact models by showing that inference-time search lifts held-out feasibility and score across small planners.

  1. Bold header: Robustness against scarce teacher trace budgets

The system is designed to perform reliably with limited supervision, as evidenced by results showing that SFT and SFT+DPO on the same search-mined data match, underperform, or collapse below zero-shot performance. This suggests that executiongrounded search is more reliable under scarce teacher-trace budgets than relying solely on supervised finetuning.

  1. Bold header: Improved structural generalization of tool graphs

The system can generate more robust workflows by focusing on structure over surface imitation, as shown by the finding that 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.

  1. Bold header: Adaptive search intensity based on progress

The system dynamically adjusts its search strategy using an adaptive intensity controller where the growth level determines the search intensity to manage exploration versus exploitation, ensuring that Low growth increases exploratory mutation and may trigger meta guidance.

Abstract

Small language models (1.5B-4B parameters) offer low-cost, low-latency tool use but often produce plausible plans that fail during execution due to unavailable tools, missing arguments, or broken dependencies. We introduce EvoFlux, an inference-time search method that repairs tool plans through an evolutionary loop over structured graphs of tool calls and dependencies. EvoFlux executes candidate plans against live tool servers and uses execution errors to guide targeted edits, including replacing tools, correcting parameters, inserting missing steps, and removing redundant ones. On held-out MCP-Bench tasks spanning 28 live servers and 250 tools, EvoFlux improves execution success from roughly 3% to 17-24% across four small planners. SFT and SFT+DPO trained on the same 177 demonstrations and 624 preference pairs match or underperform the zero-shot baseline, while ReAct reaches higher peaks on stronger planners at 4-20x greater planner-token cost per solved task. Execution-guided inference-time repair reliably improves small tool-using agents when supervision is limited.

Sources

Related papers