Making Data Vary Without Losing Meaning
Once xLAM has placed tool descriptions, requests, calls, and observations in a common structure, a new problem appears: a model can memorize that structure too literally. This chapter focuses on how xLAM varies the presentation of an interaction while trying to preserve the task underneath, and how it detects the errors that variation can expose or create. The practical goal is to tell genuine robustness apart from a model that has simply learned one ordering, one delimiter, or one style of function call.
Changing the surface without changing the task
The first augmentation family changes the prompt's surface form. The available tools are presented as a list, so xLAM can shuffle the order of that list. It can also shuffle the order of a tool's name, description, and parameters, as well as the order of parameters within a call. The sections surrounding the interaction—task instruction, tools, format instruction, examples, and query—can appear in different orders. These changes do not alter which functions are available or what the request means. They alter where the same information appears and how the model must find it.
This matters because a fixed presentation creates an accidental shortcut. If the model repeatedly sees the correct tool in the first position, it may learn a positional association instead of comparing the request with every available description. If the required parameter always appears last, the model may learn a familiar layout rather than the parameter's role. Shuffling removes those easy cues. It forces the decision to depend more on the relationship between the query and the tool schema.
The pipeline also varies how structured sections are joined into a single training sequence. The report describes several concatenation styles, including explicit start and end markers, XML-like tags, and plain text. These tokens are the boundaries a language model sees when a structured record becomes a prompt. Varying them tests whether the model can preserve the separation between, for example, a user query and a tool description even when the visual markers change.
That does not mean every output format is interchangeable in a running system. xLAM uses 15 output formats with corresponding instructions and converters, including JSON, XML, YAML, and plain text. A converter is what turns a model's selected format back into a representation the downstream system can use. Format variation is therefore a training strategy for reducing dependence on one serialization, not a promise that an arbitrary text response can be executed without an explicit interpretation step.
The second augmentation family changes the language of the instruction. A powerful language model rephrases task instructions so that a model encounters different ways of being asked to perform the same kind of action. This addresses a different shortcut from order memorization. Users do not all phrase a request in the same way, and an agent should not require one canonical sentence before it can identify the relevant function.
But rephrasing is more dangerous than shuffling. Moving a tool description does not normally change the description's meaning; rewriting a sentence can. A rephrased instruction might accidentally add a requirement, remove a constraint, change whether multiple calls are expected, or imply a different output format. xLAM therefore checks rephrased instructions by asking a model to follow them and produce correct function calls. The check is an attempt to ensure that linguistic variety remains label-preserving. Without it, augmentation would multiply inconsistent answers and make the training set less trustworthy while appearing more diverse.
The causal idea is straightforward. First, preserve the underlying query, tools, and intended call. Second, alter the way that information is presented. Third, verify that the altered instruction still leads to the same valid behavior. If the last step is skipped, the pipeline cannot tell robustness training from the deliberate introduction of contradictions.
Consider one request asking for weather in Palo Alto and Paris. In one training instance, the weather tool may appear first, its location parameter may be listed before its units parameter, and the output may be wrapped in JSON. In another, the same tool may appear after an unrelated function, the fields may be reordered, and the format instruction may use different boundary markers. The correct underlying decision is still two calls to the weather function with the two locations. A model that learned the relationship should recover that decision from the descriptions; a model that learned a position or delimiter may fail even though none of the relevant facts changed. This is the kind of shortcut the augmentation is designed to make less profitable.
The same test applies to language. A direct request such as “get the weather for both cities” and a more conversational request such as “I am comparing the conditions in these two places” should lead to the same call pattern when the available tools and intended information are equivalent. But a rewrite that says “compare the cities and summarize the difference” may add a response requirement beyond the calls, while a rewrite that mentions only one city changes the task. The verification step must catch those differences; otherwise, the pipeline would label two different tasks as if they were one.
The errors that variation exposes
Augmentation is useful only if the records entering it are worth varying. xLAM's quality analysis separates several failure modes that look similar when all of them are called “bad tool use.” An undefined function call occurs when the predicted function is not in the list of available functions. An undefined argument occurs when the function name matches but an argument name does not. These are action-space or schema failures: the model has crossed a boundary visible in the structured tool description.
An incorrect argument type is different. The model may select the right function and provide the right apparent value, but encode a list as a string or otherwise violate the parameter type. The report notes that many such errors can be fixed by converting the argument to the expected type. That makes them partly mechanical failures, although the conversion must still be safe. Changing a string into a list is not enough if the list contains values that do not fit the user's request.
Argument hallucination concerns grounding rather than serialization. One form invents a tool or argument name; the structured schema makes that form relatively easy to detect. The harder form invents an argument value that does not appear in the user's query or in earlier observations. A model might know that a weather function needs a radius and supply a plausible number even though the user never provided one. The call can be perfectly formatted and type-correct while still being unsupported by the interaction.
Low-quality reasoning and planning form another category. A trajectory may contain the right tools but a confused plan, repeated turns, or a thought step that does not move toward the user's objective. xLAM uses rule-based heuristics to filter some low-quality records, then prompts language models to assess whole trajectories and individual thought steps. A sample of these ratings is checked by humans. The report treats this as distinct from schema validation because a well-formed function call can be the endpoint of poor planning, and a good plan can still be rendered in the wrong format.
These categories imply a division of labor. Rules are strong when the question is local and explicit: does the function name exist, is a required field present, or does the argument type match the declared type? A language-model judge is useful when the question depends on context: is the value supported by the query, does the sequence of calls cover all the user's requests, or does the reasoning lead to the observed action? The judge is not automatically more reliable. It introduces its own possibility of inconsistency, but it can examine relationships that simple string matching cannot.
The distinction between local and contextual error also explains why the common representation matters. The checker needs the available tools to identify undefined names, the parameter schema to identify type problems, and the query and prior observations to identify unsupported values. If these pieces were stored in unrelated formats, each check would need to reconstruct the interaction before it could even ask whether an error occurred. Standardization reduces that reconstruction burden; it does not make the semantic decision automatic.
These errors also occur at different boundaries in the agent's operation. An undefined function is usually visible as soon as the model output is compared with the action space. A type mismatch may appear when the call is parsed or prepared for execution. An unsupported value may remain invisible until a reviewer compares the call with the user's wording and the history. A weak plan may only become clear when the whole trajectory is read: the model may repeat an action, ignore a returned observation, or satisfy one part of a multiple request while abandoning another. Treating all four cases as one generic “bad example” would make it harder to choose the right repair or rejection rule.
The categories also explain why cleaning is not the same as deleting every unusual example. An unfamiliar phrasing may be valuable if it preserves the intended call; an unusual parameter value may be correct if it is grounded in the request; and a refusal to call may be the right response when no supplied tool can solve the problem. The issue is not whether an example looks typical. It is whether the example maintains the relationship between the request, the action space, the arguments, and the next state. xLAM's filters are meant to remove contradictions and unsupported actions, not to force every interaction into one superficial pattern.
The training process can now be understood as a controlled path rather than a single transformation:
What the ablation supports
The xLAM report tests whether these operations matter by comparing 7B models trained on raw data, augmented data, and augmented data that has also been cleaned. The augmented data improves on raw data across the selected metrics: the reported gains are 2.3% on ToolBench, 5.8% on WebShop, and 18.3% on ToolQuery. Adding cleaning produces a further 23.4% improvement on ToolQuery in the stated comparison. The exact metric values are less important here than the pattern: changing the presentation and removing defective records are associated with better measured agent behavior than training on the unprocessed set.
The result supports a claim about the pipeline, not a claim that one shuffle operation causes a fixed percentage improvement everywhere. The study compares composite datasets. It does not isolate each field-order change, delimiter, instruction rewrite, output format, or quality filter in a complete factorial experiment. The reported improvements also come from particular models, tasks, and evaluation settings. They should therefore be read as evidence that augmentation and cleaning can change capability, not as universal conversion rates for data preprocessing.
The comparison is especially informative because it changes the training material rather than merely changing the prompt at evaluation time. A model trained on raw records may perform well when the test resembles the same presentation, while a model trained on varied records has had to separate the stable decision from the layout around it. The additional gain after cleaning suggests that the model is also sensitive to the quality of the supervision it receives. But because the augmented and cleaned sets are composites, the result cannot tell us whether the biggest contribution came from order variation, instruction variation, format diversity, error removal, or their interaction.
There is a deeper reason to pair the two operations. Variation without cleaning spreads mistakes across more surface forms. Cleaning without variation can leave a small set of correct but repetitive examples that teaches brittle habits. In xLAM's design, augmentation seeks to make the stable relationship harder to shortcut, while verification seeks to ensure that the relationship remains correct. The two processes address opposite risks: overfitting to presentation and learning from misleading supervision.
This balance also clarifies why a generated example should not be judged by fluency alone. A rephrased instruction can sound natural and still change the number of calls expected. A YAML or plain-text answer can look readable and still omit a required argument. A correctly typed argument can be plausible and still be unsupported by the query. The useful question is always relational: did the altered record preserve the connection between user intent, available tools, model action, and expected result?
xLAM's answer is not to freeze the data into one perfect template. It is to create controlled variation, attach the right checks to each failure surface, and measure whether the resulting models behave better. That prepares the way for APIGen, which uses the same distinctions when it creates new query-and-call pairs around executable APIs rather than only transforming existing records.