Topics Tool use

Tool-use trajectories

What a run has to record, where logging loses the part that matters, and how to grade a path rather than an answer.

Answer in brief

A tool-use trajectory is the ordered record of a run: which tool was called, with which arguments, what it returned, and why it stopped. It is training signal and audit trail at once; a final answer hides the decisions made.

Three properties make a trajectory usable: full arguments, an observation at every step including errors, and a stop reason that says whether the goal was met or a limit reached.

This page is buying guidance, not a benchmark report.

Per-step record
Observations
Stop reason
Graded path

Entity chain

Task and stateOrdered stepsObservation logGraded outcome

Why the run matters

Agent behavior is a sequence of choices: which tool, with what arguments, when to stop. Training on final answers leaves the model to infer the path, and grading final answers cannot say where a run went wrong.

A trajectory also needs its starting state — task text, permitted tools, starting data and tool versions — or it cannot be replayed. Keep it separate from an expert demonstration: a demonstration isolates one decision, a trajectory is the whole run.

Minimum schema

A delivery missing these fields is expensive to repair. Agree the schema and ask for one complete example.

Field	What it records	Failure it prevents
Step index	Position in the run, under a stable run identifier.	Steps reordered or stitched across attempts, so the sequence cannot be graded.
Tool	The exact tool called, from the permitted inventory.	An alias or invented name that makes the call unverifiable.
Arguments	The full call as the tool received it, types preserved.	Truncated arguments that hide what the agent asked for.
Observation	The response or error payload, unedited except for agreed redaction.	A run graded on call names cannot show whether the result was read.
Stop reason	Goal met, blocked, refused, step limit or budget exhausted.	Runs that stop silently look like runs that gave up.

Record run-level fields once: run identifier, task text, starting state, permitted and prohibited tools, environment versions and the verdict.

What logging breaks

Most unusable trajectories are incomplete at the tool boundary:

Missing observations. Only call names are logged, so nobody can tell what the agent saw.
Truncated arguments. A log cap drops the identifier or filter that determined the decision.
Silent retries. The first error is overwritten and the trajectory shows one clean step.
Merged steps. Parallel calls are flattened and the ordering is lost.

Log at the tool boundary and version the schema; redact with placeholders that preserve the distinction the agent had to make.

Partial credit and forbidden tools

Grade three things separately: format validity, path correctness and task success. A single pass verdict hides which of the three failed.

Partial-credit examples should cover a correct first step followed by a wrong one, a correct path that missed the final state, and a correct answer reached through a prohibited route. Fail any run that calls a prohibited tool; also record whether the tool was offered: declining differs from never being tested.

Reward stopping when the objective is met or the run is blocked; penalize endless loops and premature stops.

Acceptance checklist

Run identifier, task text, starting state and permitted tools are logged once.
Every step has an observation, including errors and empty responses.
Arguments are stored in full, with the types the tool received.
Retries and timeouts appear as separate steps and nothing is overwritten.
The terminal step carries a stop reason from the agreed list.
Format validity, path correctness and task success are graded separately.

Questions to ask a supplier

Are observations the raw tool responses, or summaries written afterward?
How are failed calls, retries and timeouts represented?
Which schema do you use, and can you show one complete trajectory?
How is partial credit defined, and can you show a graded run where path and outcome disagree?
Which tools were prohibited, and how is a run that used one detected?
How is the starting state pinned for replay?

Questions & answers

Is a chat transcript a tool-use trajectory?

Not on its own. A transcript shows intent but not the call boundary — the arguments received and the payload returned. Without them, nobody can tell whether a step depended on the observation.

How long should a trajectory be?

As long as the task, up to the step budget you set. Do not truncate at the first plausible answer or stitch steps from different attempts; a reached budget is itself a stop reason.

Sources for this entry

Editorial checklists on this site — Original guidance written for this reference.
WebArena: a realistic web environment for autonomous agents — Public paper describing realistic web environments and reproducible evaluation of agents (not a ranked supplier).
GAIA: a benchmark of real-world assistant questions — Public paper describing real-world assistant questions requiring tool use (not a ranked supplier).

Editorial checklists on this site are original guidance. Links to official product documentation help readers understand the category; they do not establish comparative performance and are not endorsements of any supplier.

Specifying a trajectory delivery?

Send the tools your agent may call, the schema you expect and one task where it fails. We reply with questions and, where it fits, a short list of suppliers.

Request a provider shortlist

Contact: contact@bestaiagenttrainingdata.com

Cite this entry

Best AI Agent Training Data. “Tool-use trajectories.” Content reviewed 9 November 2026.

https://bestaiagenttrainingdata.com/