It Takes Workflows to Evolve Better Workflows

It Takes Workflows to Evolve Better Workflows. By Xuehang Guo and five others, from William and Mary, NEC Corporation of America, and one other institution. Published on the first of October. No code repository is linked to it.

Some real-world tasks exceed what a single large language model can do, which is the motivation for multi-agent workflows that coordinate specialised agents. Recent methods train a model to construct better workflows from execution outcomes. They optimise only that workflow generator, though. The other agents, the ones that build or execute each workflow, remain fixed, even though every outcome depends on all of them. Extending training beyond the generator runs into two obstacles. The agents are coupled to one another. And a workflow's outcome is a single sparse score, which cannot tell which agent caused a failure. Train one agent on that score and the others shift the ground under it. Train them all on it and none of them learns what was its own fault.

FloWright takes the title literally. It leverages the workflow itself as a harness for optimising workflows. The structure that coordinates the agents at run time becomes the structure used to train them. On top of that sits a hierarchical, structure-aware reward paradigm. With it, one role can self-evolve on its own, or two or more roles can co-evolve together. None of this calls for additional models, additional labels, or additional executions. The abstract leaves the reward's internals at that description: hierarchical, and aware of the workflow's structure. What it does specify is the reach. The generator is no longer the only thing that learns.

A second limitation concerns the data. Workflows are commonly trained and evaluated on tasks that a single agent can already handle, which leaves the coordination untested. The authors answer that with DataWright, an adaptive data hardening approach. It converts existing datasets into workflow-level tasks with increased difficulty, so that the training and evaluation material asks for more than one agent could supply. Taken together, FloWright changes who gets trained, and DataWright changes what they are trained and judged on.

Evaluation spans document, slide, chart, code, math, and finance tasks. Small open models trained with FloWright improve by up to seven point four one percent. The comparison between roles is the telling part. Co-evolving more roles gains five point zero three percent. Optimising one of them alone gains two point eight three percent. Training more of the agents that an outcome depends on returns more than training one.

A sparse score that cannot name the failing agent looks like a reason to train only the generator. FloWright's answer is that the workflow already carries the structure needed to share credit among its roles, and that using it lets several roles improve together, without adding models, labels, or runs.