arXiv CSopen access

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 Haipeng Ding1,2 , Yuexiang Xie2 , Zhewei Wei1, * , Yaliang Li2,∗ , Bolin Ding2 1 Renmin University of China, 2 Alibaba Group

arXiv:2607.07321v1 [cs.AI] 8 Jul 2026

Abstract

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-solving (Fabiano et al., 2025). 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 tasks (Pan et al., 2025). Recent research on tool-augmented agents followed mainly two paths, refining a model’s ability to use specific tools (Qin et al., 2024) and expanding the overall breadth of the available toolset (Lyu et al., 2023). However, these efforts do not address the fundamental inefficiency of reasoning in long and fragmented sequences of atomic actions. While recent studies (Yuan et al., 2024; Liu et al., 2025) 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 introduce E VO SOP, 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, E VO SOP establishes a continuous optimization loop that progressively refines

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 selfevolution 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 introduce E VO SOP, 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 that E VO SOP significantly 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 selfevolving agents.

1

Introduction

Large Language Models (LLMs) (Raffel et al., 2020; Touvron et al., 2023; Brown et al., 2020) have fundamentally advanced the field of artificial intelligence, demonstrating remarkable capabilities in logical reasoning and general-purpose problem-solving (Chen et al., 2021). By leveraging external tools, LLM-based agents (Yao et al., 2023; Qin et al., 2024; Wang et al., 2024) extend these strengths beyond text generation to interact with the real world and solve complex and practical tasks (Mialon et al., 2024). * Correspondence to: Zhewei Wei ⟨[email protected]⟩ and Yaliang Li⟨[email protected]⟩

1

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, E VO SOP governs 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 that E VO SOP serves 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 selfevolving 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 propose E VO SOP, 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 that E VO SOP significantly increases task success rates while reducing the number of interaction rounds compared to baselines.

2

instantiated by an LLM, expressed as: at ∼ πLLM (· | Ct ), where Ct represents the context available at time t. Following the paradigm of ReAct (Yao et al., 2023), the action at may consist of a reasoning trace lt and a specific tool call ft . For simplification, we denote the reasoning of the LLM given prompt P as a = πLLM (P ). The environment then returns a response rt (e.g., execution results or error messages), which leads to the next state and observation ot+1 . Context. The context Ct is a structured representation of the agent’s current state, designed to provide the LLM with all necessary information for decision-making. We formalize Ct as a tuple: Ct = ⟨P, G, Ht , Mt , F⟩, where P is the persona or system prompt defining the agent’s role and behavioral constraints, G is the task goal and its associated success criteria, Ht = {(a1 , r1 , o1 ), . . . , (at−1 , rt−1 , ot−1 )} is the interaction history, Mt represents the external memory or long-term knowledge retrieved by the agent, and F is the toolset containing the functional interfaces available to the agent. Atomic Actions and Tool Schema. The toolset F = {f1 , f2 , . . . , fn } initially consists of atomic actions, i.e., granular and single-purpose functions such as file operations or API calls. Each tool fi ∈ F is defined by its schema = ⟨name, desc, params, returns⟩, where name and desc provide 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 H0 = {}. At each time step t, the agent performs the following operations:

Preliminaries

We first introduce the definitions and notations of LLM-based agents. We focus on a practical agentic setting (Gao et al., 2025; Li, 2025) 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 DFSDT (Qin et al., 2024) in Appendix B.

Context Construction : Pt = Format(Ct ), Reasoning : ât = πLLM (Pt ), Acting : rt = Exec(ât , E), State Update : Ht+1 ← Ht ∪ {(ât , rt , ot )}.

Environment and Interaction. We consider an agent interacting with an environment E. At each time step t, the agent receives an observation ot ∈ O from the environment and takes an action at ∈ A based on its internal policy. The policy π is

The process ends when the agent reaches a terminal state or exceeds the maximum iterations. We define an execution trajectory ξq = ((â1 , r1 , o1 ), (â2 , r2 , o2 ), · · · , (âk , rk , ok )) of task q when the agent is terminated after k iterations. 2

Execution Trajectories turn_on_wifi + log_in

… Retrieval

Agent

Agent

Trajectory Analysis tool_call_1:{ Name: turn_on_wifi, Input: N/A, Output: succeed, } tool_call_2:{ Name: log_in, Input: name&password, Output: succeed, }

Atomic Actions

SOPs

SOP1

SOP2

Mergence

turn_on_wifi + log_in + place_order

Merged SOP

log_in + place_order SOP3 …

SOPs SOP Rewriting

Valuable Tool Combination Module 2: Merger

Module 1: Constructor SOP1_result1:{ Works perfectly: True, Cause failure: False, … } SOP1_result2:{ Works partially: True, Reason: wrong username or password, … }

… SOP1

SOP2

SOP3

Atomic Actions

SOPs

Agent

Test Set (Invisible)

Training Set

SOP2_result1:{ Works partially: True, Cause failure: True, Reason: Delete the wrong message, … }

New Logs

…

Module 3: Evaluator

Retained Agent SOP1

High Quality Removed SOPs

SOP2

…

Low Quality

Module 4: Reviewer

Figure 1: The overall architecture of E VO SOP, illustrating the iterative tool optimization lifecycle. The framework employs four collaborative modules, including C ONSTRUCTOR, M ERGER, E VALUATOR, and R EVIEWER.

3

Methodology

3.1

Design Motivation and Principle

beyond simple tool creation by establishing a continuous and iterative tool optimization process. 3.2

As mentioned in Section 1, most LLM-based agents rely on a static toolset F composed of granular atomic actions. While recent studies have explored expanding the toolset through dynamic code generation (Wang et al., 2025; Yuan et al., 2024), 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 lowlevel 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 decisionmaking, ultimately degrading the success rate. To address these challenges, E VO SOP moves

Overview

As illustrated in Figure 1, E VO SOP consists of four collaborative modules that govern the optimization of the toolset, including: (i) C ONSTRUCTOR: This module identifies recurring action sequences within execution trajectories ξ, 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) M ERGER: 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 context C; (iii) E VALUATOR: The agent is equipped with the updated toolset F ′ and reexecutes tasks. This module produces new trajectories that reflect the actual utility and reliability of the evolved SOPs in environments; (iv) R EVIEWER: 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. Although E VO SOP does not modify the learnable parameters of the underlying LLM, its iterative structure constitutes a form of nonparametric structural optimization. We formalize this by drawing a conceptual parallel between 3

E VO SOP and the machine learning pipeline. First, the agent’s interaction with training tasks represents the data acquisition stage, while the execution of tasks using the current toolset F corresponds to forward propagation. The resulting execution trajectories ξ serve as observable behavioral outputs, capturing the agent’s reasoning process and tool-use patterns. Improvement is then achieved through a backward propagation, where E VO SOP analyzes 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 critical regularization mechanisms. 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 a decaying learning rate, where the agent eventually converges toward an optimized hierarchy of toolset. 3.3

and granular toolsets. C ONSTRUCTOR extracts 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). We formalize the SOP construction process as a two-stage transformation: ξi′ = fextract (ξi ),

Si = frewrite (ξi′ , Fatomic ),

where ξi represents the raw execution trajectory for task i, and ξi′ denotes the set of action segments identified as logically coupled. The transformation function frewrite then maps these segments into the resulting SOP source code Si , drawing upon the functional interfaces of the initial atomic toolset. M ERGER: 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 context Ct . Such noise complicates the LLM’s decision-making and may lead to the selection of suboptimal or conflicting tools. To address this, we design the M ERGER, a module dedicated to simplifying the toolset and enhancing its overall quality through structural optimization. The M ERGER analyzes 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: [ Sb = Si , S ′ = fmerge (Sb ),

Tool Optimization Lifecycle in E VO SOP

In this subsection, we detail the tool optimization lifecycle in E VO SOP, which is designed to systematically transform raw interaction experiences into a solidified toolset F of high-level SOPs. Please refer to Appendix D for the selected prompts adopted in E VO SOP indicating our design conception. C ONSTRUCTOR: From Trajectories to Functional Abstractions. The optimization lifecycle begins with the C ONSTRUCTOR, an LLM-based module designed to distill reusable functional abstractions from historical execution trajectories ξ. As established in Section 2, 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 subproblems. The C ONSTRUCTOR identifies 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

i∈b

where b denotes the set of task indices, Sb is the union of newly constructed SOPs, and S ′ represents the consolidated set generated by the merger. E VO SOP adopts 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 4

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, E VO SOP ensures that the final toolset is refined based on empirical performance rather than static heuristics, adhering to the principle of hierarchical efficiency without sacrificing reliability.

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 introduce R EVIEWER, an LLM-based module that functions as a critic. The R EVIEWER analyzes the verification trajectories ξˆ 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.

E VALUATOR: 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. E VO SOP subjects all candidate SOPs to an E VALUATOR, which serves as the experimental foundation for assessing their real-world utility. Specifically, all constructed SOPs within the sets Sb and S ′ 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 F as:  F ′ = Fatomic ∪ fschema (s) | s ∈ Sb ∪ S ′ .

• 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.

This expanded toolset F ′ 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, E VO SOP initiates a full re-execution of the training tasks within a realworld setting. During this process, the framework meticulously monitors task outcomes and captures ˆ These trajecthe resulting execution trajectories ξ. tories 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.

• 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, the R EVIEWER provides 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, E VO SOP performs a global filtering operation to refine the toolset:

R EVIEWER: Quality Control and Simplification. The final stage of the E VO SOP lifecycle 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

R=

M

freview (ξˆi ),

i∈Itrain

Ssolid = {s | fcheck (s, Rs ) ̸= remove, s ∈ S ′ ∪ Sb }, where ⊕ is the review aggregation operator. 5

3.4

Table 1: Averaged successful rate ± standard error (%) of the baselines and E VO SOP on benchmark ACEBench and Tau2Bench. Note that all the base agentic methods relied by tool-related methods are run on GPT-4o.

Training Workflow

As formally specified in Section 3.3, each component of E VO SOP is designed to support a parameter-free training paradigm. Unlike prior studies that predominantly rely on parametric finetuning, E VO SOP realizes the “training” process through iterative optimization of the toolset. The complete training workflow is presented in Algorithm 1 in Appendix A. Mini-batching. At the beginning of the training process, we partition the initial execution trajectories ξ into discrete mini-batches. In those batches, the C ONSTRUCTOR identifies 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, the M ERGER first 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, the R E VIEWER assesses each tool’s empirical contribution and prunes those that exhibit implementation defects or redundant reasoning.

Experiments

4.1

Setup

ACEBench Multi-Step Gemini-3-FP GPT-4o

ReAct + ASI + EvoSOP DFSDT + DRAFT + EvoSOP

/ 45.8 ± 14.8 83.3 ± 2.4 / 84.2 ± 1.9 82.5 ± 2.6

80.8 ± 3.4 60.0 ± 12.9 84.2 ± 1.9 78.3 ± 6.8 75.0 ± 5.8 85.0 ± 0.0

/ 53.3 ± 9.4 84.2 ± 1.9 / 74.2 ± 5.4 85.8 ± 1.9

ReAct + ASI + EvoSOP DFSDT + DRAFT + EvoSOP

ACEBench Multi-Turn / 72.2 ± 3.7 46.7 ± 11.1 57.2 ± 8.0 79.4 ± 4.5 79.4 ± 3.0 / 69.4 ± 4.5 71.1 ± 6.0 66.1 ± 3.0 83.3 ± 3.3 74.4 ± 3.1

/ 65.6 ± 8.8 84.4 ± 3.1 / 78.3 ± 2.6 77.9 ± 4.1

ReAct + ASI + EvoSOP

Tau2-Bench Telecom Solo / 37.1 ± 2.8 35.4 ± 1.1 37.7 ± 1.4 43.3 ± 0.8 40.9 ± 0.4

/ 39.5 ± 4.0 40.2 ± 2.2

Qwen-Max

et al., 2025), 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 ACEBench (Chen et al., 2025) and Tau2Bench (Barres et al., 2025). For ACEBench, we use the agent subset, while for Tau2Bench, we use the solo mode of the Telecom subset. Throughout the experiments, GPT-4o serves as the backbone LLM for all evaluation agents. During the toolset construction phase, we adopt GPT-4o, Gemini-3-Flash-Preview, and Qwen-Max to assess cross-model robustness. Detailed configurations are provided in Appendix B.

Checkpointing. A critical challenge in LLMbased optimization is the potential stochasticity of model behavior, where aggressive pruning might inadvertently remove genuinely beneficial SOPs. To mitigate this risk, E VO SOP avoids 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 S ∗ represents the optimal balance between expressivity and reliability.

4

Backbone

4.2

Performance Comparisons

The main experimental results are summarized in Table 1. In general, E VO SOP outperforms both the base agent and other selected tool-related baselines. On both subset of ACEBench, E VO SOP achieves 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. In the challenging Tau2Bench-Telecom, which is characterized by a larger tool space and intricate stateful transitions, E VO SOP maintains a steady performance lead. Although the margin of improvement is more concentrated compared to ACEBench due to the inherent complexity of the domain, the

Our evaluation compares several distinct tool configurations: (i) ReAct and DFSDT, which use the original atomic actions; (ii) ASI (Wang et al., 2025), whose toolset is augmented with SOPs, referred to as skills in the original paper, induced through a one-time process; (iii) DRAFT (Qu 6

ReAct

ReAct +EvoSOP(GPT-4o) +EvoSOP(Gemini-3-FP)

6 5 4

2

4

Epochs

6

w/o Merger

w/o Reviewer

0.6 0.4 0.2 0.0

0

+EvoSOP

0.8 Success rate

Rounds

7

8

10

ACEBench Multi-Step

ACEBench Multi-Turn

Figure 3: Performance of E VO SOP and its ablated variants in dataset ACEBench.

Figure 2: The averaged reasoning rounds across epochs in dataset ACEBench .

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.

results show that E VO SOP can navigate and optimize tools even in high-entropy scenarios where static or one-shot toolsets typically struggle. From the experiments, we also observe that E VO SOP produces 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. E VO SOP employs its R EVIEWER and M ERGER to 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.

4.3

Ablation Study

To quantify the individual contribution of each component within the proposed E VO SOP, we conduct an ablation study by systematically removing the R EVIEWER and M ERGER modules. Figure 3 illustrates the average performance of the complete E VO SOP and its variants. Overall, the ablation study demonstrates that the superior performance of E VO SOP is 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 the R EVIEWER, 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 the C ONSTRUCTOR introduces 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 the R EVIEWER, these suboptimal tools accumulate, leading to a bloated toolset that confuses the agent’s decisionmaking. These findings explain the performance gap between E VO SOP and the one-shot ASI baseline (as shown in Table 1), reinforcing that active tool management is just as critical as tool creation for self-evolving agents. Besides, we evaluate the necessity of the M ERGER module. As shown in Figure 3, the variant without the merging process also exhibits performance degradation. The M ERGER performs semantic and functional consolidation, transform-

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, 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, E VO SOP filters out low-utility tools and consolidates overlapping routines. By the final several epochs, the number of interaction 7

SOP1. enhanced_manage_food_order SOP2. order_food_online SOP3. order_food_from_merchant

SOP4. fetch_messages_for_user SOP5. retrieve_flight_details SOP6. manage_and_send_message

portional increase in success rate. (iii) Merged SOPs: Initially, the C ON STRUCTOR generated two task-specific tools, i.e., order_food_online and order_food_from_ merchant. Later the M ERGER identified 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, showing that E VO SOP maintains the toolset at a compact scale.

36% 4/11

SOP6

0% unused 50% SOP5 0/2 1/2

50% 1/2

100% 100% 100% 100% 100% 100% 80% 4/4 6/6 5/5 3/3 6/6 5/5 4/5

SOP4 SOP3

100% 75% 5/5 3/4

SOP2

90% 100% 9/10 5/5

SOP1 0

1

2

3

83% 5/6

86% 6/7

88% 100% 89% 7/8 6/6 8/9

83% 100% 100% 5/6 7/7 6/6

100% 50% 100% 67% 2/2 1/2 5/5 2/3

75% 100% 100% 3/4 3/3 3/3

4

5 6 Epochs

7

8

9

10

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.

ing 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, the M ERGER acts as a “regularizer” that fosters the emergence of robust, high-order tool-use patterns, ensuring the long-term stability of the agent system. 4.4

5

Related 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 accuracy (Bai et al., 2025; Qin et al., 2024; Li et al., 2025). In contrast, non-parametric methods optimize tool use without modifying the underlying model. For example, DRAFT (Qu et al., 2025) and EasyTool (Yuan et al., 2025) 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 Voyager (Wang et al., 2023), CRAFT (Yuan et al., 2024), and Alita (Qiu et al., 2025), while ASI (Wang et al., 2025) 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 of E VO SOP in this study.

Case Study

To better understand the optimization process, we analyze a representative execution of E VO SOP on ACEBench. We track the utilization and performance metrics of selected SOPs to illustrate how E VO SOP distinguishes between high-utility, highrisk, and redundant tools. As shown in Figure 4, we observe some distinct lifetime patterns: (i) Fundamental SOPs: Tools like fetch_ message exhibit 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_message is synthesized during Epoch 1 but immediately evicted by the R EVIEWER due to a critical failure rate. This demonstrates the framework’s ability to prevent unreliable code from polluting the toolset. Similarly, retrieve_flight_details is pruned after several epochs because its marginal utility is low, it is rarely invoked, and introduces non-negligible reasoning overhead without a pro-

6

Conclusions

In this study, we propose E VO SOP, a novel framework designed to empower LLM-based agents to self-evolve through iterative tool optimization. By synthesizing granular atomic actions into highlevel and reusable SOPs, E VO SOP boosts 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, 8

our framework establishes a continuous optimization lifecycle, effectively mitigating the risks of logic fragmentation and toolset bloating. Extensive experiments on ACEBench and Tau2Bench demonstrate that E VO SOP significantly enhances task success rates while reducing the number of reasoning rounds across diverse benchmarks.

9

References

and feedback learning. In Proceedings of the 31st International Conference on Computational Linguistics, COLING 2025, Abu Dhabi, UAE, January 19-24, 2025, pages 9760–9779.

Yifan Bai, Yiping Bao, Guanduo Chen, Jiahao Chen, Ningxin Chen, Ruijue Chen, Yanru Chen, Yuankun Chen, Yutian Chen, Zhuofu Chen, Jialei Cui, Hao Ding, Mengnan Dong, Angang Du, Chenzhuang Du, Dikang Du, Yulun Du, and 1 others. 2025. Kimi K2: open agentic intelligence. CoRR, abs/2507.20534.

Marianne Menglin Liu, Daniel Garcia, Fjona Parllaku, Vikas Upadhyay, Syed Fahad Allam Shah, and Dan Roth. 2025. Toolscope: Enhancing LLM agent tool use through tool merging and context-aware filtering. CoRR, abs/2510.20036.

Victor Barres, Honghua Dong, Soham Ray, Xujie Si, and Karthik Narasimhan. 2025. τ 2 -bench: Evaluating conversational agents in a dual-control environment. CoRR, abs/2506.07982.

Bohan Lyu, Xin Cong, Heyang Yu, Pan Yang, Yujia Qin, Yining Ye, Yaxi Lu, Zhong Zhang, Yukun Yan, Yankai Lin, Zhiyuan Liu, and Maosong Sun. 2023. Gitagent: Facilitating autonomous agent with github by tool extension. CoRR, abs/2312.17294.

Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, and 2 others. 2020. Language models are few-shot learners. In Advances in Neural Information Processing Systems 33: Annual Conference on Neural Information Processing Systems 2020, NeurIPS 2020, December 6-12, 2020, virtual.

Grégoire Mialon, Clémentine Fourrier, Thomas Wolf, Yann LeCun, and Thomas Scialom. 2024. GAIA: a benchmark for general AI assistants. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. Zhuoshi Pan, Qizhi Pei, Yu Li, Qiyao Sun, Zinan Tang, H. Vicky Zhao, Conghui He, and Lijun Wu. 2025. REST: stress testing large reasoning models by asking multiple problems at once. CoRR, abs/2507.10541.

Chen Chen, Xinlong Hao, Weiwen Liu, Xu Huang, Xingshan Zeng, Shuai Yu, Dexun Li, Shuai Wang, Weinan Gan, Yuefeng Huang, Wulong Liu, Xinzhi Wang, Defu Lian, Baoqun Yin, Yasheng Wang, and Wu Liu. 2025. Acebench: Who wins the match point in tool learning? CoRR, abs/2501.12851.

Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu, and Maosong Sun. 2024. Toolllm: Facilitating large language models to master 16000+ real-world apis. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024.

Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Pondé de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, and 4 others. 2021. Evaluating large language models trained on code. CoRR, abs/2107.03374.

Jiahao Qiu, Xuan Qi, Tongcheng Zhang, Xinzhe Juan, Jiacheng Guo, Yifu Lu, Yimin Wang, Zixin Yao, Qihan Ren, Xun Jiang, Xing Zhou, Dongrui Liu, Ling Yang, Yue Wu, Kaixuan Huang, Shilong Liu, Hongru Wang, and Mengdi Wang. 2025. Alita: Generalist agent enabling scalable agentic reasoning with minimal predefinition and maximal self-evolution. CoRR, abs/2505.20286.

Francesco Fabiano, Marianna Bergamaschi Ganapini, Andrea Loreggia, Nicholas Mattei, Keerthiram Murugesan, Vishal Pallagani, Francesca Rossi, Biplav Srivastava, and K. Brent Venable. 2025. Thinking fast and slow in human and machine intelligence. Commun. ACM, 68(8):72–79.

Changle Qu, Sunhao Dai, Xiaochi Wei, Hengyi Cai, Shuaiqiang Wang, Dawei Yin, Jun Xu, and Ji-Rong Wen. 2025. From exploration to mastery: Enabling llms to master tools via self-driven interactions. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025.

Huan-ang Gao, Jiayi Geng, Wenyue Hua, Mengkang Hu, Xinzhe Juan, Hongzhang Liu, Shilong Liu, Jiahao Qiu, Xuan Qi, Yiran Wu, Hongru Wang, Han Xiao, Yuhang Zhou, Shaokun Zhang, Jiayi Zhang, Jinyu Xiang, Yixiong Fang, Qiwen Zhao, Dongrui Liu, and 8 others. 2025. A survey of self-evolving agents: On path to artificial super intelligence. CoRR, abs/2507.21046.

Colin Raffel, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter J. Liu. 2020. Exploring the limits of transfer learning with a unified text-to-text transformer. J. Mach. Learn. Res., 21:140:1–140:67.

Xiaoxi Li, Wenxiang Jiao, Jiarui Jin, Guanting Dong, Jiajie Jin, Yinuo Wang, Hao Wang, Yutao Zhu, Ji-Rong Wen, Yuan Lu, and Zhicheng Dou. 2025. Deepagent: A general reasoning agent with scalable toolsets. CoRR, abs/2510.21618.

Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timothée Lacroix, Baptiste Rozière, Naman Goyal, Eric Hambro, Faisal Azhar, Aurélien Rodriguez, Armand Joulin, Edouard

Xinzhe Li. 2025. A review of prominent paradigms for llm-based agents: Tool use, planning (including rag),

10

Algorithm 1 EvoSOP training workflow

Grave, and Guillaume Lample. 2023. Llama: Open and efficient foundation language models. CoRR, abs/2302.13971.

Input: execution log set ξ, atomic tool set F, training set index Itrain , batched index set B Built in: max iterations M , LLM-based function f· (·), verification module gverify (·) Initialize S = ϕ, R = ϕ for i = 0 to M − 1 do if i < len(B) then SBi = ϕ for j in Bi do SBi = SBi ∪ frewrite (fextract (ξj ), F) end for end if S = S ∪ SBi ∪ fmerge (S ∪ SBi ) F ′ = F ∪ {fschema (s)|s ∈ S} ξb = gverify (F ′ ) for j in Itrain do R = R ⊕ freview (ξbi , S) end for for s in S do if Rs exists and fcheck (Rs )==“remove” then R = R \ Rs S =S \s end if end for save S, R end for

Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. 2023. Voyager: An openended embodied agent with large language models. Preprint, arXiv:2305.16291. Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, and Heng Ji. 2024. Executable code actions elicit better LLM agents. In Fortyfirst International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024. Zora Zhiruo Wang, Apurva Gandhi, Graham Neubig, and Daniel Fried. 2025. Inducing programmatic skills for agentic tasks. CoRR, abs/2504.06821. Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R. Narasimhan, and Yuan Cao. 2023. React: Synergizing reasoning and acting in language models. In The Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023. Lifan Yuan, Yangyi Chen, Xingyao Wang, Yi Fung, Hao Peng, and Heng Ji. 2024. CRAFT: customizing llms by creating and retrieving from specialized toolsets. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. Siyu Yuan, Kaitao Song, Jiangjie Chen, Xu Tan, Yongliang Shen, Kan Ren, Dongsheng Li, and Deqing Yang. 2025. EASYTOOL: enhancing llm-based agents with concise tool instruction. In Proceedings 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, pages 951–972.

A

Pseudo-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 function fmerge takes as input the union of the SOP set maintained from previous iterations and the SOPs newly generated in the current iteration. • Bi denotes the i-th mini-batch in the index set B, corresponding to b. • S represents the dynamically generated and pruned SOP set, which eventually becomes the solidified SOP set Ssolid .

11

B

Detailed Experimental Settings and Configurations

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 set max_steps to 100, and we set max_beam_size of DFSDT to 3. For the two tool-related methods, ASI and DRAFT, 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 are the average success rates ± standard errors across runs. All of the used artifacts including benchmarks and code bases are consistent with their intended use.

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 the Agent-Multi-Step and Agent-Multi-Turn subsets 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.

Backbone models. To ensure a fair comparison within our experiments, we consistently use GPT-4o as 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 with Gemini-3-Flash-Preview or Qwen-Max as the backbone model. For the core algorithms of ASI, DRAFT, and EvoSOP, we adopt GPT-4o, Gemini-3-Flash-Preview, and Qwen-Max to 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.

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 wellknown method, DFSDT (Qin et al., 2024), 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, when max_beam_size is set to 1, DFSDT effectively degenerates into a ReAct agent with the additional option of giving up. DFSDT dumps and restores

C

Toolset 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 summarizes the macro evolution of the toolset’s composition. During the initial phase (Epochs 1 to 5), the toolset size undergoes rapid expansion as the C ONSTRUCTOR 12

40 30 Counts

Your primary purpose is to summarize and ,→ extract the given workflows, induce ,→ reusable and meaningful consecutive ,→ `tool_call`s as an SOP. There possibly contains more than one SOPs, or ,→ no SOP. Rewrite the SOPs which you think ,→ that satisfy the following rules, possibly ,→ multiple, one, or none.

Constructed SOPs Involved SOPs Maintained SOPs

20 10 0

0

2

4

Epochs

6

8

10

### Operating Paradigm You are given an action trajectory of a ,→ completed task containing `tool_call`s only, ,→ in the form of .json, the given arguments, ,→ and the name of that specific tool. Some `tool_call`s have identifiable features ,→ which indicates that their functionality ,→ may have strong inter connections for ,→ combining them as an SOP. Your paradigm of inducing SOPs are listed as ,→ follows: 1. **Consecutive `tool_call`**: This indicates ,→ that the `tool_call`s are executed ,→ consecutively. 2. **Separated `tool_call` Message Number**: ,→ This indicates that the `tool_call` are ,→ closely connected, but not executed ,→ consecutively. For example, `tool_call` A ,→ write down a python file, and encounters ,→ some error with consecutive `tool_call` B, ,→ but `tool_call` C is more general and ,→ successfully runs A without errors. 3. **Similar `tool_call` Results and Following Input Argument**: This indicates that two ,→ `tool_call`s are strongly connected, as the ,→ result of one `tool_call` is immediately ,→ used in another one's input. ,→ 4. **Meaningful Combination**: Some consecutive `tool_call`s combination are of great ,→ reality meanings, as `search` plusing ,→ `write_file` means search something and ,→ directly write this to some designated ,→ file. ,→ 5. **Frequently Usage**: Some consecutive ,→ `tool_call`s combination are of frequent ,→ occurrence, which implys that they can be ,→ modularized.

Figure 5: Trends of constructed, involved, and maintained SOPs across training epochs in ACEBench.

explores 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, E VO SOP maintains 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.

D

Prompt Engineering in E VO SOP

In this section, we summarize our promptengineering strategies used to implement the proposed LLM-based modules, namely C ONSTRUC TOR , M ERGER , and R EVIEWER . 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 two C ONSTRUCTOR functionalities, 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 in C ONSTRUCTOR.

### Important Constraints and Hints 1. As is stated above, the **consecutive** ,→ `tool_call` means the they should be ,→ executed as close as possible. Do not ,→ induce `tool_call`s too far, making the ,→ span too big. 2. The tools in induced SOP should have strong ,→ inter connection. You should carefully ,→ check the connection between `tool_call`s ,→ by examining the `tool_call` arguments and ,→ results. DO NOT INTEGRATE IRRELEVANT TOOL ,→ COMBINATIONS TO COMPLICATE THE RESULT. 3. The induced SOP should containing **at ,→ least** 2 `tool_call` actions to make the ,→ induced SOP be concise and not too simple. 4. The induced SOP should containing **no more ,→ than** 5 `tool_call` actions to make the ,→ induced SOP be general and scalable to be ,→ applied to other similar tasks. 5. Consecutive file operations have a higher ,→ probability of being combined together. You ,→ may need to consider deeper about the ,→ returned value of some `tool_call`, for the ,→ input parameters of the next `tool_call`.

## Identity You are a specialized agent who is good at text ,→ extraction and analyzing. You are designed ,→ to summarize and extract some reusable and ,→ meaningful consecutive `tool_call`s from ,→ the provided action trajectories, forming a ,→ Standard Operation Process (SOP). ## Core Mission.

13

6. Focus more on the workflow revealed by the ,→ logs. Do not care too much about the content ,→ in 'text' field if it is extremely long. 7. Except the required output in the following ,→ output guidance, DO NOT OUTPUT ANYTHING ,→ ELSE.

### Example

1. Consecutive file operations have a higher ,→ probability of being combined together. You ,→ may need to process the returned value of ,→ some `tool_call`, for the input parameters ,→ of the next `tool_call`. 2. Focus more on the workflow revealed by the ,→ logs. Do not care too much about the content ,→ in 'text' field with repeated patterns. 3. Pay special attention to the docstrings of ,→ the input parameters of the `tool_call`s ,→ components, and reveal any special pattern ,→ if the input parameters are directly passed ,→ to these `tool_call`s. 4. You should include all of the used ,→ `tool_call` names (in order if possible) in ,→ the docstring. 5. Except the code, DO NOT OUTPUT ANY OTHER ,→ THINGS.

**Example Input:**

## Output Function Guidance

{example_trajectory}

{function_guidance}

**Example Output**

## Input Logs The following contents are the input messages ,→ for you to process.

## Output Guidance The output should just be a serialized python ,→ list object. The list object may contain one valuable ,→ induced SOP, and the SOP should also be a ,→ list, containing the corresponding ,→ `message_number` in the `tool_call` logs. If you think there is not valuable combination, ,→ output an empty list.

{example_tool_call_ids}

{trajectories}

## Input Logs The following contents are the input logs for ,→ you to process. Try your best to finish ,→ your task.

The following contents are the docstrings of ,→ all the involved `tool_call`s. {tool_docstrings}

The following code block shows the prompt of SOP functionalization in C ONSTRUTOR. The “function_guidance” should be a guidance and limitation of constructing SOPs, which could vary among different environments and datasets.

E

An example of the synthesized SOP

In this section, we provide the source code of a representative SOP generated by E VO SOP. 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.

## Identity You are a specialized agent who is good at ,→ software engineering. You are designed to ,→ rewrite the consecutive `tool_call`s to a ,→ standard operating procecure (SOP) from the ,→ provided action trajectories. ## Core Mission Your primary purpose is to extract the current ,→ workflows, induce the `tool_call`s in the ,→ given logs to a well-bounded SOP, and ,→ rewrite the induced SOP in the form of a ,→ new tool function for future usage. ### Operation Paradigm You are given an action trajectory of a ,→ completed task containing `tool_call`s ,→ only, in the form of .json, with the ,→ message number, the given arguments, and ,→ the name of that specific tool. You are also given the docstring of all the ,→ involved `tool_call`s, which will help you ,→ conclude some implicit requirements or ,→ restraints about the tool function. ### Important Constraints and Hints

14

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

import traceback from typing import Any, Dict def send_message_workflow(self, message: str, receiver_name: str, sender_name: str) -> Dict[str, ,→ Any]: """ This function performs the following steps: 1. Attempts to send a message from one user to another. 2. If sending fails due to memory issues, it retrieves the latest message ID. 3. Deletes the latest message based on its ID. 4. Retries sending the message. Args: self: Instance of the current class. message (str): The message content to send. receiver_name (str): Name of the receiver. sender_name (str): Name of the sender. Returns: dict: A dictionary containing: - "status" (bool): True if the operation succeeds, False otherwise. - "content" (dict): Contains results of message sending, and deletion if applicable. - "send_status_initial": Result of the first send attempt. - "latest_message_id": ID of the latest message retrieved (optional). - "delete_status": Result of the delete operation (optional). - "send_status_final": Result of the retry send operation. """ try: # Step 1: Attempt to send the message initially send_result_initial = self.send_message(message=message, receiver_name=receiver_name, ,→ sender_name=sender_name) # Check if sending failed due to memory issues if not send_result_initial['status']: # Step 2: Retrieve the latest message ID latest_message_result = self.get_latest_message_id() latest_message_id = latest_message_result.get('message_id') # Step 3: Delete the latest message based on its ID delete_result = self.delete_message(message_id=latest_message_id) # Step 4: Retry sending the message send_result_final = self.send_message(message=message, receiver_name=receiver_name, ,→ sender_name=sender_name) return { "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 } } # Message was sent successfully in the first attempt return { "status": send_result_initial['status'], "content": { "send_status_initial": send_result_initial } } except Exception as e: return { "status": False, "content": { "error": str(e), "traceback": traceback.format_exc() } }

15