The Evolution of Tool Use in LLM Agents: From Single-Tool Call to Multi-Tool Orchestration

1 Introduction

• Multi-tool tasks require coupled decisions about tool selection, dependencies, scheduling, recovery, and replanning, with state consistency and race conditions becoming bottlenecks in long-horizon write operations.The research objective therefore shifts from single-call correctness to end-to-end executability and robustness in complex environments.Source: §1 · p. 2

1.1 Aims and Motivations

• The survey addresses conceptual confusion among tool-use terms and the separate treatment of planning, training, safety, efficiency, benchmarking, and open-environment adaptation.It reviews inference-time reasoning, trajectory construction, safety, operational efficiency, incomplete environments, and system-level evaluation.Source: §1.1 · p. 2, §1 · p. 2

1.2 Related Work

• Unlike broader tool-use and agent surveys, this work centers multi-tool orchestration, connects six research dimensions, and distinguishes invocation, retrieval, orchestration, and toolset expansion.It relates methodological progress to the shift from call-level correctness toward system-level reliability in benchmarks and applications.Source: §1.2 · p. 3, Figure 1 · p. 3

2 Problem formulation

• A multi-tool learning instance includes a task, an interactive environment with latent state and observations, and an inventory of tools described by schemas.A tool execution interface accepts valid arguments and returns feedback alongside the post-call environment state.Source: §2 · p. 3
• The interaction history accumulates actions, feedback, and observations, while a trajectory records tool-action and feedback pairs ending in Finish.The objective captures long-horizon scheduling, failure recovery, and replanning under tool and environment feedback, with λ trading off success against cost.Source: §2 · pp. 4–5
• At each step, the policy selects either a tool call with valid parameters or a Finish action that returns the final answer, conditioned on history and memory.The tool call produces feedback and a state transition that can inform subsequent decisions.Source: §2 · pp. 4–5

3.1 Topological Planning

• Linear ReAct traces fit simple retrieval but mismatch nested calls, parallel operations, and long-horizon goals because they constrain dependencies and let early errors accumulate.Topology-aware planning represents workflows with graphs or AND/OR structures, while hierarchical planners and search methods support decomposition, replanning, and verification before commitment.Source: §3.1 · pp. 5–6

3.2 Long-Horizon Orchestration

• Long-horizon orchestration distributes work across specialized reasoning, execution, and routing components, while procedural memory helps avoid relying on one transient context window.Systems use compact progress summaries and structured or typed memories to retain decision-relevant history while suppressing noise and outdated branches.Source: §3.2 · pp. 6–7

3.3 Agent Self-Improvement

• Self-improvement methods diagnose and revise trajectories during or after execution to address misbound parameters, invalid assumptions, and ineffective recovery.Approaches include reflection and repair as well as continual improvement through memory and planning repair.Source: §3.3 · p. 7
• Capability evolution methods distill experience into reusable tools or knowledge, synthesize and validate tools during inference, or revise tool descriptions and memory interfaces from feedback.These approaches treat inference as an adaptive loop that can reorganize and improve the tool ecosystem while solving tasks.Source: §3.3 · p. 7

4 Multi-Tool Agent Tuning Paradigms

• Tuning spans four approaches, ordered by computational overhead and data dependency: training-free methods, trajectory synthesis, SFT, and RL.The taxonomy moves from activating tool use without parameter updates toward using environmental feedback for agent adaptation.Source: §4 · p. 7

4.1 Training-free Methods

• Training-free methods improve tool use without updating model parameters, using retrieval, prompting, and non-parametric memory.Examples include retrieving relevant tool descriptions, generating instructions and exemplars, and reusing successful trajectories.Source: §4.1 · pp. 7–8

4.2 Multi-tool trajectory Data Synthesis

• Synthetic trajectory development has shifted toward a synthesis-validation-expansion framework that targets compositional coverage, execution quality, and error recovery.Approaches construct structured traces, verify syntax, execution, and semantics, and expand coverage to long-tail interactions and multi-step errors.Source: §4.2 · pp. 8–9

4.3 Supervised Fine-Tuning

• SFT has moved beyond syntax and API-call imitation toward specialized training for large-scale tool selection, dependency planning, and execution control.Methods include search trajectories, function masking, staged reasoning and tool output, joint retrieval and parameter generation, and fine-grained task decomposition.Source: §4.3 · p. 9

4.4 Reinforcement Learning

• Because SFT can leave agents reliant on training trajectories, RL methods use environmental feedback to address long-horizon decision-making and error recovery.Work targets sparse rewards and credit assignment, adapts policy optimization, and develops end-to-end frameworks, including RL from a base model without prerequisite SFT.Source: §4.4 · p. 10

5 Safety of Multi-Tool Agents

• Multi-tool security depends on cross-tool and cross-timestep execution structures, which can propagate localized malicious inputs or hallucinations through tool-chain state.The review distinguishes risks in parallel execution from those in long-horizon chains.Source: §5 · p. 11

5.1 Security Risks in Parallel Execution

• Concurrent write operations can cause race conditions and state inconsistencies, while interdependent calls can propagate malicious payloads across tool boundaries.The cited work motivates explicit control over side effects and execution scope.Source: §5.1 · p. 11
• Parallel-execution defenses progress from pre-execution constraints to transactional workflows with rollback and post-execution verification.Examples include intercepting conflicting actions, bounded workflows with compensation, and verifier-executor or graph-embedded verification.Source: §5.1 · pp. 11–12

5.2 Security Risks in Long-Horizon Tool Chains

• Long-horizon chains are vulnerable to agent drift and cross-tool state contamination as intermediate variables and reused malicious data can carry errors downstream.Attacks include memory poisoning, plan injection, and amplification of small upstream deviations through variable binding and parameter reuse.Source: §5.2 · p. 12
• Long-horizon defenses increasingly use execution-grounded trajectory checks, rollback, root-cause diagnosis, and interventions before unsafe actions.Training approaches also use sandboxed reinforcement learning, episodic memory consolidation, and adversarial tool chains for alignment.Source: §5.2 · p. 13

• Multi-step inference and sequential tool invocation create efficiency bottlenecks, motivating work on latency in tool chains and tool-call cost and inference budgets.Source: §6 · p. 13

6.1 Latency in multi-tool chains

• Latency can accumulate linearly or even exponentially with task steps when each LLM inference waits for prior tool results.Source: §6.1 · p. 13

6.1.1 Parallel execution.

• Parallel execution runs independent subtasks concurrently, with effectiveness depending on explicit dependencies and controlled side effects.Examples include dependency planning for concurrent calls and overlapping planning with execution.Source: §6.1.1 · p. 13

6.1.2 Asynchronous decoupling.

• Asynchronous decoupling separates inference planning from I/O-intensive tool execution to improve concurrent throughput and reduce latency from environmental changes.Some systems synchronize state asynchronously or separate planning from external verification.Source: §6.1.2 · p. 14

6.1.3 Speculative reasoning.

• Speculative reasoning predicts later actions or tool outcomes before observations arrive, then commits execution when speculation is correct.Methods include generating execution graphs, lookahead over trajectories, and speculative routing of tool requests.Source: §6.1.3 · p. 14

6.2 Tool call cost and inference budget

• The section organizes cost reduction around dynamic tool retrieval, adaptive model routing, and intelligent caching and memory.These target context overhead, compute allocation, and repeated interactions, respectively.Source: §6.2 · pp. 14–15

6.2.1 Dynamic tool search.

• Top-K retrieval, hierarchical filtering, and ToolkenGPT’s special-token representation reduce irrelevant context or lengthy tool descriptions.ToolLLM retrieves relevant descriptions, AnyTool progressively filters large API libraries, and ToolkenGPT maps invocation logic to a token.Source: §6.2.1 · p. 15

6.2.2 Adaptive Model Routing.

• Model cascading and adaptive routing reserve more expensive models for requests whose difficulty or confidence warrants them.SwiftSage assigns routine operations to lightweight edge modules and complex inference to a central large model.Source: §6.2.2 · p. 15

6.2.3 Intelligent caching and memory.

• Agent memory, virtual-memory paging, and semantic caching target repeated errors, long-task memory limits, and duplicate API requests.Reflexion stores failure-derived strategies; MemGPT pages between context and an external database; GPTCache reuses results for semantically similar requests.Source: §6.2.3 · p. 15

7 Completeness

• Functional completeness is framed as a continual cycle of boundary perception, tool expansion, and open-environment adaptation.The stages diagnose gaps, compensate for them, and preserve successful tools or interaction traces for later use.Source: §7 · p. 16

7.1 Capability boundary perception

• Capability-boundary perception addresses missing tools, ambiguous intent, and parameter anomalies through clarification or safe termination.FAIL-TALMS and ToolHaystack describe boundary-awareness and parameter-hallucination problems; AskToAct clarifies missing parameters, while termination mechanisms can abort uncertain or high-risk execution.Source: §7.1 · pp. 16–17

7.2 Autonomous tool expansion

• Autonomous tool expansion fills capability gaps by generating verified tools or composing existing APIs into higher-level skills.LATM separates tool creators from users and verifies generated Python functions; RestGPT connects REST APIs, while ToolMaker can reuse synthesized tools within the current context.Source: §7.2 · p. 17

7.3 Open environment adaptation

• Open-environment adaptation stores successful tools, call traces, or learned skills as reusable experience as interfaces and tool libraries change.Voyager builds a skill library, ExpeL extracts cross-task insights from successful and failed traces, ToolkenGPT adapts tool-token embeddings, and AppAgent updates app interaction memory.Source: §7.3 · pp. 17–18

8 Benchmarks

• Long-horizon evaluation spans dependency topology, temporal scale, environmental dynamism, and state persistence with self-correction.The survey contrasts system-level trajectory capabilities with earlier emphasis on intent detection and tool retrieval.Source: §8 · p. 18

8.1 Topological Complexity

• Benchmarks probe whether agents can construct dependency graphs for nested, branching, parallel, or distributed tool calls rather than follow linear scripts.They assess execution order, intermediate-output transfer, and dependencies distributed across stages, modalities, or speakers.Source: §8.1 · p. 18

8.2 Temporal Scale

• Benchmarks report steep degradation as trajectory horizons and global constraints increase.UltraHorizon averages 400+ tool calls and 200K+ tokens; TRIP-Bench uses travel dialogues exceeding 150 tool invocations with budget and time constraints.Source: §8.2 · pp. 19–20

8.3 Dynamic Environments

• Dynamic-environment benchmarks test state changes, interruptions, API reproducibility, user corrections, and real-world interface variability.ToolSandbox changes state through intermediate outputs, ToolGym injects interruptions, and human-in-the-loop benchmarks test evolving instructions and corrections.Source: §8.3 · p. 20

8.4 State Persistence and Self-Correction

• State-persistence and recovery evaluations examine whether agents maintain intermediate resources, detect inconsistencies, and continue after partial failure.The survey argues that evaluation should expose intermediate signals and distinguish robust orchestration from accidental endpoint success.Source: §8.4 · p. 21

9.1 A Unified Abstraction for Application-Side Multi-Tool Orchestration

• Application-side orchestration is framed as closed-loop execution toward a target state, with intermediate and final outcomes requiring verification.The framework considers heterogeneous environments, orchestration topologies, and operational constraints; visual action grounding is described as a key execution bottleneck in GUI settings.Source: §9.1 · p. 21, Figure 5 · p. 22
• Extended tool chains face engineering constraints in state management, parameter binding, process supervision, security, and standardized integration.The chapter emphasizes invocation-path correctness and preventing unauthorized access while preserving task completion.Source: §9.1 · p. 22

9.2 Orchestration Paradigms in Representative Interactive Environments

• Application domains differ chiefly in operational bottlenecks, including visual grounding, deterministic test verification, transactional consistency, and safe cross-app coordination.The chapter relates GUI volatility and latency, software test costs, enterprise audit and permission needs, and mobile misoperation risks to different execution demands.Source: §9.2 · p. 23

9.3 Engineering Essentials and Governance for Industrial-Grade Multi-Tool Orchestration

• Industrial deployment calls for tool governance, auditable access controls, intermediate verification, observability, and joint quality-time-cost optimization.The chapter discusses interface virtualization and regression validation, policy layers, checkpoints, and budget-aware routing.Source: §9.3 · pp. 23–24

9.4 Open Problems and Future Directions

• Open challenges include adapting to interface evolution, making long-horizon execution verifiable without prohibitive efficiency loss, optimizing cost, latency, and quality, and improving recovery.The proposed research agenda centers on evolvable tool governance, verifiable closed-loop execution, and adaptive orchestration.Source: §9.4 · p. 24

10 Conclusion

• Multi-tool agents must plan under dependencies, manage mutable state, control execution, and preserve correctness amid uncertainty, latency, and safety constraints.The problem extends beyond prompting or API formatting.Source: §10 · p. 24
• The survey reviews multi-tool agents across inference-time planning, training, safety, efficiency, capability completeness, benchmarks, and applications.Source: §10 · p. 24
• These dimensions are tightly connected: planning interacts with state management and verifiability, safety with execution control and isolation, and efficiency with decomposition, routing, and reuse.Source: §10 · p. 24
• The field needs better abstractions for stateful orchestration, stronger evaluation protocols for dynamic long-horizon settings, and closer integration of model reasoning with system guarantees.Source: §10 · p. 24
• Progress on these fronts is necessary for multi-tool agents to move from prototypes to dependable, auditable, and scalable real-world systems.Source: §10 · p. 24