Agent Self-Evolution · Tool Optimization

From repetition,
better tools.

Most LLM agents carry a fixed toolkit from first run to last, re-deriving the same multi-step sequences each time. This paper builds the system that notices the patterns and promotes them into callable, reusable tools.

Core concept
SOP tools: higher-order callable tools mined from recurring sequences in an agent's own successful trajectories, managed through a construction-execution-optimization lifecycle that mirrors ML training.
scroll to explore
01The problem

Every run, the
same derivation.

Atomic tool calls are clean, debuggable, and composable. They are also repetitive in ways that cost reasoning budget and introduce failure paths the agent re-navigates from scratch on every run.

First surfaced in Tandemly Briefing — 2026-07-10.

A tool-using LLM agent has a toolkit: a set of callable functions with defined signatures. Each run, it reads a task, reasons about which tools to call and in what order, executes the sequence, and returns a result. The approach is flexible. It is also wasteful in a specific way.

If the same five-step sequence appears in most successful runs for a given task type, the agent re-derives it each time. It re-decides the order, re-handles the intermediate outputs, re-manages the chain. If the reasoning goes slightly wrong at step three, the task fails. If the sequence is long enough, the model loses track of where it is.

Standard responses to this problem fall into two camps. The first is hardcoded composite tools: a human notices the recurring pattern and writes a wrapper. That works, but it requires a human to identify the pattern and it produces a static library that does not evolve as tasks change. The second is better memory: context caching, vector stores, long-context windows. That preserves the information but does not shorten the reasoning chain. The agent still navigates the full sequence on every run.

Ding and colleagues from Renmin University of China and Alibaba Group ask a different question. What if the agent could do what the human engineer does: watch the successful runs, notice the recurring sequences, and promote them into first-class callable tools?

The question this paper asks

Can an LLM agent systematically mine its own successful trajectories, extract the recurring multi-step sequences, promote them into callable higher-order tools, and manage that tool library through a structured optimization cycle? And if so, does it help?

02The approach

Three phases,
one lifecycle.

The paper draws an explicit parallel to ML training. The SOP tool lifecycle maps cleanly onto construction as data collection, execution as the forward pass, and optimization as the backward pass.

The core mechanism is a three-phase cycle that runs on top of a standard tool-using agent. The agent itself does not change in the first phase. It runs its tasks using its existing atomic toolkit, and at the end of each successful run, a separate mining step inspects the trajectory.

The mining step looks for multi-step sequences that appear repeatedly across runs. When a sequence crosses a frequency threshold, it becomes a SOP tool candidate: a named, callable wrapper that encapsulates the full sequence behind a single function call with a clean signature.

C
Construction (data collection)
The agent runs tasks with its current atomic toolkit. After each successful run, a trajectory mining step identifies recurring multi-step sequences and nominates them as SOP tool candidates. Frequency thresholds control which sequences get promoted.
E
Execution (forward pass)
Admitted SOP tools are registered in the agent's toolkit. On subsequent runs, the agent can invoke the SOP tool as a single action rather than re-deriving and executing the underlying sequence step by step. The agent reasons over a smaller, higher-level action space.
O
Optimization (backward pass)
After a batch of runs with the updated toolkit, a merge-evaluate-prune cycle runs. Tools with overlapping behavior are merged. Tools that underperform on a held-out task sample are retired. The library is kept bounded and current.
Why the ML training parallel matters

The analogy is not decorative. It identifies where each component sits in the system and what it is responsible for. Construction collects the data that informs what tools are worth building. Execution applies the current best knowledge to new tasks. Optimization updates the knowledge based on what execution reveals. Each phase has a different feedback signal and a different cadence, and conflating them creates architectural problems the paper is trying to avoid.

The admission step matters separately. A SOP tool promoted from a flawed trajectory embeds the failure path into the toolkit, where it can surface in future runs as an apparently valid option. The paper gates each candidate behind a unit test before registration, a pattern borrowed from software engineering rather than ML. Passing the test is a precondition for admission, not a quality signal after the fact.

03Findings & benchmarks

Better tasks,
fewer rounds.

Evaluated on ACEBench, a benchmark for coding and reasoning agent tasks, across multiple backbone models. Task success improved across all tested backbones, and agents reached correct solutions in fewer interaction rounds.

Best backbone improvement
13.4
percentage points on ACEBench
Minimum backbone improvement
2.5
percentage points on ACEBench
Lifecycle phases
3
construction · execution · optimization
Finding 1: Gains are consistent across backbone models

The task success improvement ranges from 2.5 to 13.4 percentage points across the backbone models tested, but the direction is consistent. The SOP tool lifecycle adds value whether the base model is strong or weak. This matters because it suggests the gain comes from the toolset structure, not from the model learning new capabilities.

Finding 2: Agents reach solutions in fewer interaction rounds

Beyond task success rate, the paper reports a reduction in interaction rounds per task. When the agent can invoke a SOP tool in a single action, it no longer spends reasoning tokens re-navigating the underlying sequence. The shorter action trace also reduces the surface for intermediate errors, which is a different benefit from the accuracy gain and one that compounds over longer task horizons.

Finding 3: The approach is distinct from the harness-effect and skill-routing clusters

The paper is careful to position this work relative to existing agent research. Harness-effect studies show that the scaffolding around a model matters as much as the model. Skill-routing research addresses how agents select from a fixed set of skills. The SOP tool lifecycle addresses something earlier: the composition and lifecycle of the toolset itself. The toolset is not fixed. It evolves as the agent encounters more tasks.

Scope and limitations

The evaluation is on ACEBench, a structured agent benchmark. Real production tasks tend to have more varied structure, noisier trajectories, and harder-to-define success criteria. The frequency thresholds for SOP promotion and the unit-test admission requirement are design choices whose sensitivity is not fully explored in the paper. Teams adopting the pattern should calibrate these against their own task distributions before treating the ACEBench gains as a deployment estimate.

04Practical takeaways

What builders
can do with this.

The SOP tool pattern is an architectural intervention, not a model change. It can be layered on top of any tool-using agent that logs its own trajectories.

1
Log every successful trajectory, not just task outcomes
The value in the SOP approach comes from finding repeated sequences within trajectories. A record that captures only the final result discards exactly the information needed for mining. Store (task_id, step_index, tool_name, args) at minimum. Successful trajectories only: failed runs introduce sequences that do not generalize.
2
Gate admission behind a unit test, not just a frequency threshold
A sequence that appears often in successful runs is not necessarily a good SOP tool. It might be frequent because the agent keeps working around a limitation rather than solving the task directly. Write a test that exercises the candidate tool on at least one held-out task sample before registering it. A tool that fails its unit test should not enter the toolkit regardless of its frequency count.
3
Run the optimization cycle periodically, not after every run
The merge-evaluate-prune cycle is a batch operation. Running it after every task adds overhead and creates instability: the toolkit changes too frequently for the agent to build reliable expectations about what tools are available. Batch it at natural intervals: after a fixed number of new tasks, or on a regular schedule that matches your task volume.
4
Measure rounds-per-task as a separate signal from task success
The paper reports both task success rate and interaction round count. In production, these can diverge. An agent might reach the correct answer in more steps using atomic tools, or fewer steps using SOP tools, while holding task success constant. Tracking both lets you separate the accuracy benefit (are tasks succeeding that were failing before?) from the efficiency benefit (are successful tasks getting cheaper?)
5
The toolset lifecycle is a governance surface, not just a performance lever
A SOP tool is code. It encapsulates assumptions about the task, the environment, and the acceptable action sequence. Over time, those assumptions can drift out of date as APIs change or task distributions shift. The prune step handles underperforming tools, but a tool might perform well on benchmark tasks while encoding an unsafe or outdated pattern. Treat the SOP library as a governed artifact with the same review cadence as any other production code that affects external state.
05Further exploration

Where to go
from here.

Starting points for teams interested in implementing the SOP tool pattern in their own agent stacks.

1
Read the paper
Ding, Xie, Wei, Li and Ding. From Atomic Actions to Standard Operating Procedures: Iterative Tool Optimization for Self-Evolving LLM Agents. Renmin University of China and Alibaba Group. arXiv:2607.07321.
2
Start with a trajectory logger
Before building the SOP promotion pipeline, instrument your agent to log tool call sequences on every successful run. A structured JSON record (task_id, run_id, step_index, tool_name, args, result_ok) is enough to run sequence frequency analysis offline. Build the logger first, collect a week of runs, then decide which n-gram lengths are worth mining.
3
Read the related work on self-evolving agent toolsets
MUSE-Autoskill (Lin et al., 2026) covers a similar terrain from the skill-lifecycle perspective, treating skills as the primary unit of agent capability with creation, memory, organization, and evaluation components. The contrast is instructive: MUSE-Autoskill starts from skill creation on demand; the SOP approach mines sequences from completed trajectories. Both are worth reading together.
4
Run a head-to-head comparison before committing
Same task distribution, same backbone model, same evaluation harness, with and without SOP tools. Measure task success rate and rounds-per-task in both conditions. The ACEBench numbers are a prior, not a guarantee. Your task distribution may have sparser trajectory overlap (making mining harder) or denser overlap (making it more powerful). The head-to-head tells you which regime you are in.
5
Consider the governance angle early
If your agent operates on external systems (APIs, databases, communication tools), each SOP tool encapsulates a sequence of writes. Review the admission and prune criteria with the same attention you would give any code that reaches production external state. The patterns that emerge as high-frequency may include aggressive sequences that work most of the time but carry edge-case risk. A code review of candidate SOP tools before registration is not overhead: it is the safeguard that makes the lifecycle safe to run.