Trajectory Data and Quality Filtering

The ShareGPT Format

Every trajectory the batch runner produces is stored in ShareGPT format. This is a well-established structure in the fine-tuning community, supported by most training frameworks including Axolotl, LLaMA-Factory, and Unsloth. If you have ever worked with open-source fine-tuning, you have probably encountered it.

A ShareGPT trajectory is a JSON object with a conversations array. Each element in the array is a message with two fields: from (who sent it) and value (what they said). The from field is one of human, gpt, or function_call / observation for tool interactions.

A simple trajectory from a single-tool-call session might look like: the human sends a prompt, gpt sends a function_call invoking a tool, observation returns the tool's result, and gpt sends the final response. Each step in the agent's reasoning is captured as a separate message in the conversation array.

This format is what makes batch trajectories immediately usable for training. There is no format conversion step between the batch runner's output and a fine-tuning pipeline's input. You point your training script at trajectories.jsonl and it works.

What Trajectories Capture Beyond the Conversation

Beyond the conversation messages, each trajectory includes metadata that the batch runner adds during processing:

Tool call statistics. How many tool calls the agent made during the session, broken down by tool name. This lets you filter trajectories by tool-use complexity -- selecting only trajectories with 3 or more tool calls for a dataset focused on multi-step reasoning, for example.

Reasoning coverage metrics. What fraction of the agent's responses included reasoning tokens (the extended thinking content that is hidden from the final user output). High reasoning coverage indicates the agent was genuinely working through the problem rather than producing shallow responses.

Session metadata. The prompt index, the run name, the model used, the duration, and the timestamp. These fields let you trace any trajectory back to the exact run that produced it.

Automatic Quality Filter 1: Missing Reasoning Tokens

The batch runner automatically removes trajectories where the agent produced no reasoning tokens at all. These are sessions where the model responded without engaging its extended thinking capability.

Why filter these? If you are generating training data intended to teach a model to reason, trajectories that contain no reasoning are not useful examples. They show the model jumping straight to an answer without visible intermediate thought. Training on these trajectories can actually harm reasoning ability by providing examples of the behavior you want to avoid.

If you find that a large fraction of your batch is being filtered for missing reasoning, your prompts may be too simple. The model is answering them without needing to reason. Try adding complexity: multi-step requirements, ambiguous inputs that require interpretation, or tasks that involve error recovery.

Note that some models do not support extended reasoning at all. If you are running a batch with a model that has no reasoning capability, this filter will remove everything. Check your model's capabilities before designing a large dataset around reasoning-heavy prompts.

Automatic Quality Filter 2: Hallucinated Tool Names

The second automatic filter removes trajectories where the agent called tools that do not exist. If the agent produces a function call for search_codebase but that tool is not in the active toolset, the trajectory is filtered out.

Hallucinated tool calls indicate the agent is confused about what tools are available. These trajectories are harmful as training data because they teach the model to call tools that do not exist -- exactly the behavior you want to prevent. They are also a signal that your toolset configuration may be mismatched with your prompts.

If you see many trajectories filtered for hallucinated tools, check two things: first, that the toolset you are using actually contains the tools your prompts reference; second, that your system prompt or prompt text is not inadvertently suggesting tool names that are not available.

Downstream Uses for Filtered Datasets

Once your trajectories have passed the automatic filters, what can you do with them? The three primary uses correspond to the three use cases from lesson one, but the specifics are worth spelling out.

Fine-tuning. Point a training framework like Axolotl at your trajectories.jsonl file. The ShareGPT format means no preprocessing is needed. The trajectories become supervised training examples that teach the model to reason and use tools in the same patterns the base Hermes agent used. If your dataset is diverse and high-quality, the resulting fine-tuned model generalizes well to new tasks.

Evaluation scoring. For evaluation datasets, you compare the agent's trajectory against expected outputs. If you have a ground-truth answer for each prompt, you can write a simple script that reads each trajectory, extracts the final response, and compares it against the expected answer. The metadata fields make it easy to slice results by model, toolset, or prompt category.

Analysis and debugging. Trajectories are excellent debugging tools. If an agent is behaving unexpectedly in production, running a batch of representative prompts and analyzing the trajectories can reveal whether the problem is systematic (the agent always makes the same mistake on a certain type of prompt) or sporadic (only some prompts trigger the issue).

Manual Quality Review

Automatic filters catch the most obvious quality problems, but they cannot catch everything. Manual spot-checking is still essential.

After a batch run, open 10 to 20 random trajectories from trajectories.jsonl and read them start to finish. Ask yourself: Does the reasoning make sense? Are the tool calls appropriate for the task? Does the final output match what the prompt asked for? Are there any signs of the agent confusing itself partway through?

Pay particular attention to trajectories where the agent made many tool calls. These are the most complex sessions and the most likely to contain mistakes. A trajectory where the agent called 8 tools to accomplish something that should have taken 2 is worth reading carefully -- either the agent was inefficient, or the prompt was ambiguous in a way that caused unnecessary work.

If your spot-check reveals systematic problems, address them before using the dataset for training. Feeding a fine-tuning pipeline a dataset with systematic errors trains the resulting model to reproduce those errors.