Fine-tuning

Fine-tuning changes the model itself. Instead of telling a model how to behave in a prompt on every turn, you train it on hundreds or thousands of example exchanges until the behavior is part of its weights. In the context of voice and chat agents it is the heaviest of the three ways to shape an agent, after prompting (including few-shot examples) and retrieval, and for most business deployments it is the one you do not need.

How it works. You assemble a dataset of input and ideal-output pairs: customer messages and the replies you want, or transcripts and the summaries you want. The pretrained model is trained further on that dataset, adjusting its weights so the examples' patterns become the default. The output is a new model version that runs with a shorter prompt and produces the trained behavior without being shown examples. Costs are the labeling work, the training run and, from then on, hosting and re-running the process whenever the base model is upgraded, since fine-tunes do not transfer between model versions.

Why it matters for the build-versus-configure decision. Fine-tuning is sold as a way to make an agent 'know your business'. It is a poor fit for facts: prices, hours and policies change, and a fine-tuned fact is frozen until the next training run. It is a reasonable fit for style and structure at scale: a specialized vocabulary (medical coding, legal intake), a strict output schema used millions of times, or a tone that prompts cannot reliably hold. The decision rule most teams land on is: documents for facts, prompts and examples for behavior, fine-tuning only when both have been tried and the gap is measurable.

Example. A healthcare clinic network wants its intake agent to summarize each call into a structured note using its own section headings and abbreviations. Prompting with three examples gets the format right most of the time but drifts on long calls. After six months of operation the team has 4,000 reviewer-corrected summaries, which is enough to fine-tune a model on the summarization task alone. The fine-tuned summarizer runs after the call; the conversational agent itself stays on a general model with retrieval, because the clinic's services and insurance lists keep changing and must stay in documents.

Fine-tuning vs RAG. Retrieval changes what the model reads; fine-tuning changes how the model behaves. Retrieval updates in minutes by editing a file and keeps a traceable source for every answer; fine-tuning updates in days and gives no citation for anything the model learned. If the question is 'how do I get the agent to answer from our documents', the answer is retrieval. If the question is 'how do I get the agent to always write in this exact form', fine-tuning is on the table once examples are plentiful.

Common pitfalls.

• Training facts into the model that then go stale, with no way to see which answers came from training.
• Datasets built from unreviewed transcripts, which teach the model the mistakes along with the style.
• Losing general capability: a narrowly fine-tuned model can get worse at everything outside its dataset.
• Vendor lock: a fine-tune lives on one provider's model and cannot move.

Botcadence agents are grounded through document training and per-agent instructions, so a changed price or policy takes effect by updating the document; see chat agents and RAG.