When and Why to Fine-Tune · Model Specialization: Fine-Tuning & Agentic RL

The proposal lands in the architecture review with the confidence of the obvious: "our support agent keeps calling the wrong tool and writing the escalation summary in its own format — we should fine-tune it on our data." Half the room nods. It sounds like the adult version of prompt engineering: deeper, more permanent, more real. The staff engineer in the corner asks one question: "what did the eval suite say about why it fails?" Silence. There is no eval suite. There is a screenshot of one bad trajectory and a strong feeling. Four weeks of engineering time and a five-figure GPU bill hang on the next ten minutes of conversation.

This lesson is those ten minutes, done properly. Fine-tuning — continuing training on your own data so the weights themselves change — is a genuinely powerful tool. It transforms an agent's default behavior in ways no prompt can match: which tool it reaches for first, how many steps it takes before it answers, whether its arguments validate on the first try, how much context it needs to be told before it acts. It is also the most over-prescribed remedy in applied AI, reached for when cheaper tools would win, and fully capable of quietly destroying capabilities you were not measuring.

You arrive here having already built the prerequisites. From Transformer Architecture & LLM Internals you know what a training step does to a weight matrix. From Evaluation & Benchmarking of Agentic Systems you have the suites that will judge every run in this course — and without them, nothing in the next fourteen lessons is measurable. What this lesson adds is the judgment that should precede every training run: what fine-tuning actually changes, what it reliably cannot do, and the decision that separates the two.

1. What Fine-Tuning Actually Is

Mechanically, fine-tuning is the same next-token objective that built the base model, run by you on a much smaller corpus. The loss is cross-entropy over your target tokens; the data is thousands of examples instead of trillions of tokens; the compute is hours on one GPU instead of months on tens of thousands. Nothing exotic happens. The model's weights move a little way in the direction that makes your examples more probable, and everything else the model knows moves with them.

Three variants matter in practice, and the hardware column is the reason the third one exists:

Variant	What trains	Hardware for an 8B base	When you use it
Full fine-tuning	Every weight	Multi-GPU node (~130 GB with Adam states), FSDP or DeepSpeed	Deep domain shifts, new languages, frontier labs — rarely you
LoRA (Lesson 5)	Small adapter matrices; base frozen	One 40-80 GB card	The practitioner default
QLoRA (Lesson 6)	Adapters over a 4-bit quantized base	One 24 GB consumer card	Same quality class, hardware you can rent by the hour

The open-weights premise of this course pays off here. Because a Qwen3-8B or Llama-class 8B checkpoint is downloadable, you can change its weights at all, run the experiment on your own infrastructure, and keep the artifact. Closed frontier models offer hosted fine-tuning APIs where you upload JSONL and receive a model ID: the concepts in this course transfer directly, but the control does not — you cannot inspect the adapter, serve it yourself, or run the RL loops in Lessons 10 through 13.

2. The Knowledge/Behavior Split, Now Load-Bearing

One rule governs everything in this course, and most failed fine-tuning projects are the rule being ignored: fine-tuning changes behavior reliably and knowledge unreliably.

Training on your API documentation does not turn the model into a dependable lookup table for your API. A fact seen a handful of times during fine-tuning lodges weakly, blurs into the billions of patterns already in the weights, and comes back out as a confident hallucination wearing your house style. Worse, the fact freezes: the moment training ends, the weights stop learning, and your endpoint list is a snapshot of the day you built the dataset. What fine-tuning changes superbly is the shape of behavior — format, tone, register, task reflexes, the choices the model makes by default when nobody told it what to do.

For agents specifically, that split has a sharper edge than it does for chat models, because an agent's behavior is a sequence of decisions and every one of them is trainable:

Fine-tuning is the right tool for	The wrong tool for
Tool-selection reflexes — reaching for `search_orders` before `list_customers` without 3,000 tokens of instruction saying so	Teaching the agent your current tool catalogue (tools change weekly; put them in the request)
Argument discipline — emitting valid JSON against your schemas on the first attempt instead of the third	Any fact with a shelf life: prices, inventory, org charts, on-call rotations
Trajectory shape — knowing when three tool calls are enough and when to stop and ask	Per-user or per-tenant knowledge separation (weights have no access controls; everyone gets everything)
House output format at scale — every incident summary in your exact schema, with the instructions baked in	Attributable answers (weights carry no citations)
Distillation — a 200B-class model's judgments compressed into an 8B you can serve at a tenth the cost	General reasoning gains — that was pretraining scale, and your 10,000 examples will not move it

3. Behavior Is Not the Only Thing You Are Buying

There are three distinct motives for specializing an agent model, and teams routinely confuse them, which is why they argue past each other in the design review.

The first is quality: the agent is not good enough at the task and no prompt fixes it. This is the motive people say out loud and the one that most often turns out to be false, because the prompt was never seriously optimized and the eval suite was never built.

The second is economics: the agent is good enough, but it runs on a model that costs too much or responds too slowly for the traffic you have. A support triage agent handling 200,000 tickets a month at 6,000 prompt tokens and 400 completion tokens each is a real monthly bill; moving that workload to a tuned 8B served on your own GPUs is often a 10-30x unit-cost reduction with a p95 latency that drops from seconds to hundreds of milliseconds. This motive is measurable before you train, and it is the one that most often justifies the project.

The third is control: you need the model on your hardware, in your VPC, on an air-gapped edge box, or simply not subject to a vendor silently changing behavior under you in the next point release. Regulated deployments live here, and so does anything where a base-model upgrade breaking your prompts is an incident rather than an annoyance.

Write down which of the three you are actually buying before you write the first line of the training script. Quality projects need eval-suite evidence of a behavioral gap. Economics projects need a cost model and a target unit price. Control projects need an infrastructure plan more than they need a dataset. The three have different success criteria, and a project that cannot say which one it is will fail all three.

4. The Decision Ladder

The framework the staff engineer was reaching for. Climb only when the rung below has demonstrably failed, because each step up costs an order of magnitude more in setup, iteration speed, and long-term maintenance:

Prompt and context engineering (hours). Better tool descriptions, few-shot trajectories, explicit stop conditions. Iteration is seconds. Most "model problems" die here as specification problems.
Ground it (days). If the failures are knowledge-shaped — wrong facts, stale facts, your facts — retrieval fixes them and a training run does not. Re-index and the agent is current; retrain and you are current until Thursday.
Escalate or restructure (days). A stronger base model, a reasoning model with a larger thinking budget, or a decomposition into two smaller agents. Buying capability sometimes beats building it — compare costs honestly rather than reflexively.
Change the weights (weeks, then forever). If the behavior is only right with a prompt you cannot afford, or a small model must acquire a large model's reflexes, or the eval gap is behavioral and persistent: now it is justified, and only now.

The gate for step 4 is not a feeling. It is a sentence you can defend with data: "on our 180-case agent eval suite, the best prompt on the best affordable model scores 0.71 task success; we need 0.88; the failures are tool-selection and format, not missing knowledge." If you cannot write that sentence, you do not have a fine-tuning project — you have a missing eval suite, and Evaluation & Benchmarking of Agentic Systems already taught you to build one.

5. What Goes Wrong Inside the Weights

Fine-tuning failures are quieter than prompt failures, because they hide in capabilities you stopped measuring. Four to fear, in roughly the order they will find you:

Catastrophic forgetting. A neural network has no "append" operation: every update overwrites. Train hard on single-turn JSON extraction and multi-turn conversational repair erodes. Train on English incident reports and the model's Spanish degrades. Train on your five tools and general function-calling on unseen schemas gets worse. The optimizer is not malicious, just amnesiac — nothing in your loss said keep the old skills.
Overfitting on a thimble of data. Four hundred examples against an 8B model is memorization territory: training loss near zero by epoch two, parroted phrasings, and brittleness the moment production sends something slightly different.
Distribution lock-in. The model becomes excellent on inputs that look like your training set and measurably worse than the base on everything adjacent. If production traffic is broader than your dataset, you traded robustness for a benchmark.
Eval contamination. You mined training data from production traces, and some of those traces are the same scenarios your eval suite grades. Your numbers go up, your agent does not. This one is specific to the trace-mining workflow this course teaches, it is entirely self-inflicted, and Lesson 4 spends a section on preventing it.

The common thread: every one of these is invisible without before/after measurement on both your target task and a broad general capability probe. That double measurement is Lesson 8's entire subject, and it is not optional.

Your agent's failures cluster on one symptom: it invents endpoint names that do not exist in your API, and the invented names change every week as the API evolves. What does the ladder say?

6. Licenses and Provenance: Read Before You Train

Two legal surfaces, both far cheaper to check now than after the run.

The base model's license. Apache-2.0 releases (much of the Qwen and Mistral lineage) are the least encumbered. Llama's community license adds naming and scale conditions. Gemma's terms permit commercial fine-tuning subject to a use policy. Read the actual text rather than a blog summary, and note that your adapter weights are a derivative of the base — the base's terms travel with them.

The data's provenance. Production agent traces contain customer data, which needs consent coverage and usually needs PII scrubbing before it becomes a training set — territory covered in Security, Safety & Governance of Agents. Synthetic data generated by a hosted frontier model may carry terms restricting its use to train competing models; check the specific provider's terms rather than assuming, and note that the distillation pattern is cleanest when the teacher is a model you are allowed to distill, which is one reason strong open-weights teachers are strategically valuable.

7. The Road Through This Course

With the judgment in place, the rest of the course is craft, in execution order. Lessons 2 through 7 are the SFT foundation: the decision framework in detail, dataset preparation, mining your own production traces into training data, the low-rank mathematics that makes training affordable, and a complete QLoRA run. Lessons 8 and 9 add measurement and preference optimization — proving the tune helped, then training on comparisons rather than demonstrations. Lessons 10 through 13 are the frontier: reinforcement learning with verifiable rewards on real agent tasks, the GRPO recipe behind the reasoning models, building an environment that scores trajectories, and detecting the reward hacking that follows. The capstone project builds a specialist agent model end to end.