From Atomic Actions to Standard Operating Procedures: Iterative Tool Optimization for Self-Evolving LLM Agents

# From Atomic Actions to Standard Operating Procedures: Iterative Tool Optimization for Self-Evolving LLM Agents
Source: [https://arxiv.org/html/2607.07321](https://arxiv.org/html/2607.07321)
Haipeng Ding1,2,Yuexiang Xie2,Zhewei Wei1,,Yaliang Li2,∗\\ast,Bolin Ding2 1Renmin University of China,2Alibaba Group Correspondence to: Zhewei Wei⟨\\langle[zhewei@ruc\.edu\.cn](https://arxiv.org/html/2607.07321v1/mailto:[email protected])⟩\\rangleand Yaliang Li⟨\\langle[yaliang\.li@alibaba\-inc\.com](https://arxiv.org/html/2607.07321v1/mailto:[email protected])⟩\\rangle

###### Abstract

Tool utilization enables Large Language Model \(LLM\) agents to interact with the real world and resolve complex tasks\. However, existing agent frameworks predominantly rely on static toolsets composed of granular atomic actions \(e\.g\., basic file I/O or single\-turn search\), which forces agents to reinvent low\-level logic for every recurring workflow, leading to increased reasoning overhead and failure rates\. In this study, we propose that agents can achieve self\-evolution by synthesizing these atomic actions into reusable Standard Operating Procedures \(SOPs\), which function as callable higher\-order tools that encapsulate multi\-step logic\. We further introduceEvoSOP, a framework that empowers agents to extract SOPs from execution trajectories and iteratively optimize the toolset through a systematic lifecycle of construction, merging, evaluation, and pruning\. Extensive experiments demonstrate thatEvoSOPsignificantly boosts task success rates while substantially reducing the number of interaction rounds compared to baselines\. Our analysis also reveals that iterative tool optimization fosters reliable and efficient tool\-use patterns, providing a scalable pathway for the development of self\-evolving agents\.

From Atomic Actions to Standard Operating Procedures: Iterative Tool Optimization for Self\-Evolving LLM Agents

Haipeng Ding1,2, Yuexiang Xie2, Zhewei Wei1,††thanks:Correspondence to: Zhewei Wei⟨\\langle[zhewei@ruc\.edu\.cn](https://arxiv.org/html/2607.07321v1/mailto:[email protected])⟩\\rangleand Yaliang Li⟨\\langle[yaliang\.li@alibaba\-inc\.com](https://arxiv.org/html/2607.07321v1/mailto:[email protected])⟩\\rangle, Yaliang Li2,∗\\ast, Bolin Ding21Renmin University of China,2Alibaba Group

## 1Introduction

Large Language Models \(LLMs\)Raffelet al\.\([2020](https://arxiv.org/html/2607.07321#bib.bib1)\); Touvronet al\.\([2023](https://arxiv.org/html/2607.07321#bib.bib2)\); Brownet al\.\([2020](https://arxiv.org/html/2607.07321#bib.bib3)\)have fundamentally advanced the field of artificial intelligence, demonstrating remarkable capabilities in logical reasoning and general\-purpose problem\-solvingChenet al\.\([2021](https://arxiv.org/html/2607.07321#bib.bib4)\)\. By leveraging external tools, LLM\-based agentsYaoet al\.\([2023](https://arxiv.org/html/2607.07321#bib.bib6)\); Qinet al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib7)\); Wanget al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib8)\)extend these strengths beyond text generation to interact with the real world and solve complex and practical tasksMialonet al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib5)\)\.

While effective tool utilization is critical to the performance of agent systems, existing frameworks predominantly rely on static toolsets of atomic actions, such as basic file I/O, single\-turn search, etc\. This design forces agents to orchestrate every task through fine\-grained sequences of low\-level logic, diverging from the hierarchical efficiency seen in human problem\-solvingFabianoet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib11)\)\. In practice, humans often bypass exhaustive deliberation by employing Standard Operating Procedures \(SOPs\) that encapsulate multi\-step logic into cohesive and high\-level routines\. Without these abstractions, agents face significantly increased reasoning overhead and a higher risk of cascading errors, particularly in long\-term tasksPanet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib12)\)\.

Recent research on tool\-augmented agents followed mainly two paths, refining a model’s ability to use specific toolsQinet al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib7)\)and expanding the overall breadth of the available toolsetLyuet al\.\([2023](https://arxiv.org/html/2607.07321#bib.bib24)\)\. However, these efforts do not address the fundamental inefficiency of reasoning in long and fragmented sequences of atomic actions\. While recent studiesYuanet al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib10)\); Liuet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib22)\)enable agents to create new tools dynamically, they typically treat tool addition as a one\-time event and lack a mechanism for long\-term management\. This leads to a bloated toolset where redundant or suboptimal tools accumulate, creating noise and complicating the agent’s decision\-making\. This implies that a truly self\-evolving agent requires more than just the ability to generate tools\. It needs a systematic and iterative process to optimize its toolset by pruning ineffective tools, ensuring that evolved SOPs remain efficient and reliable\.

To address the aforementioned challenges, we introduceEvoSOP, a framework that empowers agents to self\-evolve by synthesizing atomic actions into high\-level and reusable SOPs\. Distinct from existing methods that treat tool creation as an isolated event,EvoSOPestablishes a continuous optimization loop that progressively refines the agent’s toolset\. Specifically, the framework iteratively identifies recurring and useful patterns of atomic actions within execution trajectories, and compresses these long\-horizon reasoning chains into callable higher\-order tools\. Within this same iterative cycle,EvoSOPgoverns the composition of the toolset by merging redundant routines and pruning low\-utility actions based on their historical performance\. This systematic approach ensures that agent capabilities remain both lean and powerful, effectively preventing performance degradation often caused by bloated toolsets\. Note thatEvoSOPserves as a model\-agnostic framework that requires no parametric updates to the underlying LLMs, ensuring seamless integration with existing agent systems and enhancing the performance of black\-box models\.

Our main contributions are summarized as:

- •We define a novel paradigm for agent self\-evolving that formalizes how agent systems improve through iterative tool optimization\. This paradigm establishes a conceptual parallel to the standard machine learning pipeline by mirroring essential stages such as data acquisition, forward execution, backward propagation, etc\.
- •We proposeEvoSOP, a framework that empowers agents to extract SOPs from their execution trajectories\. The system iteratively optimizes the toolset through a systematic lifecycle that encompasses construction, merging, evaluation, and pruning\.
- •We provide extensive experiments on various benchmarks to demonstrate the effectiveness of the proposed framework\. The experimental results show thatEvoSOPsignificantly increases task success rates while reducing the number of interaction rounds compared to baselines\.

## 2Preliminaries

We first introduce the definitions and notations of LLM\-based agents\. We focus on a practical agentic settingGaoet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib26)\); Li \([2025](https://arxiv.org/html/2607.07321#bib.bib27)\)where the agent interacts with an environment through a toolset to accomplish complex tasks\. Due to the space limitation, we place another agent system named DFSDTQinet al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib7)\)in Appendix[B](https://arxiv.org/html/2607.07321#A2)\.

#### Environment and Interaction\.

We consider an agent interacting with an environmentℰ\\mathcal\{E\}\. At each time steptt, the agent receives an observationot∈𝒪o\_\{t\}\\in\\mathcal\{O\}from the environment and takes an actionat∈𝒜a\_\{t\}\\in\\mathcal\{A\}based on its internal policy\. The policyπ\\piis instantiated by an LLM, expressed as:

at∼πLLM\(⋅∣Ct\),a\_\{t\}\\sim\\pi\_\{\\text\{LLM\}\}\(\\cdot\\mid C\_\{t\}\),whereCtC\_\{t\}represents thecontextavailable at timett\. Following the paradigm of ReActYaoet al\.\([2023](https://arxiv.org/html/2607.07321#bib.bib6)\), the actionata\_\{t\}may consist of a reasoning traceltl\_\{t\}and a specific tool callftf\_\{t\}\. For simplification, we denote the reasoning of the LLM given promptPPasa=πLLM​\(P\)a=\\pi\_\{\\text\{LLM\}\}\(P\)\. The environment then returns a responsertr\_\{t\}\(e\.g\., execution results or error messages\), which leads to the next state and observationot\+1o\_\{t\+1\}\.

#### Context\.

The contextCtC\_\{t\}is a structured representation of the agent’s current state, designed to provide the LLM with all necessary information for decision\-making\. We formalizeCtC\_\{t\}as a tuple:

Ct=⟨𝒫,𝒢,ℋt,ℳt,ℱ⟩,C\_\{t\}=\\langle\\mathcal\{P\},\\mathcal\{G\},\\mathcal\{H\}\_\{t\},\\mathcal\{M\}\_\{t\},\\mathcal\{F\}\\rangle,where𝒫\\mathcal\{P\}is the persona or system prompt defining the agent’s role and behavioral constraints,𝒢\\mathcal\{G\}is the task goal and its associated success criteria,ℋt=\{\(a1,r1,o1\),…,\(at−1,rt−1,ot−1\)\}\\mathcal\{H\}\_\{t\}=\\\{\(a\_\{1\},r\_\{1\},o\_\{1\}\),\\dots,\(a\_\{t\-1\},r\_\{t\-1\},o\_\{t\-1\}\)\\\}is the interaction history,ℳt\\mathcal\{M\}\_\{t\}represents the external memory or long\-term knowledge retrieved by the agent, andℱ\\mathcal\{F\}is the toolset containing the functional interfaces available to the agent\.

#### Atomic Actions and Tool Schema\.

The toolsetℱ=\{f1,f2,…,fn\}\\mathcal\{F\}=\\\{f\_\{1\},f\_\{2\},\\dots,f\_\{n\}\\\}initially consists ofatomic actions, i\.e\., granular and single\-purpose functions such as file operations or API calls\. Each toolfi∈ℱf\_\{i\}\\in\\mathcal\{F\}is defined by itsschema=⟨name,desc,params,returns⟩\\textit\{schema\}=\\langle\\text\{name\},\\text\{desc\},\\text\{params\},\\text\{returns\}\\rangle, wherenameanddescprovide the semantic information required by the LLM to understand the tool’s utility\.

#### Workflow\.

The operational cycle of the agent follows a reasoning\-acting loop\. The agent is initialized with stateℋ0=\{\}\\mathcal\{H\}\_\{0\}=\\\{\\\}\. At each time steptt, the agent performs the following operations:

Context Construction:Pt=Format​\(Ct\),\\displaystyle:P\_\{t\}=\\text\{Format\}\(C\_\{t\}\),Reasoning:a^t=πLLM​\(Pt\),\\displaystyle:\\hat\{a\}\_\{t\}=\\pi\_\{\\text\{LLM\}\}\(P\_\{t\}\),Acting:rt=Exec​\(a^t,ℰ\),\\displaystyle:r\_\{t\}=\\text\{Exec\}\(\\hat\{a\}\_\{t\},\\mathcal\{E\}\),State Update:ℋt\+1←ℋt∪\{\(a^t,rt,ot\)\}\.\\displaystyle:\\mathcal\{H\}\_\{t\+1\}\\leftarrow\\mathcal\{H\}\_\{t\}\\cup\\\{\(\\hat\{a\}\_\{t\},r\_\{t\},o\_\{t\}\)\\\}\.The process ends when the agent reaches a terminal state or exceeds the maximum iterations\. We define anexecution trajectoryξq=\(\(a^1,r1,o1\),\(a^2,r2,o2\),⋯,\(a^k,rk,ok\)\)\\xi\_\{q\}=\(\(\\hat\{a\}\_\{1\},r\_\{1\},o\_\{1\}\),\(\\hat\{a\}\_\{2\},r\_\{2\},o\_\{2\}\),\\cdots,\(\\hat\{a\}\_\{k\},r\_\{k\},o\_\{k\}\)\)of taskqqwhen the agent is terminated afterkkiterations\.

## 3Methodology

![Refer to caption](https://arxiv.org/html/2607.07321v1/x1.png)Figure 1:The overall architecture ofEvoSOP, illustrating the iterative tool optimization lifecycle\. The framework employs four collaborative modules, includingConstructor,Merger,Evaluator, andReviewer\.### 3\.1Design Motivation and Principle

As mentioned in Section[1](https://arxiv.org/html/2607.07321#S1), most LLM\-based agents rely on a static toolsetℱ\\mathcal\{F\}composed of granular atomic actions\. While recent studies have explored expanding the toolset through dynamic code generationWanget al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib9)\); Yuanet al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib10)\), they typically treat tool addition as a one\-time event and lack a long\-term management mechanism, leading to several critical limitations:

\(i\)Unreliable Tool Executability: Although LLMs can generate syntactically correct code, synthesized tools often fail in complex environments due to various engineering reasons\. Without a systematic evaluation and refinement, tools remain fragile and cannot be trusted for long\-term tasks\.

\(ii\)Limited Generalization and Reusability: Tools derived from narrow scenarios often encode context\-dependent logic that lacks broader applicability\. Without a mechanism to iteratively abstract actions into reusable SOPs, the agent reinvents low\-level logic, failing to achieve the hierarchical reasoning efficiency seen in human problem\-solving\.

\(iii\)Redundancy: In the absence of a lifecycle management \(e\.g\., merging and pruning\), continuous tool creation leads to a bloated toolset and brings noise to the agent’s context\. Increasing reasoning overhead complicates the LLM’s decision\-making, ultimately degrading the success rate\.

To address these challenges,EvoSOPmoves beyond simple tool creation by establishing a continuous and iterative tool optimization process\.

### 3\.2Overview

As illustrated in Figure[1](https://arxiv.org/html/2607.07321#S3.F1),EvoSOPconsists of four collaborative modules that govern the optimization of the toolset, including: \(i\)Constructor: This module identifies recurring action sequences within execution trajectoriesξ\\xi, which extracts logical segments of atomic actions that frequently co\-occur and synthesizes them into callable SOPs, complete with executable code and semantic schemas; \(ii\)Merger: To maintain a lean toolset, this module inspects newly generated SOPs for functional redundancy, merging overlapping routines into generalized and higher\-order tools to prevent the bloating of the contextCC; \(iii\)Evaluator: The agent is equipped with the updated toolsetℱ′\\mathcal\{F\}^\{\\prime\}and re\-executes tasks\. This module produces new trajectories that reflect the actual utility and reliability of the evolved SOPs in environments; \(iv\)Reviewer: This module acts as a critic by analyzing the performance metrics of synthesized tools, which prunes SOPs that exhibit high error rates or significant redundancy compared to existing tools\.

#### Agent Self\-Evolution by Non\-Parametric Learning\.

AlthoughEvoSOPdoes not modify the learnable parameters of the underlying LLM, its iterative structure constitutes a form of non\-parametric structural optimization\. We formalize this by drawing a conceptual parallel betweenEvoSOPand the machine learning pipeline\.

First, the agent’s interaction with training tasks represents thedata acquisitionstage, while the execution of tasks using the current toolsetℱ\\mathcal\{F\}corresponds toforward propagation\. The resulting execution trajectoriesξ\\xiserve as observable behavioral outputs, capturing the agent’s reasoning process and tool\-use patterns\. Improvement is then achieved through abackward propagation, whereEvoSOPanalyzes reasoning inefficiencies or execution failures within the trajectories\. Instead of updating model weights via gradients, the framework performs “symbolic” backpropagation by extracting and synthesizing reusable SOPs that encapsulate multi\-step logic into cohesive routines\.

Besides, to ensure the SOPs remain lean and to avoid the performance degradation typically caused by bloated toolsets, the merging and pruning processes function as criticalregularizationmechanisms\. These mechanisms mitigate the risk of “overfitting” to narrow and task\-specific contexts by eliminating redundant or low\-utility actions, thereby fostering generalized and reliable tool\-use patterns\. As the iteration proceeds, the stabilization of the toolset mirrors the behavior of adecaying learning rate, where the agent eventually converges toward an optimized hierarchy of toolset\.

### 3\.3Tool Optimization Lifecycle inEvoSOP

In this subsection, we detail the tool optimization lifecycle inEvoSOP, which is designed to systematically transform raw interaction experiences into a solidified toolsetℱ\\mathcal\{F\}of high\-level SOPs\. Please refer to Appendix[D](https://arxiv.org/html/2607.07321#A4)for the selected prompts adopted inEvoSOPindicating our design conception\.

#### Constructor: From Trajectories to Functional Abstractions\.

The optimization lifecycle begins with theConstructor, an LLM\-based module designed to distill reusable functional abstractions from historical execution trajectoriesξ\\xi\. As established in Section[2](https://arxiv.org/html/2607.07321#S2), raw trajectories record sequences of atomic actions and environment responses in strict temporal order\. In practice, many of these consecutive tool calls are not merely coincidental but reflect deep\-seated logical or causal dependencies required to resolve recurring sub\-problems\. TheConstructoridentifies these patterns to transform fragmented action sequences into cohesive and higher\-order routines\.

The primary objective of this stage is to mitigate the excessive reasoning overhead inherent in static and granular toolsets\.Constructorextracts empirically valuable segments of tool\-use patterns and functionalizes them into callable code\. These synthesized SOPs are more than simple linear macros; they are interleaved with lightweight processing logic \(e\.g\., conditional checks or error handling\) to ensure they remain applicable across varying environmental states \(an implementation example is provided in Appendix[E](https://arxiv.org/html/2607.07321#A5)\)\.

We formalize the SOP construction process as a two\-stage transformation:

ξi′=fextract​\(ξi\),𝒮i=frewrite​\(ξi′,ℱatomic\),\\mathcal\{\\xi\}^\{\\prime\}\_\{i\}=f\_\{\\text\{extract\}\}\(\\mathcal\{\\xi\}\_\{i\}\),\\quad\\mathcal\{S\}\_\{i\}=f\_\{\\text\{rewrite\}\}\(\\mathcal\{\\xi\}^\{\\prime\}\_\{i\},\\mathcal\{F\}\_\{\\text\{atomic\}\}\),whereξi\\mathcal\{\\xi\}\_\{i\}represents the raw execution trajectory for taskii, andξi′\\mathcal\{\\xi\}^\{\\prime\}\_\{i\}denotes the set of action segments identified as logically coupled\. The transformation functionfrewritef\_\{\\text\{rewrite\}\}then maps these segments into the resulting SOP source code𝒮i\\mathcal\{S\}\_\{i\}, drawing upon the functional interfaces of the initial atomic toolset\.

#### Merger: Structural Optimization\.

As the agent accumulates experience across task domains, functional overlap and redundancy among synthesized SOPs become inevitable, often manifesting as noise within the contextCtC\_\{t\}\. Such noise complicates the LLM’s decision\-making and may lead to the selection of suboptimal or conflicting tools\. To address this, we design theMerger, a module dedicated to simplifying the toolset and enhancing its overall quality through structural optimization\.

TheMergeranalyzes the candidate SOP set within a training batch to identify functional overlaps based on shared objectives or highly similar logic\. When candidates with convergent functionalities are identified, the module integrates them into a single, more expressive SOP that preserves the constituent capabilities of its predecessors while maintaining a high degree of generality\. We formalize this batch\-based merging process as follows:

𝒮b=⋃i∈b𝒮i,𝒮′=fmerge​\(𝒮b\),\\mathcal\{S\}\_\{b\}=\\bigcup\_\{i\\in b\}\\mathcal\{S\}\_\{i\},\\quad\\mathcal\{S\}^\{\\prime\}=f\_\{\\text\{merge\}\}\(\\mathcal\{S\}\_\{b\}\),wherebbdenotes the set of task indices,𝒮b\\mathcal\{S\}\_\{b\}is the union of newly constructed SOPs, and𝒮′\\mathcal\{S\}^\{\\prime\}represents the consolidated set generated by the merger\.

EvoSOPadopts a non\-destructive consolidation strategy during this stage\. While newly merged, composite SOPs are added to the toolset, the original constituent SOPs are not immediately removed\. This design choice is motivated by two critical observations regarding agent self\-evolution\. Firstly, even when two SOPs possess nominally identical functionality, they may differ significantly in implementation quality, including robustness, coding style, and the clarity of their docstrings, all of which affect the LLM’s ability to invoke them correctly\. Secondly, a larger composite SOP is not inherently superior to its more granular components; it may introduce implicit technical defects or reduce execution reliability in specific contexts\. By deferring the removal of tools until the verification phase,EvoSOPensures that the final toolset is refined based on empirical performance rather than static heuristics, adhering to the principle of hierarchical efficiency without sacrificing reliability\.

#### Evaluator: Execution\-based Validation\.

As synthesized SOPs are inherently prone to fragility when deployed in complex and stateful environments, they cannot be immediately integrated into the agent’s core capabilities without rigorous validation\.EvoSOPsubjects all candidate SOPs to anEvaluator, which serves as the experimental foundation for assessing their real\-world utility\.

Specifically, all constructed SOPs within the sets𝒮b\\mathcal\{S\}\_\{b\}and𝒮′\\mathcal\{S\}^\{\\prime\}are loaded into the execution environment\. Since these SOPs are instantiated as callable functions, the framework must first bridge the gap between executable code and the LLM’s reasoning interface\. We accomplish this by extracting the functional schema for each SOP \(i\.e\., comprising its name, semantic description, and parameter specifications\) and updating the toolsetℱ\\mathcal\{F\}as:

ℱ′=ℱatomic∪\{fschema​\(s\)∣s∈𝒮b∪𝒮′\}\.\\mathcal\{F\}^\{\\prime\}=\\mathcal\{F\_\{\\text\{atomic\}\}\}\\cup\\left\\\{f\_\{\\text\{schema\}\}\(s\)\\mid s\\in\\mathcal\{S\}\_\{b\}\\cup\\mathcal\{S\}^\{\\prime\}\\right\\\}\.This expanded toolsetℱ′\\mathcal\{F\}^\{\\prime\}provides the agent with a hierarchical choice\. It can either continue using granular atomic actions or invoke the newly synthesized SOPs to bypass multi\-step reasoning\.

Following the toolset update,EvoSOPinitiates a full re\-execution of the training tasks within a real\-world setting\. During this process, the framework meticulously monitors task outcomes and captures the resulting execution trajectoriesξ^\\hat\{\\xi\}\. These trajectories provide the empirical data necessary to diagnose implementation defects, assess functionality under diverse conditions, and provide a principled basis for the final quality control process\.

#### Reviewer: Quality Control and Simplification\.

The final stage of theEvoSOPlifecycle is a rigorous quality control procedure designed to ensure the reliability and effectiveness of the toolset\. As SOPs are synthesized independently across varied trajectories, several systematic issues typically arise: \(i\) functional redundancy among overlapping tools; \(ii\) semantic misalignment, where misleading tool names or docstrings trigger retrieval errors; \(iii\) limited utility of tools that are rarely invoked; and \(iv\) latent technical defects that manifest only in specific stateful contexts\. Addressing these challenges is essential to prevent the accumulation of technical debt and the resulting performance degradation caused by bloated toolsets\.

Within the reasoning\-acting loop, an agent’s understanding of an SOP is governed by its docstring\. Since these SOPs are automatically generated from historical logs, any discrepancy between the tool’s implementation and its semantic description can lead to inappropriate invocations or reasoning failures\. To operationalize the assessment of such risks, we introduceReviewer, an LLM\-based module that functions as a critic\. TheRevieweranalyzes the verification trajectoriesξ^\\hat\{\\xi\}and categorizes each SOP invocation into the following states:

- •Optimal Execution: The SOP successfully completes its intended functionality as defined in its docstring without any technical exceptions\.
- •Partial Utility: The tool executes without technical error but achieves its intended goals partially with complicated reasons\.
- •Neutrality: The SOP returns successfully but produces no significant change in the environmental state, indicating low practical relevance\.
- •Negative Interference: The tool negatively impacts task progress or compromises the environmental state, leading to unacceptable outcomes\.
- •Implementation Defect: Execution triggers a technical exception and produces a traceback, indicating internal implementation errors\.

These statuses are not mutually exclusive, reflecting the nuanced failure modes of complex agentic systems\. For each judgment, theReviewerprovides a brief natural\-language justification, ensuring that the pruning process is both interpretable and traceable\. Following the aggregation of these performance statistics across the training batch,EvoSOPperforms a global filtering operation to refine the toolset:

ℛ\\displaystyle\\mathcal\{R\}=⨁i∈Itrainfreview​\(ξ^i\),\\displaystyle=\\bigoplus\_\{i\\in I\_\{\\text\{train\}\}\}f\_\{\\text\{review\}\}\(\\hat\{\\xi\}\_\{i\}\),𝒮solid\\displaystyle\\mathcal\{\\mathcal\{S\}\}\_\{\\text\{solid\}\}=\{s∣fcheck​\(s,ℛs\)≠remove,s∈𝒮′∪𝒮b\},\\displaystyle=\\\{s\\mid f\_\{\\text\{check\}\}\(s,\\mathcal\{R\}\_\{s\}\)\\neq\\text\{remove\},s\\in\\mathcal\{S\}^\{\\prime\}\\cup\\mathcal\{S\}\_\{b\}\\\},where⊕\\oplusis the review aggregation operator\.

### 3\.4Training Workflow

As formally specified in Section[3\.3](https://arxiv.org/html/2607.07321#S3.SS3), each component ofEvoSOPis designed to support a parameter\-free training paradigm\. Unlike prior studies that predominantly rely on parametric fine\-tuning,EvoSOPrealizes the “training” process through iterative optimization of the toolset\. The complete training workflow is presented in Algorithm[1](https://arxiv.org/html/2607.07321#alg1)in Appendix[A](https://arxiv.org/html/2607.07321#A1)\.

#### Mini\-batching\.

At the beginning of the training process, we partition the initial execution trajectoriesξ\\mathcal\{\\xi\}into discrete mini\-batches\. In those batches, theConstructoridentifies tool\-use patterns and proposes new functional abstractions\. Notably, this is the exclusive stage for introducing new SOPs, ensuring the growth of toolset is strictly grounded in observed execution experience\.

In every iteration, theMergerfirst consolidates overlapping functionalities into generalized procedures to maintain a compact toolset\. Subsequently, the system enters an evaluation phase where the agent re\-executes all training tasks with the updated SOPs\. Using the resulting rollouts, theReviewerassesses each tool’s empirical contribution and prunes those that exhibit implementation defects or redundant reasoning\.

#### Checkpointing\.

A critical challenge in LLM\-based optimization is the potential stochasticity of model behavior, where aggressive pruning might inadvertently remove genuinely beneficial SOPs\. To mitigate this risk,EvoSOPavoids a strictly linear update; instead, it adopts a checkpointing mechanism\. At the end of each iteration, the full evaluation logs and the current SOP toolset are archived\. Since task feedback is obtained directly from the environment in a self\-supervised manner, we do not require a separate validation set\. We select the iteration that yields the highest training success rate as the final epoch, ensuring that the output toolset𝒮∗\\mathcal\{S\}^\{\*\}represents the optimal balance between expressivity and reliability\.

## 4Experiments

### 4\.1Setup

Our evaluation compares several distinct tool configurations: \(i\)ReActandDFSDT, which use the original atomic actions; \(ii\)ASIWanget al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib9)\), whose toolset is augmented with SOPs, referred to asskillsin the original paper, induced through a one\-time process; \(iii\)DRAFTQuet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib14)\), which equips tools with rewritten descriptions and usage guidance; and \(iv\)EvoSOP, our proposed method that performs iterative SOP optimization\. The evaluation is conducted on ACEBenchChenet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib20)\)and Tau2BenchBarreset al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib21)\)\. For ACEBench, we use the agent subset, while for Tau2Bench, we use the solo mode of the Telecom subset\.

Throughout the experiments,GPT\-4oserves as the backbone LLM for all evaluation agents\. During the toolset construction phase, we adoptGPT\-4o,Gemini\-3\-Flash\-Preview, andQwen\-Maxto assess cross\-model robustness\. Detailed configurations are provided in Appendix[B](https://arxiv.org/html/2607.07321#A2)\.

### 4\.2Performance Comparisons

The main experimental results are summarized in Table[1](https://arxiv.org/html/2607.07321#S4.T1)\. In general,EvoSOPoutperforms both the base agent and other selected tool\-related baselines\. On both subset of ACEBench,EvoSOPachieves a significant improvement over the base method, yielding gains ranging from 2\.5% to 13\.4% depending on the backbone model\. This performance surge indicates that the evolved SOPs effectively address recurring reasoning bottlenecks by providing the agent with robust and reliable logic blocks\.

Table 1:Averaged successful rate±\\pmstandard error \(%\) of the baselines andEvoSOPon benchmark ACEBench and Tau2Bench\. Note that all the base agentic methods relied by tool\-related methods are run on GPT\-4o\.In the challenging Tau2Bench\-Telecom, which is characterized by a larger tool space and intricate stateful transitions,EvoSOPmaintains a steady performance lead\. Although the margin of improvement is more concentrated compared to ACEBench due to the inherent complexity of the domain, the results show thatEvoSOPcan navigate and optimize tools even in high\-entropy scenarios where static or one\-shot toolsets typically struggle\.

From the experiments, we also observe thatEvoSOPproduces reliable SOPs\. Our analysis of the trajectories reveals that GPT\-4o often encounters reasoning failures as the context window grows or when tasks require precise temporal tracking\. For example, in text message management scenario \(e\.g\., deleting the earliest message\), agents using atomic actions often become indecisive after multiple turns, frequently returning control to the user for clarification, or deleting the wrong target\.

While ASI can induce SOPs for such workflows, its one\-shot nature often leads to brittle logic that may delete the latest message instead of the earliest, causing cascading errors in similar but slightly different contexts\. In contrast, the behavior of DRAFT becomes more stable as it does not make substantial changes to the tools\.EvoSOPemploys itsReviewerandMergerto evaluate execution feedback\. It identifies these subtle logic flaws, merges redundant tools, and prunes SOPs that exhibit high error rates\. This iterative self\-correction and complete lifecycle management ensure that the resulting toolset is not just larger, but fundamentally more reliable and useful\.

![Refer to caption](https://arxiv.org/html/2607.07321v1/x2.png)Figure 2:The averaged reasoning rounds across epochs in dataset ACEBench \.#### Reasoning Compression\.

A core hypothesis in this study is that SOPs should reduce the cognitive load on the agent by encapsulating multi\-step workflows\. In Figure[2](https://arxiv.org/html/2607.07321#S4.F2), we illustrate the average number of reasoning rounds per task across the epochs\.

The experimental results confirm that the transition from atomic actions to SOPs substantially streamlines the interaction process\. In the initial phases, the toolset may contain experimental or unstable SOPs, occasionally leading to redundant trial\-and\-error reasoning\. However, as the iterative cycle progresses,EvoSOPfilters out low\-utility tools and consolidates overlapping routines\. By the final several epochs, the number of interaction rounds stabilizes at a significantly lower level than that of baselines\. Such reasoning compression not only reduces API latency and cost but also minimizes the risk of the agent losing focus within long\-horizon trajectories, which is a primary driver of the observed increase in success rates\.

### 4\.3Ablation Study

![Refer to caption](https://arxiv.org/html/2607.07321v1/x3.png)Figure 3:Performance ofEvoSOPand its ablated variants in dataset ACEBench\.To quantify the individual contribution of each component within the proposedEvoSOP, we conduct an ablation study by systematically removing theReviewerandMergermodules\. Figure[3](https://arxiv.org/html/2607.07321#S4.F3)illustrates the average performance of the completeEvoSOPand its variants\. Overall, the ablation study demonstrates that the superior performance ofEvoSOPis not derived from any single module but from the synergy of its various components, which together provide comprehensive tool lifecycle management\.

Specifically, the experimental results reveal that the iterative reviewing and pruning procedure, driven by theReviewer, has the most profound impact on final performance\. When the pruning mechanism is disabled, the success rate of the agent significantly declines on both datasets\. These results confirm that, while theConstructorintroduces beneficial SOPs, it also inevitably generates low\-quality or context\-sensitive tools that can introduce noise\. Without the “backward propagation” of performance feedback provided by theReviewer, these suboptimal tools accumulate, leading to a bloated toolset that confuses the agent’s decision\-making\. These findings explain the performance gap betweenEvoSOPand the one\-shot ASI baseline \(as shown in Table[1](https://arxiv.org/html/2607.07321#S4.T1)\), reinforcing that active tool management is just as critical as tool creation for self\-evolving agents\.

Besides, we evaluate the necessity of theMergermodule\. As shown in Figure[3](https://arxiv.org/html/2607.07321#S4.F3), the variant without the merging process also exhibits performance degradation\. TheMergerperforms semantic and functional consolidation, transforming narrow and task\-specific action sequences into generalized SOPs\. By merging overlapping routines, the framework maintains a compact toolset where each SOP possesses a broader scope of applicability and higher reliability\. These results indicate that these consolidated tools are invoked more frequently across diverse scenarios, which in turn reduces their risk of being erroneously evicted during the pruning phase\. Consequently, theMergeracts as a “regularizer” that fosters the emergence of robust, high\-order tool\-use patterns, ensuring the long\-term stability of the agent system\.

### 4\.4Case Study

![Refer to caption](https://arxiv.org/html/2607.07321v1/x4.png)Figure 4:The lifetime of synthesized SOPs\. The numbers inside each block represent the success rate \(\#success/\#total\) of the SOP\. Lines ending with a cross indicate that the corresponding SOPs have been removed during the optimization cycle\.To better understand the optimization process, we analyze a representative execution ofEvoSOPon ACEBench\. We track the utilization and performance metrics of selected SOPs to illustrate howEvoSOPdistinguishes between high\-utility, high\-risk, and redundant tools\. As shown in Figure[4](https://arxiv.org/html/2607.07321#S4.F4), we observe some distinct lifetime patterns:

\(i\)Fundamental SOPs: Tools likefetch\_ messageexhibit high invocation frequency and near\-zero error propensity\. These represent stable logic that the framework identifies early and retains as core components of agents\.

\(ii\)Transient SOPs:manage\_and\_send\_mess\- ageis synthesized during Epoch 1 but immediately evicted by theReviewerdue to a critical failure rate\. This demonstrates the framework’s ability to prevent unreliable code from polluting the toolset\. Similarly,retrieve\_flight\_detailsis pruned after several epochs because its marginal utility is low, it is rarely invoked, and introduces non\-negligible reasoning overhead without a proportional increase in success rate\.

\(iii\)Merged SOPs: Initially, theConstructorgenerated two task\-specific tools, i\.e\.,order\_food\_onlineandorder\_food\_from\_ merchant\. Later theMergeridentified their functional overlap and synthesized a generalized SOP,enhanced\_manage\_food\_order\. Consequently, the original specific tools are pruned to maintain toolset leanness, while the new SOP continued to perform reliably across diverse contexts\.

This case clearly demonstrates how the designed components cooperate to produce a compact SOP toolset with high\-quality SOPs\. In general, the size of the SOP set remains consistently low, even as new SOPs are continually generated\. We summarize the macro\-level evolution of the toolset composition in Appendix[C](https://arxiv.org/html/2607.07321#A3), showing thatEvoSOPmaintains the toolset at a compact scale\.

## 5Related Works

Early research primarily focuses on enhancing tool mastery through parametric updates, employing supervised fine\-tuning or reinforcement learning to improve tool retrieval and invocation accuracyBaiet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib13)\); Qinet al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib7)\); Liet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib15)\)\. In contrast, non\-parametric methods optimize tool use without modifying the underlying model\. For example, DRAFTQuet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib14)\)and EasyToolYuanet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib16)\)refine tool documentation and retrieval strategies through trial feedback\. Moving toward self\-evolution, several studies empower agents to synthesize new tools via code generation, such as VoyagerWanget al\.\([2023](https://arxiv.org/html/2607.07321#bib.bib18)\), CRAFTYuanet al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib10)\), and AlitaQiuet al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib23)\), while ASIWanget al\.\([2025](https://arxiv.org/html/2607.07321#bib.bib9)\)introduces a mechanism to induce high\-level skills from successful action trajectories\. However, these works typically treat tool creation as a one\-off event and lack a long\-term management mechanism, often leading to toolkit bloating and reasoning redundancy, which motivates the development ofEvoSOPin this study\.

## 6Conclusions

In this study, we proposeEvoSOP, a novel framework designed to empower LLM\-based agents to self\-evolve through iterative tool optimization\. By synthesizing granular atomic actions into high\-level and reusable SOPs,EvoSOPboosts task success rates and addresses the reasoning overhead inherent in static toolsets\. Different from existing methods that treat tool creation as a one\-time event, our framework establishes a continuous optimization lifecycle, effectively mitigating the risks of logic fragmentation and toolset bloating\. Extensive experiments on ACEBench and Tau2Bench demonstrate thatEvoSOPsignificantly enhances task success rates while reducing the number of reasoning rounds across diverse benchmarks\.

## References

- Y\. Bai, Y\. Bao, G\. Chen, J\. Chen, N\. Chen, R\. Chen, Y\. Chen, Y\. Chen, Y\. Chen, Z\. Chen, J\. Cui, H\. Ding, M\. Dong, A\. Du, C\. Du, D\. Du, Y\. Du,et al\.\(2025\)Kimi K2: open agentic intelligence\.CoRRabs/2507\.20534\.External Links:2507\.20534Cited by:[§5](https://arxiv.org/html/2607.07321#S5.p1.1)\.
- τ\\tau2\{\}^\{\\mbox\{2\}\}\-bench: evaluating conversational agents in a dual\-control environment\.CoRRabs/2506\.07982\.External Links:2506\.07982Cited by:[§4\.1](https://arxiv.org/html/2607.07321#S4.SS1.p1.1)\.
- T\. B\. Brown, B\. Mann, N\. Ryder, M\. Subbiah, J\. Kaplan, P\. Dhariwal, A\. Neelakantan, P\. Shyam, G\. Sastry, A\. Askell, S\. Agarwal, A\. Herbert\-Voss, G\. Krueger, T\. Henighan, R\. Child, A\. Ramesh, D\. M\. Ziegler, J\. Wu, C\. Winter, C\. Hesse,et al\.\(2020\)Language models are few\-shot learners\.InAdvances in Neural Information Processing Systems 33: Annual Conference on Neural Information Processing Systems 2020, NeurIPS 2020, December 6\-12, 2020, virtual,Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p1.1)\.
- C\. Chen, X\. Hao, W\. Liu, X\. Huang, X\. Zeng, S\. Yu, D\. Li, S\. Wang, W\. Gan, Y\. Huang, W\. Liu, X\. Wang, D\. Lian, B\. Yin, Y\. Wang, and W\. Liu \(2025\)ACEBench: who wins the match point in tool learning?\.CoRRabs/2501\.12851\.External Links:2501\.12851Cited by:[§4\.1](https://arxiv.org/html/2607.07321#S4.SS1.p1.1)\.
- M\. Chen, J\. Tworek, H\. Jun, Q\. Yuan, H\. P\. de Oliveira Pinto, J\. Kaplan, H\. Edwards, Y\. Burda, N\. Joseph, G\. Brockman, A\. Ray, R\. Puri, G\. Krueger, M\. Petrov, H\. Khlaaf, G\. Sastry, P\. Mishkin, B\. Chan, S\. Gray, N\. Ryder, M\. Pavlov, A\. Power,et al\.\(2021\)Evaluating large language models trained on code\.CoRRabs/2107\.03374\.External Links:2107\.03374Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p1.1)\.
- F\. Fabiano, M\. B\. Ganapini, A\. Loreggia, N\. Mattei, K\. Murugesan, V\. Pallagani, F\. Rossi, B\. Srivastava, and K\. B\. Venable \(2025\)Thinking fast and slow in human and machine intelligence\.Commun\. ACM68\(8\),pp\. 72–79\.Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p2.1)\.
- H\. Gao, J\. Geng, W\. Hua, M\. Hu, X\. Juan, H\. Liu, S\. Liu, J\. Qiu, X\. Qi, Y\. Wu, H\. Wang, H\. Xiao, Y\. Zhou, S\. Zhang, J\. Zhang, J\. Xiang, Y\. Fang, Q\. Zhao, D\. Liu, Q\. Ren, C\. Qian, Z\. Wang, M\. Hu, H\. Wang, Q\. Wu, H\. Ji, and M\. Wang \(2025\)A survey of self\-evolving agents: on path to artificial super intelligence\.CoRRabs/2507\.21046\.External Links:2507\.21046Cited by:[§2](https://arxiv.org/html/2607.07321#S2.p1.1)\.
- X\. Li, W\. Jiao, J\. Jin, G\. Dong, J\. Jin, Y\. Wang, H\. Wang, Y\. Zhu, J\. Wen, Y\. Lu, and Z\. Dou \(2025\)DeepAgent: A general reasoning agent with scalable toolsets\.CoRRabs/2510\.21618\.External Links:2510\.21618Cited by:[§5](https://arxiv.org/html/2607.07321#S5.p1.1)\.
- X\. Li \(2025\)A review of prominent paradigms for llm\-based agents: tool use, planning \(including rag\), and feedback learning\.InProceedings of the 31st International Conference on Computational Linguistics, COLING 2025, Abu Dhabi, UAE, January 19\-24, 2025,pp\. 9760–9779\.Cited by:[§2](https://arxiv.org/html/2607.07321#S2.p1.1)\.
- M\. M\. Liu, D\. Garcia, F\. Parllaku, V\. Upadhyay, S\. F\. A\. Shah, and D\. Roth \(2025\)ToolScope: enhancing LLM agent tool use through tool merging and context\-aware filtering\.CoRRabs/2510\.20036\.External Links:2510\.20036Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p3.1)\.
- B\. Lyu, X\. Cong, H\. Yu, P\. Yang, Y\. Qin, Y\. Ye, Y\. Lu, Z\. Zhang, Y\. Yan, Y\. Lin, Z\. Liu, and M\. Sun \(2023\)GitAgent: facilitating autonomous agent with github by tool extension\.CoRRabs/2312\.17294\.External Links:2312\.17294Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p3.1)\.
- G\. Mialon, C\. Fourrier, T\. Wolf, Y\. LeCun, and T\. Scialom \(2024\)GAIA: a benchmark for general AI assistants\.InThe Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7\-11, 2024,Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p1.1)\.
- Z\. Pan, Q\. Pei, Y\. Li, Q\. Sun, Z\. Tang, H\. V\. Zhao, C\. He, and L\. Wu \(2025\)REST: stress testing large reasoning models by asking multiple problems at once\.CoRRabs/2507\.10541\.External Links:2507\.10541Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p2.1)\.
- Y\. Qin, S\. Liang, Y\. Ye, K\. Zhu, L\. Yan, Y\. Lu, Y\. Lin, X\. Cong, X\. Tang, B\. Qian, S\. Zhao, L\. Hong, R\. Tian, R\. Xie, J\. Zhou, M\. Gerstein, D\. Li, Z\. Liu, and M\. Sun \(2024\)ToolLLM: facilitating large language models to master 16000\+ real\-world apis\.InThe Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7\-11, 2024,Cited by:[Appendix B](https://arxiv.org/html/2607.07321#A2.SS0.SSS0.Px3.p1.1),[§1](https://arxiv.org/html/2607.07321#S1.p1.1),[§1](https://arxiv.org/html/2607.07321#S1.p3.1),[§2](https://arxiv.org/html/2607.07321#S2.p1.1),[§5](https://arxiv.org/html/2607.07321#S5.p1.1)\.
- J\. Qiu, X\. Qi, T\. Zhang, X\. Juan, J\. Guo, Y\. Lu, Y\. Wang, Z\. Yao, Q\. Ren, X\. Jiang, X\. Zhou, D\. Liu, L\. Yang, Y\. Wu, K\. Huang, S\. Liu, H\. Wang, and M\. Wang \(2025\)Alita: generalist agent enabling scalable agentic reasoning with minimal predefinition and maximal self\-evolution\.CoRRabs/2505\.20286\.External Links:2505\.20286Cited by:[§5](https://arxiv.org/html/2607.07321#S5.p1.1)\.
- C\. Qu, S\. Dai, X\. Wei, H\. Cai, S\. Wang, D\. Yin, J\. Xu, and J\. Wen \(2025\)From exploration to mastery: enabling llms to master tools via self\-driven interactions\.InThe Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24\-28, 2025,Cited by:[§4\.1](https://arxiv.org/html/2607.07321#S4.SS1.p1.1),[§5](https://arxiv.org/html/2607.07321#S5.p1.1)\.
- C\. Raffel, N\. Shazeer, A\. Roberts, K\. Lee, S\. Narang, M\. Matena, Y\. Zhou, W\. Li, and P\. J\. Liu \(2020\)Exploring the limits of transfer learning with a unified text\-to\-text transformer\.J\. Mach\. Learn\. Res\.21,pp\. 140:1–140:67\.Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p1.1)\.
- H\. Touvron, T\. Lavril, G\. Izacard, X\. Martinet, M\. Lachaux, T\. Lacroix, B\. Rozière, N\. Goyal, E\. Hambro, F\. Azhar, A\. Rodriguez, A\. Joulin, E\. Grave, and G\. Lample \(2023\)LLaMA: open and efficient foundation language models\.CoRRabs/2302\.13971\.External Links:2302\.13971Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p1.1)\.
- G\. Wang, Y\. Xie, Y\. Jiang, A\. Mandlekar, C\. Xiao, Y\. Zhu, L\. Fan, and A\. Anandkumar \(2023\)Voyager: an open\-ended embodied agent with large language models\.External Links:2305\.16291Cited by:[§5](https://arxiv.org/html/2607.07321#S5.p1.1)\.
- X\. Wang, Y\. Chen, L\. Yuan, Y\. Zhang, Y\. Li, H\. Peng, and H\. Ji \(2024\)Executable code actions elicit better LLM agents\.InForty\-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21\-27, 2024,Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p1.1)\.
- Z\. Z\. Wang, A\. Gandhi, G\. Neubig, and D\. Fried \(2025\)Inducing programmatic skills for agentic tasks\.CoRRabs/2504\.06821\.External Links:2504\.06821Cited by:[§3\.1](https://arxiv.org/html/2607.07321#S3.SS1.p1.1),[§4\.1](https://arxiv.org/html/2607.07321#S4.SS1.p1.1),[§5](https://arxiv.org/html/2607.07321#S5.p1.1)\.
- S\. Yao, J\. Zhao, D\. Yu, N\. Du, I\. Shafran, K\. R\. Narasimhan, and Y\. Cao \(2023\)ReAct: synergizing reasoning and acting in language models\.InThe Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1\-5, 2023,Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p1.1),[§2](https://arxiv.org/html/2607.07321#S2.SS0.SSS0.Px1.p1.14)\.
- L\. Yuan, Y\. Chen, X\. Wang, Y\. Fung, H\. Peng, and H\. Ji \(2024\)CRAFT: customizing llms by creating and retrieving from specialized toolsets\.InThe Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7\-11, 2024,Cited by:[§1](https://arxiv.org/html/2607.07321#S1.p3.1),[§3\.1](https://arxiv.org/html/2607.07321#S3.SS1.p1.1),[§5](https://arxiv.org/html/2607.07321#S5.p1.1)\.
- S\. Yuan, K\. Song, J\. Chen, X\. Tan, Y\. Shen, K\. Ren, D\. Li, and D\. Yang \(2025\)EASYTOOL: enhancing llm\-based agents with concise tool instruction\.InProceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies, NAACL 2025 \- Volume 1: Long Papers, Albuquerque, New Mexico, USA, April 29 \- May 4, 2025,pp\. 951–972\.Cited by:[§5](https://arxiv.org/html/2607.07321#S5.p1.1)\.

## Appendix APseudo\-code of Training Workflow

In this section, we present the pseudo\-code to clearly illustrate the main training workflow of our method\. While the descriptions in the main text are module\-centric, the pseudo\-code provides a global overview; consequently, some notational differences may exist between the two\. The correspondences are as follows:

- •The functionfmergef\_\{\\text\{merge\}\}takes as input the union of the SOP set maintained from previous iterations and the SOPs newly generated in the current iteration\.
- •BiB\_\{i\}denotes theii\-th mini\-batch in the index setBB, corresponding tobb\.
- •SSrepresents the dynamically generated and pruned SOP set, which eventually becomes the solidified SOP setSsolidS\_\{\\text\{solid\}\}\.

Algorithm 1EvoSOP training workflowInput:execution log set

ξ\\mathcal\{\\xi\}, atomic tool set

ℱ\\mathcal\{F\}, training set index

ItrainI\_\{\\mathrm\{train\}\}, batched index set

BB
Built in:max iterations

MM, LLM\-based function

f⋅​\(⋅\)f\_\{\\cdot\}\(\\cdot\), verification module

gverify​\(⋅\)g\_\{\\mathrm\{verify\}\}\(\\cdot\)
Initialize

𝒮=ϕ,ℛ=ϕ\\mathcal\{S\}=\\phi,\\mathcal\{R\}=\\phi
for

i=0i=0to

M−1M\-1do

if

i<len​\(B\)i<\\mathrm\{len\}\(B\)then

𝒮Bi=ϕ\\mathcal\{S\}\_\{B\_\{i\}\}=\\phi

for

jjin

BiB\_\{i\}do

𝒮Bi=𝒮Bi∪frewrite​\(fextract​\(ξj\),ℱ\)\\mathcal\{S\}\_\{B\_\{i\}\}=\\mathcal\{S\}\_\{B\_\{i\}\}\\cup f\_\{\\mathrm\{rewrite\}\}\(f\_\{\\mathrm\{extract\}\}\(\\mathcal\{\\xi\}\_\{j\}\),\\mathcal\{F\}\)

endfor

endif

𝒮=𝒮∪𝒮Bi∪fmerge​\(𝒮∪𝒮Bi\)\\mathcal\{S\}=\\mathcal\{S\}\\cup\\mathcal\{S\}\_\{B\_\{i\}\}\\cup f\_\{\\mathrm\{merge\}\}\(\\mathcal\{S\}\\cup\\mathcal\{S\}\_\{B\_\{i\}\}\)

ℱ′=ℱ∪\{fschema​\(s\)\|s∈S\}\\mathcal\{F\}^\{\\prime\}=\\mathcal\{F\}\\cup\\left\\\{f\_\{\\mathrm\{schema\}\}\(s\)\|s\\in S\\right\\\}

ξ^=gverify​\(ℱ′\)\\widehat\{\\mathcal\{\\xi\}\}=g\_\{\\mathrm\{verify\}\}\(\\mathcal\{F\}^\{\\prime\}\)

for

jjin

ItrainI\_\{\\mathrm\{train\}\}do

ℛ=ℛ⊕freview​\(ξi^,𝒮\)\\mathcal\{R\}=\\mathcal\{R\}\\oplus f\_\{\\mathrm\{review\}\}\(\\widehat\{\\mathcal\{\\xi\}\_\{i\}\},\\mathcal\{S\}\)

endfor

for

ssin

𝒮\\mathcal\{S\}do

if

ℛs​exists​and​fcheck​\(ℛs\)\\mathcal\{R\}\_\{s\}\\ \\mathrm\{exists\}\\ \\mathrm\{and\}\\ f\_\{\\mathrm\{check\}\}\(\\mathcal\{R\}\_\{s\}\)==“remove”then

ℛ=ℛ∖ℛs\\mathcal\{R\}=\\mathcal\{R\}\\setminus\\mathcal\{R\}\_\{s\}

𝒮=𝒮∖s\\mathcal\{S\}=\\mathcal\{S\}\\setminus s

endif

endfor

save

𝒮,ℛ\\mathcal\{S\},\\mathcal\{R\}
endfor

## Appendix BDetailed Experimental Settings and Configurations

In this section, we provide a comprehensive description of the experimental configurations, settings, and implementation details\. This section offers a detailed overview of the parameters and environments used in our study, ensuring the transparency and reproducibility of the reported results\.

#### Dataset information\.

In our experiments, we evaluate our method and the baselines on ACEBench and Tau2Bench\. ACEBench is a tool\-use\-oriented benchmark, in which theAgent\-Multi\-StepandAgent\-Multi\-Turnsubsets focus on evaluating agents’ task\-completion ability when equipped with different tools\. Tau2Bench is a benchmark for conversational AI agents that involves issue resolution and simulated human feedback\. To align with the pure tool\-use setting considered in our study, we use the solo mode of the Telecom subset, which focuses on resolving phone network connection issues by the agent itself\.

#### Data preparation for EvoSOP and baselines\.

For each dataset, we first run the base methods, namely ReAct and DFSDT, to collect an initial set of trajectories, regardless of whether the trajectories are successful\. During the training process of EvoSOP, we feed 5 randomly sampled trajectories in each of the first 5 iterations, exposing our method to 25 trajectories and tasks in total\. In the last 5 iterations, EvoSOP only performs merging, evaluation, and review, meaning that no new SOPs are generated from trajectories\.

To ensure a fair comparison, we expose the same number of trajectories to the ASI baseline for agentic skill induction\. The reported results include performance on both exposed and unseen tasks\.

#### Baselines\.

In addition to the ReAct agentic system described earlier, we reproduce another well\-known method, DFSDTQinet al\.\([2024](https://arxiv.org/html/2607.07321#bib.bib7)\), which implements a DFS\-based algorithm to explore potentially promising choices and backtrack from failed branches\.

DFSDT allows the agent to give up and backtrack to a previous state when encountering obstacles during task solving\. Typically, whenmax\_beam\_sizeis set to 1, DFSDT effectively degenerates into a ReAct agent with the additional option of giving up\. DFSDT dumps and restores the current states of both the agent and the environment before each reasoning step\. When DFSDT gives up on a search branch, it restores the working state from the previously saved backup and performs a re\-reasoning step, providing information about the failed branches in the prompt so that the agent can avoid repeating the same mistakes\. For both ReAct and DFSDT, we setmax\_stepsto 100, and we setmax\_beam\_sizeof DFSDT to 3\.

For the two tool\-related methods,ASIandDRAFT, we select them as representative approaches for one\-shot high\-level tool optimization and tool\-docstring optimization, respectively\. We apply them to both ReAct and DFSDT for comparison\. For all methods mentioned above, we run 6 complete workflows on ACEBench and 3 complete workflows on Tau2Bench\. The results reported in Table[1](https://arxiv.org/html/2607.07321#S4.T1)are the average success rates±\\pmstandard errors across runs\.

All of the used artifacts including benchmarks and code bases are consistent with their intended use\.

#### Backbone models\.

To ensure a fair comparison within our experiments, we consistently useGPT\-4oas the backbone model for executing vanilla ReAct and DFSDT, as well as for the evaluation and testing phases of ASI, DRAFT, and EvoSOP, since these phases depend on the base agent methods\. This is why we do not report the results of ReAct and DFSDT withGemini\-3\-Flash\-PrevieworQwen\-Maxas the backbone model\. For the core algorithms of ASI, DRAFT, and EvoSOP, we adoptGPT\-4o,Gemini\-3\-Flash\-Preview, andQwen\-Maxto assess the cross\-model robustness\. Detailed documentation regarding the model’s training data coverage, linguistic capabilities, and known limitations can be found in the official technical report\.

Our proposed method is parameter\-free\. Therefore, we did not perform any local model training\. The computational cost is limited to the inference time via API calls to the proposed models\. All experiments were conducted on a standard CPU\.

## Appendix CToolset Maintenance and Convergence\.

In this section, we supplement the description that EvoSOP maintains a condense but effective tool set at a low scale\. Figure[5](https://arxiv.org/html/2607.07321#A3.F5)summarizes the macro evolution of the toolset’s composition\. During the initial phase \(Epochs 1 to 5\), the toolset size undergoes rapid expansion as theConstructorexplores various action patterns from the training trajectories\. However, as the optimization loop proceeds, the growth curve flattens and eventually enters a dynamic equilibrium where new merged SOPs are only added if they offer significant utility gains over existing ones\. Notably,EvoSOPmaintains the toolset on a compact scale \(typically fewer than 10 SOPs\) while achieving a task success rate of approximately 80%\. Such stabilization mirrors the behavior of a decaying learning rate in traditional optimization, where the system converges to a minimal yet powerful set of SOPs\.

![Refer to caption](https://arxiv.org/html/2607.07321v1/x5.png)Figure 5:Trends of constructed, involved, and maintained SOPs across training epochs in ACEBench\.
## Appendix DPrompt Engineering inEvoSOP

In this section, we summarize our prompt\-engineering strategies used to implement the proposed LLM\-based modules, namelyConstructor,Merger, andReviewer\. In general, each component is treated as an independent agent\. The prompt for each agent is carefully designed to provide a standardized description of its role, primary objective, operating paradigm, action boundaries, output requirements, and necessary few\-shot examples\.

We take the twoConstructorfunctionalities, namely log analysis and SOP functionalization, as representative examples since they include structured content generation and coding\. The other components and modules follow a similar prompt design logic\. The following code block shows the prompt used for log analysis inConstructor\.

\#\#Identity

Youareaspecializedagentwhoisgoodattextextractionandanalyzing\.Youaredesignedtosummarizeandextractsomereusableandmeaningfulconsecutive‘tool\_call‘sfromtheprovidedactiontrajectories,formingaStandardOperationProcess\(SOP\)\.

\\par\#\#CoreMission\.

Yourprimarypurposeistosummarizeandextractthegivenworkflows,inducereusableandmeaningfulconsecutive‘tool\_call‘sasanSOP\.

TherepossiblycontainsmorethanoneSOPs,ornoSOP\.RewritetheSOPswhichyouthinkthatsatisfythefollowingrules,possiblymultiple,one,ornone\.

\\par\#\#\#OperatingParadigm

Youaregivenanactiontrajectoryofacompletedtaskcontaining‘tool\_call‘sonly,intheformof\.json,thegivenarguments,andthenameofthatspecifictool\.

Some‘tool\_call‘shaveidentifiablefeatureswhichindicatesthattheirfunctionalitymayhavestronginterconnectionsforcombiningthemasanSOP\.

YourparadigmofinducingSOPsarelistedasfollows:

1\.\*\*Consecutive‘tool\_call‘\*\*:Thisindicatesthatthe‘tool\_call‘sareexecutedconsecutively\.

2\.\*\*Separated‘tool\_call‘MessageNumber\*\*:Thisindicatesthatthe‘tool\_call‘arecloselyconnected,butnotexecutedconsecutively\.Forexample,‘tool\_call‘Awritedownapythonfile,andencounterssomeerrorwithconsecutive‘tool\_call‘B,but‘tool\_call‘CismoregeneralandsuccessfullyrunsAwithouterrors\.

3\.\*\*Similar‘tool\_call‘ResultsandFollowingInputArgument\*\*:Thisindicatesthattwo‘tool\_call‘sarestronglyconnected,astheresultofone‘tool\_call‘isimmediatelyusedinanotherone’sinput\.

4\.\*\*MeaningfulCombination\*\*:Someconsecutive‘tool\_call‘scombinationareofgreatrealitymeanings,as‘search‘plusing‘write\_file‘meanssearchsomethinganddirectlywritethistosomedesignatedfile\.

5\.\*\*FrequentlyUsage\*\*:Someconsecutive‘tool\_call‘scombinationareoffrequentoccurrence,whichimplysthattheycanbemodularized\.

\\par\#\#\#ImportantConstraintsandHints

1\.Asisstatedabove,the\*\*consecutive\*\*‘tool\_call‘meansthetheyshouldbeexecutedascloseaspossible\.Donotinduce‘tool\_call‘stoofar,makingthespantoobig\.

2\.ThetoolsininducedSOPshouldhavestronginterconnection\.Youshouldcarefullychecktheconnectionbetween‘tool\_call‘sbyexaminingthe‘tool\_call‘argumentsandresults\.DONOTINTEGRATEIRRELEVANTTOOLCOMBINATIONSTOCOMPLICATETHERESULT\.

3\.TheinducedSOPshouldcontaining\*\*atleast\*\*2‘tool\_call‘actionstomaketheinducedSOPbeconciseandnottoosimple\.

4\.TheinducedSOPshouldcontaining\*\*nomorethan\*\*5‘tool\_call‘actionstomaketheinducedSOPbegeneralandscalabletobeappliedtoothersimilartasks\.

5\.Consecutivefileoperationshaveahigherprobabilityofbeingcombinedtogether\.Youmayneedtoconsiderdeeperaboutthereturnedvalueofsome‘tool\_call‘,fortheinputparametersofthenext‘tool\_call‘\.

6\.Focusmoreontheworkflowrevealedbythelogs\.Donotcaretoomuchaboutthecontentin’text’fieldifitisextremelylong\.

7\.Excepttherequiredoutputinthefollowingoutputguidance,DONOTOUTPUTANYTHINGELSE\.

\\par\#\#OutputGuidance

Theoutputshouldjustbeaserializedpythonlistobject\.

ThelistobjectmaycontainonevaluableinducedSOP,andtheSOPshouldalsobealist,containingthecorresponding‘message\_number‘inthe‘tool\_call‘logs\.

Ifyouthinkthereisnotvaluablecombination,outputanemptylist\.

\\par\#\#\#Example

\\par\*\*ExampleInput:\*\*

\\par\{example\_trajectory\}

\\par\*\*ExampleOutput\*\*

\\par\{example\_tool\_call\_ids\}

\\par\#\#InputLogs

Thefollowingcontentsaretheinputlogsforyoutoprocess\.Tryyourbesttofinishyourtask\.

The following code block shows the prompt of SOP functionalization inConstrutor\. The “function\_guidance” should be a guidance and limitation of constructing SOPs, which could vary among different environments and datasets\.

\\par\#\#Identity

Youareaspecializedagentwhoisgoodatsoftwareengineering\.Youaredesignedtorewritetheconsecutive‘tool\_call‘stoastandardoperatingprocecure\(SOP\)fromtheprovidedactiontrajectories\.

\\par\#\#CoreMission

Yourprimarypurposeistoextractthecurrentworkflows,inducethe‘tool\_call‘sinthegivenlogstoawell\-boundedSOP,andrewritetheinducedSOPintheformofanewtoolfunctionforfutureusage\.

\\par\#\#\#OperationParadigm

Youaregivenanactiontrajectoryofacompletedtaskcontaining‘tool\_call‘sonly,intheformof\.json,withthemessagenumber,thegivenarguments,andthenameofthatspecifictool\.

Youarealsogiventhedocstringofalltheinvolved‘tool\_call‘s,whichwillhelpyouconcludesomeimplicitrequirementsorrestraintsaboutthetoolfunction\.

\\par\#\#\#ImportantConstraintsandHints

1\.Consecutivefileoperationshaveahigherprobabilityofbeingcombinedtogether\.Youmayneedtoprocessthereturnedvalueofsome‘tool\_call‘,fortheinputparametersofthenext‘tool\_call‘\.

2\.Focusmoreontheworkflowrevealedbythelogs\.Donotcaretoomuchaboutthecontentin’text’fieldwithrepeatedpatterns\.

3\.Payspecialattentiontothedocstringsoftheinputparametersofthe‘tool\_call‘scomponents,andrevealanyspecialpatterniftheinputparametersaredirectlypassedtothese‘tool\_call‘s\.

4\.Youshouldincludealloftheused‘tool\_call‘names\(inorderifpossible\)inthedocstring\.

5\.Exceptthecode,DONOTOUTPUTANYOTHERTHINGS\.

\\par\#\#OutputFunctionGuidance

\\par\{function\_guidance\}

\\par\#\#InputLogs

Thefollowingcontentsaretheinputmessagesforyoutoprocess\.

\\par\{trajectories\}

\\parThefollowingcontentsarethedocstringsofalltheinvolved‘tool\_call‘s\.

\\par\{tool\_docstrings\}

\\par

## Appendix EAn example of the synthesized SOP

In this section, we provide the source code of a representative SOP generated byEvoSOP\. This SOP function contains four separate tool calls and a branching control mechanism that determines whether the message has been successfully sent directly, as well as the actions taken by the SOP in each case\.

importtraceback

fromtypingimportAny,Dict

\\pardefsend\_message\_workflow\(self,message:str,receiver\_name:str,sender\_name:str\)\-\>Dict\[str,Any\]:

"""

Thisfunctionperformsthefollowingsteps:

1\.Attemptstosendamessagefromoneusertoanother\.

2\.Ifsendingfailsduetomemoryissues,itretrievesthelatestmessageID\.

3\.DeletesthelatestmessagebasedonitsID\.

4\.Retriessendingthemessage\.

\\parArgs:

self:Instanceofthecurrentclass\.

message\(str\):Themessagecontenttosend\.

receiver\_name\(str\):Nameofthereceiver\.

sender\_name\(str\):Nameofthesender\.

\\parReturns:

dict:Adictionarycontaining:

\-"status"\(bool\):Trueiftheoperationsucceeds,Falseotherwise\.

\-"content"\(dict\):Containsresultsofmessagesending,anddeletionifapplicable\.

\-"send\_status\_initial":Resultofthefirstsendattempt\.

\-"latest\_message\_id":IDofthelatestmessageretrieved\(optional\)\.

\-"delete\_status":Resultofthedeleteoperation\(optional\)\.

\-"send\_status\_final":Resultoftheretrysendoperation\.

"""

try:

\#Step1:Attempttosendthemessageinitially

send\_result\_initial=self\.send\_message\(message=message,receiver\_name=receiver\_name,sender\_name=sender\_name\)

\\par\#Checkifsendingfailedduetomemoryissues

ifnotsend\_result\_initial\[’status’\]:

\#Step2:RetrievethelatestmessageID

latest\_message\_result=self\.get\_latest\_message\_id\(\)

latest\_message\_id=latest\_message\_result\.get\(’message\_id’\)

\\par\#Step3:DeletethelatestmessagebasedonitsID

delete\_result=self\.delete\_message\(message\_id=latest\_message\_id\)

\\par\#Step4:Retrysendingthemessage

send\_result\_final=self\.send\_message\(message=message,receiver\_name=receiver\_name,sender\_name=sender\_name\)

\\parreturn\{

"status":send\_result\_final\[’status’\],

"content":\{

"send\_status\_initial":send\_result\_initial,

"latest\_message\_id":latest\_message\_id,

"delete\_status":delete\_result,

"send\_status\_final":send\_result\_final

\}

\}

\\par\#Messagewassentsuccessfullyinthefirstattempt

return\{

"status":send\_result\_initial\[’status’\],

"content":\{

"send\_status\_initial":send\_result\_initial

\}

\}

\\parexceptExceptionase:

return\{

"status":False,

"content":\{

"error":str\(e\),

"traceback":traceback\.format\_exc\(\)

\}

\}