Large language model agents can adapt to complex tasks by constructing workflows at inference time, but procedures discovered in one episode are usually discarded after execution. Existing skill libraries provide reusable executable routines, but are typically assembled offline and do not grow from the agent's own workflows. We introduce FlowEvo, a training-free framework in which workflows and skills co-evolve at inference time. FlowEvo compiles successful workflows into callable skills, stores them in a persistent bank, and uses retrieved skills either through direct execution or as context for constructing new workflows. It also tracks each skill's downstream utility and suppresses skills that cause negative transfer. Using a shared GPT-4o-mini backbone, FlowEvo achieves the highest accuracy among 8 baselines on the full standard splits of ALFWorld, HumanEval, MBPP, GSM8K, and MATH-500. On ALFWorld, it reaches 85.6%, 26.4 points above the strongest baseline, while using roughly one third as many tokens. Across 10 base models spanning 7B to 671B parameters, FlowEvo outperforms ExpeL in 49 of 50 model-dataset comparisons. Code is available at https://github.com/DEFENSE-SEU/FlowEvo.
Alex: Welcome to another episode of ResearchPod. Today we're looking at FlowEvo, a framework for self-evolving AI agents.
Sam: So this paper is asking a pretty fundamental question — why do AI agents keep reinventing the wheel? Like, why solve the same problem from scratch every single time?
Alex: Exactly. Here's the core issue. When you give a large language model agent a task, it figures out a plan — a step-by-step workflow — on the fly. It might do this brilliantly. But once the task is done, that plan just disappears. The next time a similar task comes up, the agent starts from zero again.
Sam: And that's genuinely wasteful, right? Not just in terms of time, but in terms of computing cost?
Alex: It is. Think of it like a student who solves a tricky math problem, but never writes down their working. Next week, same problem — they have to figure it out all over again. FlowEvo is essentially saying: write it down. Keep a notebook.
Sam: So instead of solving from scratch each time, the agent builds up a library of proven solutions it can reach back into?
Alex: That's the heart of it. When an agent successfully completes a task, FlowEvo automatically captures that solution — the exact sequence of steps that worked — and stores it as what the paper calls an "executable skill." Think of it like saving a macro in a spreadsheet program. You did the work once, you recorded it, and now anyone can run it with a single click.
Sam: And these skills aren't just filed away and forgotten? The agent can actually use them in future tasks?
Alex: Right. When a new task comes in, the agent first checks its skill library. If there's a close match, it can either run that saved skill directly — like following a recipe step for step — or use it as a starting point and adapt it. The key insight is that the agent is no longer starting from a blank page.
Sam: It's kind of like a master chef who writes down a precise recipe every time a new dish succeeds. The next cook can either follow it exactly, or use it as inspiration for something new.
Alex: That's a very accurate way to put it. And the "writing it down" part is automatic — the system handles it without any human intervention.
Sam: So how does the system decide which solutions are worth saving? You wouldn't want to archive a workflow that only half-worked.
Alex: That's an important design question, and the paper addresses it directly. FlowEvo only promotes a workflow into the skill library after it's been verified — meaning the agent actually completed the task successfully. Failed attempts or partial solutions don't get saved. So the library only accumulates genuinely useful knowledge over time.
Sam: And the workflows themselves — how are they structured? Are they just plain text instructions, or something more formal?
Alex: They're more formal than plain text. The paper describes them as structured, parameterized records — meaning the skill is written in a way that can be adjusted for slightly different situations. So if you saved a skill for "make a cup of tea," the parameters might include things like water temperature or steeping time, which you can dial up or down for a different tea variety. The underlying structure stays the same; only the specifics change.
Sam: That's a meaningful distinction. It's not just copy-pasting a solution — it's saving a flexible template.
Alex: Exactly. And that flexibility is what allows the system to handle tasks that are similar but not identical to ones it's seen before.
Sam: So what does this actually look like in practice? Does the paper test it against anything?
Alex: It does. The paper evaluates FlowEvo on a benchmark called ALFWorld — a simulated household environment where an agent has to complete tasks like finding objects, moving them, or using them in specific ways. It's a standard test for this kind of agent research.
Sam: And how does it perform?
Alex: The results are meaningful. FlowEvo reaches a success rate of around eighty-six percent on that benchmark — which is roughly twenty-six percentage points above the strongest competing system the paper tests against. And it does this while using about one-third of the computing tokens that a comparable approach would use. So it's both more effective and more efficient.
Sam: That efficiency gap is interesting. Why does saving skills actually reduce the computing cost so much?
Alex: Because generating a plan from scratch is expensive. The model has to think through every step, consider alternatives, and reason about the task in full — and all of that reasoning consumes tokens, which is essentially the currency of how much work a language model does. When the agent can retrieve a pre-built skill and run it directly, it skips most of that reasoning. It's the difference between solving a problem and looking up the answer you already worked out.
Sam: So the skill library isn't just a convenience — it's actively changing how much computational work the agent has to do.
Alex: That's the right way to think about it. And importantly, none of this requires retraining the underlying model. The model's weights — the core parameters that define how it thinks — stay completely fixed. FlowEvo improves performance purely through what it stores and retrieves at runtime, not by changing the model itself.
Sam: That seems significant from a practical standpoint. You don't need access to the model's internals, or a huge training run, to get better performance over time.
Alex: The paper makes that point explicitly. It's a form of learning that happens at the system level rather than the model level. The agent gets better at its job not because its underlying intelligence changes, but because it accumulates experience in a usable form.
Sam: So FlowEvo is essentially giving AI agents something closer to institutional memory — the ability to build on past successes rather than treating every task as if it's the first.
Alex: That's a fair summary. And the broader question the paper raises is worth sitting with: as these agents are deployed in real-world settings, the ability to accumulate and reuse knowledge efficiently may matter just as much as the raw capability of the underlying model. FlowEvo is one concrete attempt to address that.
Sam: Something to think about as these systems become more embedded in everyday workflows.
Alex: Thanks for listening to ResearchPod.