Tool-First Principle

• Tool-First Principle is a design doctrine that prioritizes high-level tool abstractions over low-level actions to enhance agent performance.
• It embeds tool knowledge into parameters or workflows, thereby reducing prompt complexity and streamlining execution.
• Applied in web agents, parameter-based models, and dataset construction, it leads to significant gains in accuracy, efficiency, and reliability.

The Tool-First Principle is a design doctrine for tool-using language agents in which high-level tool abstractions are prioritized over alternative mechanisms such as long prompt-resident documentation, low-level browser actions, or query-first annotation pipelines. In recent work, the principle appears in three closely related forms. In web agents, it mandates that the policy attempt tool invocation before falling back to atomic actions such as click, type, or scroll (Lou et al., 3 Apr 2026). In parametric tool calling, it shifts tool knowledge from context into dedicated parameter modules so that grounded API schemas are “in the weights,” not the prompt (Yu et al., 28 May 2026). In tool-use dataset construction, it inverts query-first synthesis by first building executable tool-use chains and only then deriving the corresponding user query and response (Zhou et al., 6 Aug 2025). Taken together, these formulations define a family of approaches in which tool structure is primary and free-form reasoning is conditioned on that structure rather than the reverse.

1. Definitions and conceptual scope

A precise formulation appears in web-agent research: a web-agent should attempt to invoke a high-level “tool” abstraction wherever possible before falling back to series of low-level browser actions. Let $T=\{t_1,\dots,t_n\}$ denote the library of tool actions and $A=\{a_1,\dots,a_m\}$ the atomic browser actions. The decision rule is: if there exists $t\in T$ that semantically matches a subtask description $q$, invoke $t(\dots)$; otherwise plan and execute a sequence in $A$ to accomplish the subtask (Lou et al., 3 Apr 2026).

A second formulation appears in tool-use data generation. Traditional “query-first” generation picks a user instruction $q$ and then searches for a matching tool-use chain $\mathcal W$. ToolGrad inverts this order: first construct a valid, multi-step tool-use chain $\mathcal W$ with guaranteed executability, and only then synthesize the corresponding user query $q$ and final response $A=\{a_1,\dots,a_m\}$0. Formally, given an API library $A=\{a_1,\dots,a_m\}$1,

$A=\{a_1,\dots,a_m\}$2

Every API call in $A=\{a_1,\dots,a_m\}$3 succeeds by construction (Zhou et al., 6 Aug 2025).

A third formulation is parameter-centric. ParaTool addresses the dependence of mainstream in-context learning approaches on detailed tool documentation and usage examples in the prompt. Its central move is to project each tool into a dedicated, loadable set of parameters, so that tool calling can proceed without relying on in-context documents or examples. The paper explicitly characterizes this as enforcing “tool first” by making parameters the model’s primary mode of access to tool knowledge (Yu et al., 28 May 2026).

These formulations are not identical algorithms. They are, however, structurally aligned. One prioritizes tools at action selection time, another at representation time, and another at data-construction time. This suggests that the Tool-First Principle is best understood as an ordering constraint: tool structure is consulted, loaded, or constructed before lower-level fallback mechanisms are used.

2. Action-level Tool-First policies in web agents

In web agents, the principle is operationalized as a policy over two action spaces: a library of high-level tools and a library of atomic browser actions. The stated intuition is that each tool may encapsulate long, deterministic UI trajectories and thereby amortize reasoning effort. The policy therefore queries the tool library before planning at the atomic-action level (Lou et al., 3 Apr 2026).

The same study also isolates practical design rules for effective Tool-First systems. The first rule is to decouple reasoning from execution: encode only deterministic, reusable UI primitives as tools, while retaining grounding-dependent reasoning such as planning and conditionals at the agent layer. The second is to favor composability over comprehensiveness: a small set of low- to medium-complexity tools, specified as $A=\{a_1,\dots,a_m\}$4–$A=\{a_1,\dots,a_m\}$5/site, is reported as more effective than many end-to-end tools. The third is to ensure functional coverage by prioritizing tools that collectively cover the $A=\{a_1,\dots,a_m\}$6 most frequent user intentions, with coverage measured by the percentage of tasks invoking at least one tool; the paper reports Hybrid $A=\{a_1,\dots,a_m\}$7 versus WALT $A=\{a_1,\dots,a_m\}$8. Additional rules are to prune low-utility and overly complex tools, to consider semantic skills as a white-box alternative for weakly synthesized tools, and to retain visual grounding by always providing page screenshots even when tools are available (Lou et al., 3 Apr 2026).

The web-agent formulation also makes explicit that Tool-First is not equivalent to “tool-only.” The recommended deployment recipe is a two-stage policy: first, tool candidate retrieval that ranks tools by semantic match to user intent; second, a fallback planner that generates atomic Click/Type plans if no tool exceeds confidence $A=\{a_1,\dots,a_m\}$9. A related mitigation is a hybrid action selector with threshold $t\in T$0: if $t\in T$1 then tool-first, else atomic-explore (Lou et al., 3 Apr 2026).

This action-level perspective narrows the scope of tool abstraction. Tools are not treated as arbitrary macros for all behavior, but as deterministic reusable operators embedded within a larger grounded policy. A plausible implication is that the principle is strongest when tool boundaries coincide with stable environmental regularities rather than with open-ended reasoning steps.

3. Parameter-level Tool-First representations in ParaTool

ParaTool defines a fixed backbone LLM $t\in T$2 with $t\in T$3 Transformer blocks, each containing an FFN layer with weight $t\in T$4. Given a tool set $t\in T$5, it allocates to each tool $t\in T$6 a small LoRA module

$t\in T$7

so that at layer $t\in T$8 the adapted weight is

$t\in T$9

This is the paper’s parametric tool representation: detailed tool semantics are encapsulated in independent parameter modules rather than kept in context (Yu et al., 28 May 2026).

The training procedure has three stages. First, parametric tool pre-training encapsulates the knowledge of different tools into independent parameter modules. For each tool $q$0, a dedicated dataset $q$1 of next-tool-prediction traces is constructed. Each example is formatted in two ways, document-aware $q$2 and document-free $q$3, with shared target $q$4. The objective is the sum of log-likelihoods over both formats:

$q$5

All $q$6 are trained in parallel, each on its own $q$7, with $q$8 frozen (Yu et al., 28 May 2026).

Second, soft tool selection employs a gating network to dynamically weigh and aggregate relevant tool parameters. At inference step $q$9, with query $t(\dots)$0 and history $t(\dots)$1, a context vector $t(\dots)$2 is computed, and each tool documentation is embedded into $t(\dots)$3. A small MLP produces scores

$t(\dots)$4

which are normalized by softmax,

$t(\dots)$5

The resulting soft parameter mixture is

$t(\dots)$6

and the action is sampled as

$t(\dots)$7

The gating network is trained with $t(\dots)$8 and $t(\dots)$9 frozen by minimizing

$A$0

where the entropy term prevents collapse to a hard one-hot (Yu et al., 28 May 2026).

Third, parametric tool fine-tuning jointly updates tool parameters to align the training and inference processes. The gating network is frozen, $A$1 is recomputed, $A$2 is formed, and the model minimizes the standard next-token loss

$A$3

The stated purpose is to force each $A$4 to cooperate under realistic $A$5-distributions (Yu et al., 28 May 2026).

The paper’s synthesis is explicit: ParaTool enforces “tool first” by embedding each tool’s detailed semantics directly into $A$6, dynamically loading only the subset and proportions of tool parameters relevant to each query, and jointly fine-tuning under soft composition so that tool invocation becomes an integral, parameterized skill. Soft gating adds robustness by never entirely excluding any plausible tool, allowing the LLM itself to correct marginal gate errors (Yu et al., 28 May 2026).

4. Answer-first workflow construction in ToolGrad

ToolGrad embodies the Tool-First Principle at the level of supervised data construction. Instead of generating a user query and then searching for a corresponding tool-use annotation, it first constructs valid tool-use chains and then synthesizes the query and response. The paper characterizes this as an “answer-first” approach and states that it leads to ToolGrad-5k, a dataset generated with more complex tool use, lower cost, and $A$7 pass rate (Zhou et al., 6 Aug 2025).

The iterative algorithm grows a workflow $A$8 over $A$9 iterations. At each iteration, an API Proposer picks top-$q$0 candidates from a random mini-batch, an API Executor runs each proposal in parallel, an API Selector picks the single best API and the chain to attach it to, and then the workflow and its inverse annotation are updated. The workflow update is deterministic, while inverse query synthesis is performed by an LLM. The procedure returns $q$1 (Zhou et al., 6 Aug 2025).

ToolGrad formalizes textual “gradients” as discrete API selections rather than real vectors. A value function $q$2 scores how much adding $q$3 to workflow $q$4 improves its validity or complexity, and an LLM proxy implements

$q$5

This selected API is the discrete gradient $q$6, and the forward update is

$q$7

Over $q$8 steps, these textual gradients accumulate into a full multi-step chain $q$9 (Zhou et al., 6 Aug 2025).

Once a complete chain $\mathcal W$0 is built, a single LLM call produces both the user query $\mathcal W$1 and the agent’s final response $\mathcal W$2 from the API usage chains. The paper states that this inverse prediction is much simpler and more reliable than asking an LLM to discover the full tool chain from an underspecified query (Zhou et al., 6 Aug 2025).

In this setting, Tool-First is a guarantee mechanism as much as a design preference. Because the workflow is executable before annotation, the supervision signal is grounded in valid API behavior rather than in a speculative search over annotations. This suggests that the principle can alter not only inference-time behavior but also the epistemic quality of the data used to train tool-using models.

5. Reported gains, complexity, and efficiency

The three works report distinct but convergent empirical effects. In web agents, strong human-crafted tool libraries yield consistent gains on WebArena. Under Hybrid-Agent, average success rate over five sites increases from $\mathcal W$3 to $\mathcal W$4 for GPT-5, from $\mathcal W$5 to $\mathcal W$6 for Grok-4.1-R, and from $\mathcal W$7 to $\mathcal W$8 for Mistral-L-3.1. By contrast, synthesized-tool frameworks show mixed results: under WALT, GPT-5-mini changes from $\mathcal W$9 to $\mathcal W$0 and GPT-5 from $\mathcal W$1 to $\mathcal W$2; under SkillWeaver, GPT-5 changes from $\mathcal W$3 to $\mathcal W$4. The study therefore emphasizes two points: tools yield consistent $\mathcal W$5 whenever the tool user is clearly weaker than the tool constructor, and human-curated tools deliver uniformly large gains, with $\mathcal W$6–$\mathcal W$7 across all models (Lou et al., 3 Apr 2026).

The same web-agent study reports nontrivial efficiency trade-offs. Large tool sets can increase both prompt tokens, with $\mathcal W$8k tokens/website, and agent steps, with Hybrid-Agent $\mathcal W$9–$q$0, whereas a small, focused tool library reduces average steps by approximately $q$1. The conclusion is explicit: a Tool-First strategy must be paired with a carefully curated tool set to realize latency improvements $q$2 (Lou et al., 3 Apr 2026).

ParaTool quantifies the computational advantage of parameterizing tool knowledge. Context-based in-context learning has per-layer cost $q$3, where $q$4. ParaTool has per-layer cost $q$5, with $q$6 and $q$7. On Stable ToolBench with Llama-3.1-8B, Context+Docs&Examples requires approximately $q$8–$q$9 TFLOPs per problem, whereas ParaTool requires approximately $A=\{a_1,\dots,a_m\}$00–$A=\{a_1,\dots,a_m\}$01 TFLOPs plus $A=\{a_1,\dots,a_m\}$02–$A=\{a_1,\dots,a_m\}$03 TFLOPs for LoRA aggregation, yielding up to $A=\{a_1,\dots,a_m\}$04 FLOPs reduction. On BFCL with Qwen2.5-7B, the reported reduction is up to $A=\{a_1,\dots,a_m\}$05 (Yu et al., 28 May 2026).

ParaTool also reports accuracy gains and hallucination reduction. On Stable ToolBench “Live Parallel Multiple,” Context+ICL peaks and then drops as examples increase, while ParaTool improves pass-rate by $A=\{a_1,\dots,a_m\}$06 for Qwen2.5 over best ICL. On BFCL “Live Parallel Multiple,” Context+Docs&Examples achieves $A=\{a_1,\dots,a_m\}$07–$A=\{a_1,\dots,a_m\}$08 AST-correct, whereas ParaTool reaches $A=\{a_1,\dots,a_m\}$09–$A=\{a_1,\dots,a_m\}$10, an increase of $A=\{a_1,\dots,a_m\}$11 absolute, with far fewer hallucinated calls. An ablation shows that hard Top-1 selection drops accuracy by approximately $A=\{a_1,\dots,a_m\}$12, while average-all mixing fails catastrophically by hallucinating nonexistent parameters (Yu et al., 28 May 2026).

ToolGrad reports efficiency and reliability gains at data-generation time and downstream-model gains at inference time. Relative to the prior DFS-based method from ToolBench, pass rate increases from $A=\{a_1,\dots,a_m\}$13 to $A=\{a_1,\dots,a_m\}$14, average ground-truth tool calls per sample increase from $A=\{a_1,\dots,a_m\}$15 to $A=\{a_1,\dots,a_m\}$16, LLM calls per sample decrease from $A=\{a_1,\dots,a_m\}$17 to $A=\{a_1,\dots,a_m\}$18 (−$A=\{a_1,\dots,a_m\}$19), and tool executions per sample decrease from $A=\{a_1,\dots,a_m\}$20 to fewer than $A=\{a_1,\dots,a_m\}$21. On the held-out $A=\{a_1,\dots,a_m\}$22 ToolGrad-5K test split, Gemma-1B/4B/12B achieve tool recall of $A=\{a_1,\dots,a_m\}$23, success rate of $A=\{a_1,\dots,a_m\}$24, and QoR of $A=\{a_1,\dots,a_m\}$25, while baselines such as gpt-4.1, Gemini-2.5-flash, and Claude-3.7-sonnet are reported at approximately $A=\{a_1,\dots,a_m\}$26–$A=\{a_1,\dots,a_m\}$27 tool recall, approximately $A=\{a_1,\dots,a_m\}$28–$A=\{a_1,\dots,a_m\}$29 success rate, and approximately $A=\{a_1,\dots,a_m\}$30–$A=\{a_1,\dots,a_m\}$31 QoR. On ToolBench-I3 using Llama-3.2, ToolGrad fine-tuning yields QoR $A=\{a_1,\dots,a_m\}$32 for Llama-3.2-1B, $A=\{a_1,\dots,a_m\}$33 for Llama-3.2-3B, and $A=\{a_1,\dots,a_m\}$34 for Llama-3.1-8B, compared with lower scores for ToolBench-ReAct and ToolBench-DFS, and with inference cost of $A=\{a_1,\dots,a_m\}$35 LLM calls and $A=\{a_1,\dots,a_m\}$36 tool calls for the standard framework versus approximately $A=\{a_1,\dots,a_m\}$37 for ReAct and approximately $A=\{a_1,\dots,a_m\}$38 for DFS (Zhou et al., 6 Aug 2025).

Across these results, the common pattern is not merely higher task accuracy. It is the reallocation of computation: fewer prompt-resident tool descriptions, fewer failed annotation searches, or fewer low-level browser operations, depending on the setting.

6. Failure modes, misconceptions, and research implications

A central misconception addressed directly in the web-agent study is that more tools always imply better performance. The paper reports degraded performance when the backbone model out-performs the tool constructor, token-cost inflation and higher latency when searching large tool inventories, brittleness from overly task-specific tools under UI drift or unexpected page states, and tool-selection errors leading to recovery loops in the action trace. The mitigations are correspondingly conservative: align tool-constructor strength greater than or equal to tool-user strength or fall back to atomic actions; cap the total number of tools and apply invocation-based pruning; use a hybrid action selector with confidence threshold $A=\{a_1,\dots,a_m\}$39; and expose weakly synthesized tool code as semantic skills rather than direct API calls (Lou et al., 3 Apr 2026).

ParaTool identifies a different class of failure modes. The BFCL ablation shows that hard Top-1 selection drops accuracy by approximately $A=\{a_1,\dots,a_m\}$40, and average-all mixing fails catastrophically by hallucinating nonexistent parameters. A representative Stable ToolBench case study shows the gate ranking an Airline tool above the correct Airport tool, but because $A=\{a_1,\dots,a_m\}$41 was still loaded with nonzero weight, the LLM overrode the gate error and called the correct API. The paper presents this as evidence that soft gating improves robustness by not entirely excluding plausible tools (Yu et al., 28 May 2026).

ToolGrad’s contrast class is the failure mode of query-first dataset generation itself: annotation failures, lower efficiency, and less complex tool-use chains. Its answer-first procedure is presented as a remedy because it grounds each sample in an executable chain and therefore avoids wasted searches. The broader implications listed by the paper include scalable, failure-free generation, better generalization on OOD benchmarks, bootstrapping small models, and potential extension to reinforcement-learning pipelines, multi-agent memory systems, or human-in-the-loop workflows (Zhou et al., 6 Aug 2025).

Taken together, these works locate the main controversy not in whether tools can help, but in how tool abstractions are represented, curated, and prioritized. The evidence does not support an unrestricted doctrine of tool maximalism. Instead, it supports a conditional principle: tools are most effective when they are strong, domain-native, coverage-oriented, and integrated with a fallback mechanism; when tool knowledge is loaded parametrically rather than repeated in long contexts; or when tool-use supervision is generated from executable answers rather than inferred from underspecified questions. This suggests that the Tool-First Principle is best treated as a systems principle for structuring capability and computation, not as a universal claim that any increase in tooling improves agent performance.