Research
Self-Evolving Agentic Workflows via Semantic Decomposition of Complex Tasks
Overview Research area: LLM-based autonomous agents and agentic workflow construction, evaluated in the GLEE competition on interactive bargaining, negotiation and persuasion tasks. Technical level: A
- arXiv
- 2611.01840
- Published
- 2026-11-01
- Authors
- Zichuan Fu, Junjia Qi, Xian Wu, Wenlin Zhang, Yimin Deng, Kaifeng Guo, Xiangyu Zhao
AI summary
Overview
Research area: LLM-based autonomous agents and agentic workflow construction, evaluated in the GLEE competition on interactive bargaining, negotiation and persuasion tasks.
Technical level: Advanced (assumes familiarity with LLM agents, program synthesis / code-editing agents, and game-theoretic interaction environments).
Scope (one sentence): The paper proposes a framework in which an LLM coding agent decomposes an interactive decision task into a hierarchy of subtasks with explicit applicability conditions, attaches mostly-code solution procedures to them, and revises that code between games using execution records — demonstrated across three GLEE environments over 725 development iterations.
What This Paper Is About
Agentic workflows turn complex tasks into reusable step-by-step procedures, but when every step calls an LLM, inference cost and latency grow with the number of steps and can make a workflow unusable for time-sensitive interaction. This paper argues that much of that overhead is avoidable, because many steps already have defined solutions that can be expressed as code. The goal is a workflow whose decomposition explicitly names when each subtask applies and how it is solved (code, a fitted model, or an LLM call), and which an agent keeps improving from execution feedback so that model reasoning is used only where it is actually needed.
Key Contributions
-
A framework for semantic task decomposition of agentic workflows. Complex interactive decisions are organized into a hierarchy of subtasks, where each subtask carries explicit applicability conditions (the observable situation it serves) and a solution procedure that executes code or invokes a model as needed.
-
A feedback-driven revision method. An agent (
𝒜) takes the current workflowW_kplus execution traces and task outcomesD_kand produces a candidate workflow, using four kinds of revision: task decomposition (splitting subtasks or reorganizing branches), parameter adjustment (thresholds, weights), model fitting (training classifiers/regressors from execution data), and procedure redesign (an alternative strategy). -
A retained-or-reverted evaluation protocol. Each candidate is evaluated by replay, held-out records, or bounded deployment; if retained it becomes
W_{k+1}, otherwise the workflow stays atW_k. The workflow itself is fixed during an interaction and only revised between interactions. -
An empirical study of workflow evolution. The authors analyze 725 development iterations and 12,249 action records collected with fixed workflows across Bargaining, Negotiation and Persuasion, examining how strategies emerge, change or are withdrawn, and how much of the final decision-making is done by code versus fitted models versus LLM calls.
Main Findings
-
Competition result: the agent ranks first in the GLEE competition, with official ratings of 2760.27 (Bargaining), 2761.67 (Negotiation) and 2261.58 (Persuasion) at final revision
a1875a0. -
Decisions are fast and mostly local: mean local decision time per action is 0.118 ms, 0.198 ms and 0.122 ms for Bargaining, Negotiation and Persuasion respectively. Code and fitted models decide in under a millisecond, while measured LLM calls take seconds and mostly fail.
-
Small branching factors, many judgments: mean branches per strategy node is 2.13 / 2.25 / 2.24, yet the workflows make a mean of 37.61 / 22.95 / 7.42 strategy judgments per action — the depth of checking, not width of tree, carries the work.
-
Code dominates the designed modules: most designed decision modules are code throughout development; fitted models join as the workflows learn from recorded games, and LLM modules persist only as optional interfaces. Code makes nearly all final decisions.
-
The LLM judge fades out: early on the LLM judge answers about one in eleven non-message actions, almost all Persuasion buyer decisions, and agrees with the code in all but one case. Responses almost vanish after iteration 90 once those decisions are made deterministic.
-
Strategies are withdrawn, not only added: a Bargaining model judge enters at iteration 40 and is disabled at 186; a plateau exit enters at 552 and is withdrawn at 564; a Bargaining responder policy returns to shadow mode at 557. Thirteen commits restore an earlier strategy policy, most after iteration 300.
-
Revision is mostly condition-sharpening: task decomposition changes 738 code units in 458 commits and procedure redesign changes 591 units in 188 commits, while parameter adjustment and model fitting each change fewer than 35 units. Model fitting first appears at iterations 240–243.
-
Work migrates to branches: the first 258 iterations all lie on the main line; from iteration 259 onward most revision work happens on experimental branches, with selected changes later returning to the main line.
-
Tests are part of the loop: test functions on the main line grow from 165 to 595, and of the 527 commits that change strategy code, 493 also change tests.
-
The rating rewards only own payoff, and the workflows harden: the competition rating neither includes the opponent's payoff nor gives credit for enlarging the joint payoff. The final Bargaining workflow opens at a 55% self-share in all 63 eligible states and its reservation lock rejects in 382 states.
-
Code paths reach real states: replay of development states shows two situations receive most states in Bargaining and Negotiation, and in Persuasion the seller observing product quality receives about half; rare situations such as the last round still keep their own leaves.
-
The authors caution against causal readings: the plotted rating changes are recorded observations, not controlled effects of any single code edit, and the paper states that controlled comparisons are needed to quantify gains and costs.
Methodology in Plain English
The design separates two things that are often mixed together: the workflow that plays the game, and the agent that improves the workflow.
The workflow is ordinary executable code. For each move it runs through three levels: first it identifies the current situation using ordered rules, then it reads further features and selects a procedure, then it turns that procedure into a concrete offer or decision. Because the situation is named explicitly rather than hidden inside a prompt, an improvement can target one node while its siblings keep behaving as before. A step that genuinely needs language understanding can call a model, but the surrounding program decides when that call happens, what it receives, and what to do with its answer.
The improving agent runs a five-stage cycle: Construct the initial workflow, Execute and record paths and outcomes, Locate the problem among poorly handled cases, Revise the code by adding a semantic condition or changing a procedure, then Evaluate the candidate and retain or revert it. Revisions are validated against regression tests that freeze each diagnosed problem as an expected decision, so a later change to one branch does not silently break another.
For the study, GPT-5.5 acts as the coding agent revising workflows through the authors' OpenProgram framework, with Grok-4.6 serving the optional runtime LLM modules, and the whole approach is tested in the three GLEE environments under competition rules. The analysis then combines three lenses: official competition ratings, the commit history of the evolving code (function-level edit inventories across 725 revisions), and runtime attribution of recorded actions to code, fitted models or LLM calls.
Why This Matters
Impact on research. Most agentic-workflow work organizes a pipeline around interfaces, roles or prompt modules, leaving implicit which situation each step actually serves. This paper makes the situation itself a first-class, revisable object, which turns "improve the agent" into "split, merge, or re-scope a named condition." It also documents something rarely reported: the withdrawal and repair of strategies, not just their addition. By attributing recorded actions to executors, it quantifies how little LLM use survives once a workflow matures, which reframes the cost question for multi-step agents.
Potential real-world applications:
- Sales and customer-facing chat agents that must decide quickly whether to recommend, wait, or close, as in the Persuasion environment.
- Automated procurement and pricing negotiation, where offer construction has to respect reservation values and continuation estimates in real time.
- Latency-sensitive interactive systems such as live bidding or auction-style settings, where sub-millisecond local decisions matter more than per-call reasoning quality.
- Cost-constrained enterprise deployments of LLM agents, where moving stable subtasks from model calls to code directly reduces per-interaction inference spend.
Industry relevance. The pressure to cut per-step inference cost and delay is the central engineering constraint on production LLM agents. This paper offers a concrete pattern: write the reusable decision logic as code, keep the model as an optional interface at named points, and let an automated revision loop tighten conditions over many deployments. The accompanying evidence that LLM judging can be replaced by deterministic code that agrees with it in all but one case is directly actionable for teams paying for redundant model calls.
Future Directions
- Controlled ablations. The authors explicitly call for controlled comparisons to quantify performance gains and costs across workflow construction, execution and revision; the current rating curves cannot isolate the effect of any single change.
- Aligning objectives with joint outcomes. Because the competition rating ignores the opponent's payoff and gives no credit for a larger total, the evolved workflows become firm in asking and rejecting. Whether decomposition-driven evolution behaves prosocially under a joint-payoff objective is untested.
- Better operation labeling. Revision categories are assigned by syntactic rules, so a changed condition may fix a bug without truly splitting a subtask. Learning the intent of an edit, rather than inferring it from syntax, would sharpen the account of how workflows improve.
- Generalization beyond GLEE. The reported branch-usage shares come from replayed development states and reflect the opponents met during development, leaving open how these decomposed workflows transfer to unseen opponents and to domains outside bargaining, negotiation and persuasion.
Target Audience
Researchers and engineers building multi-step LLM agents who care about inference cost, latency and reliability; practitioners who maintain agent codebases and want a principled way to decide which steps should be code and which should call a model; and competition or benchmark researchers interested in longitudinal analysis of how an agent's strategy evolves rather than only in its final score. It is less suited to readers seeking prompt-engineering recipes, since the paper's unit of design is the workflow program, not the prompt.
Authors’ abstract
Agentic workflows organize complex tasks into reusable procedures. However, invoking an LLM at every step incurs repeated inference costs and delays. We propose a framework for self-evolving agentic workflows through semantic task decomposition. Each subtask has explicit applicability conditions and a procedure that executes code or invokes a model as needed. An agent uses execution feedback to refine the decomposition and update these procedures. Experiments in the GLEE competition show the framework on bargaining, negotiation and persuasion. Most observed final-decision procedures are implemented in code. Code is available at https://github.com/Applied-Machine-Learning-Lab/NeurIPS2026_SeaFlow.