Salesforce publishes the APIGen-MT paper and the xLAM-2 models

Background

An agent, in the sense used here, is a language model that is handed a task and a set of tools (search, a code interpreter, a booking API) and has to work through the task over several turns, deciding at each step which tool to call and what to say to the user. Teaching a model to behave this way needs example conversations in which every step is labelled with the action that should have been taken. The APIGen-MT paper argues that high-quality data of this kind is scarce and expensive to collect by hand ^[1].

The difficulty is structural. A single-turn example is one question and one answer; a multi-turn example is a whole sequence, where the correct action at step four depends on what happened at steps one to three. Someone has to sit down and write out that sequence, together with the tool outputs that a real system would have returned, and then check that every intermediate step is right. That work does not scale well, which is why synthetic generation is attractive: if the correct actions can be specified in a compact form, a model can be used to fill in the rest.

What was released

The paper appeared on arXiv on 4 April 2025 ^[1]. Alongside it, Salesforce published the xLAM-2-fc-r series, models trained on the generated data at sizes from 1B to 70B parameters ^[1]. The weights and the generated datasets were published on Hugging Face under a non-commercial licence ^[2], and Salesforce labels the model release as for research purposes only ^[2].

How the pipeline works

APIGen-MT splits data generation into two phases. The first produces task blueprints with ground-truth actions ^[1]. A blueprint is a skeleton for one task: what the user is trying to do, which tools are involved, and the sequence of actions that counts as correct. The second phase turns those blueprints into full interaction trajectories ^[1] — the complete back-and-forth, including the user's turns, the agent's tool calls, the results the tools return, and the final reply.

The split is the interesting design decision, because the two things that can go wrong with generated data are checked separately. Whether an action sequence is correct can be settled at the blueprint stage, before any conversation text exists. Whether the conversation reads like something a person would actually type is a question about surface form, and can be handled in the second phase without disturbing the correctness of the actions underneath. Separating structure from wording makes it possible to verify the part that matters for task success, and to vary the part that matters for realism.

Results

The paper reports that the xLAM-2-fc-r series outperforms prior models on the same multi-turn benchmarks ^[1]. As with any benchmark result reported by the authors of the model being measured, this describes performance on those benchmarks; it is not a general ranking of agent models.

Why it matters

Much of the effort in building an agent goes into obtaining demonstrations rather than into the model itself. Publishing the pipeline, the generated datasets and the weights together gives other groups a reproducible recipe rather than a single checkpoint: they can rerun the generation, inspect the blueprints, and check where the trajectories succeed or fail. For readers trying to understand the state of agent training data, the pipeline is arguably the more informative artefact, since the models are one application of it.

The licence terms set a clear boundary. The weights and datasets are under a non-commercial licence ^[2], and Salesforce labels the release as for research purposes only ^[2]. That makes the material usable for study, comparison and further research, but not for building a commercial product without a separate arrangement.