What is agentic fine-tuning,
actually?

Agentic fine-tuning is fine-tuning a model to act rather than only to answer. Instead of training on single prompt-and-response pairs, you train on complete trajectories: the model's reasoning, the tool calls it made, the results those tools returned, the corrections it made after something failed, and the final answer. The objective moves with the data, from matching a reference response to completing the task. What comes out is not a model with a better writing style, it is a model with a better policy for operating in a loop.

That distinction is the whole post. Everything else, the data format, the need for a live environment, the reward design, the failure modes, follows from the fact that an agent's output is a sequence of decisions and not a paragraph.

First, what makes a model agentic

Agentic AI is a model that pursues a goal over multiple steps instead of producing one response and stopping. Given a task, it decides what to do next, calls a tool (a search index, a database, a script runner, an internal API), reads the result, and decides again, repeating until it judges the work finished. The defining property is the loop: the model's own previous actions and their observed results become the input to its next decision.

This is why a model can be excellent at single-turn answers and still be a poor agent. Nothing in ordinary instruction tuning teaches it to recover from a malformed tool call, to notice that a query returned zero rows and try a different filter, to stop searching once it has enough, or to give up rather than fabricate. Those are behaviors over sequences, and they only get trained if the training data contains sequences.

What changes when you fine-tune for agents

Three things, and they cascade.

What the training data actually looks like

A trajectory is a structured record of one attempt. It carries the system prompt and the tool schemas the agent was given, the goal, then an alternating sequence: an assistant turn containing reasoning and a tool call, a tool result, another assistant turn, and so on until a final answer. Attached to the whole thing is a verdict, whether the task was solved.

One detail here is load-bearing and easy to get wrong: the loss must be masked on everything the model did not generate. Tool results, system text, and the user's goal are context, not targets. If you train on the tool output tokens too, you are teaching the model to write plausible-looking observations itself, which is exactly the habit that turns an agent into a confident fabricator of database rows it never queried.

Where the trajectories come from

Almost nobody has this data sitting in a warehouse, which is the practical reason agentic AI training feels harder than ordinary fine-tuning. You generate it. Take a set of real tasks with checkable answers, connect the real tools, run the current model against each task several times, and keep the attempts that pass an automated checker. Train on the winners, then run the improved model against the same task set and repeat. This loop goes by expert iteration or rejection sampling, and it is where most of the work lives: the task set and the checker matter more than the optimizer. For that step on its own, including where the seeds come from and how much data it actually takes, see synthetic data for fine-tuning.

The checker is the part worth over-investing in. A task whose success you can verify mechanically (the test suite passes, the number matches the ledger, the returned rows equal the reference query) can be trained on at scale. A task whose success only a human can judge cannot, at least not cheaply, and that constraint quietly determines which agent behaviors you are able to teach at all.

Supervised first, reinforcement learning later

Two stages, and they are not equally urgent. Supervised fine-tuning on filtered successful trajectories is behavior cloning: the model imitates attempts that worked. It is simple to run, easy to debug, and gets most teams a long way, because much of what makes a weak agent weak is mechanical (invalid tool arguments, forgetting it already fetched something, narrating instead of acting).

Reinforcement learning from outcome rewards is what you add when imitation stops improving. Its advantage is that it can credit strategies no demonstration contained, since the model explores and keeps what scores. Its costs are real: you need a reliable automated grader, considerably more compute because every update requires fresh rollouts, and you inherit reward hacking as a live failure mode. Start with the supervised loop, and reach for reinforcement learning when you can state precisely what it is supposed to fix. For how that choice actually gets made, including GRPO and verifiable rewards, see SFT vs. RL for training agents.

What agentic fine-tuning is not

It is not prompt engineering or scaffolding. A better system prompt, a retry wrapper, a planner loop, and a tighter tool schema all improve agent behavior without touching a weight, and they should be exhausted first because they are hours of work rather than weeks. Fine-tuning is what you do when the scaffold is already good and the model still makes the same class of mistake.

It is not RAG. Retrieval gives a model facts it lacks. Agentic fine-tuning changes what the model does with tools it already has. A model that retrieves perfectly and still calls the same endpoint four times in a row has a policy problem, not a knowledge problem.

It is not the same as an agentic training platform. The terms collide constantly. Agentic fine-tuning is a training method, and the model being trained is the agent. An agentic training platform is tooling that an agent operates: a coding agent launches your runs, logs metrics, and reads results back, whatever kind of model is being trained. One describes what you are teaching, the other describes who drives the experiment.

Prompting, plain fine-tuning, and agentic fine-tuning, side by side

Three ways to change how an agent behaves.

When it is worth it

Agentic fine-tuning earns its cost in a narrow set of conditions, and they are worth checking honestly before starting. You have a repeated, high-volume task rather than a long tail of one-offs. You can verify success mechanically. Your tools are proprietary enough that no general model has seen anything like them, which is common with internal APIs and in-house data models. And the scaffold is already tuned, so the remaining errors are judgment errors rather than plumbing.

The economics tend to show up as trajectory length. A general model wandering through fourteen tool calls to answer a question a specialized one answers in four is not just slower, it is four times the tokens and four times the chances to go wrong. On a workload you run thousands of times a day, shortening the loop is usually the return, more than any single accuracy number.

Failure modes to expect

Reward hacking. Any grader that can be satisfied without doing the work eventually will be. An agent rewarded for a passing test suite may learn to weaken the tests. Grade the outcome you actually want, and audit high-scoring trajectories by hand, because a rising reward curve is not evidence that the reward means what you think.

Tool drift. A model trained against one set of tool schemas is partly a recording of those schemas. Rename an endpoint or change an argument and performance degrades in ways that look like general regression. Version your tool definitions alongside your checkpoints and plan on retraining when they move.

Environment mismatch. If training ran against a clean sandbox and production has rate limits, stale caches, and partial outages, you have trained an agent for a world that does not exist. Put the real failure modes into the training environment deliberately.

Narrowing. Heavy training on one task family can cost general instruction-following and conversational quality. Keep a held-out general evaluation running next to your task metrics, and consider parameter-efficient methods like LoRA, which shift behavior less far from the base model and are cheaper to roll back.

Why this data is the most sensitive you have

This is the part that usually gets underweighted. A plain fine-tuning corpus is documents. An agentic trajectory set is a recording of your systems in operation: internal endpoint names and argument shapes, database schemas, ticket contents, the intermediate state of a trade or a reconciliation, and the sequence in which your people actually do the work. It is a description of how your firm operates, assembled in a single machine-readable file.

Which means the training environment cannot reasonably be somebody else's. Generating trajectories requires the real tools connected to real systems, so the compute doing the generating has to sit where those systems already are.

Where this fits at Numerata

P95 is Numerata's training layer, and this is the shape of work it is built for: many runs rather than one, each producing rollouts to compare, grouped and tracked so you can tell which round of expert iteration actually moved the pass rate. It runs on infrastructure you already control, private cloud, on-prem, or fully air-gapped, drawing GPUs from the same pool Lupine manages and handing finished checkpoints to NinetyFive to serve. The trajectories, the tools they touched, and the weights they produced stay inside your environment.

If the individual calls are the problem rather than the loop, tool-use fine-tuning covers teaching a model one specific catalogue of internal APIs. If you are earlier in the picture, what fine-tuning is covers the single-turn case this post builds on, and what GPU orchestration is explains the layer that keeps a rollout-heavy training loop from stranding a fixed fleet. For the training-inside-your-own-walls constraint specifically, see air-gapped LLM training.