Retrieval, agents or fine-tuning: which specialist does your problem need?
6 minute read. Updated 2026-08-08.
Match the symptom to the technique before you hire. If the model doesn't know your business, that's a retrieval problem, fixed by a data engineer and a generative AI specialist, not a fine-tuning job. If it needs to take multi-step actions across systems, that's agent orchestration, needing MLOps and software engineering skill. Fine-tuning is for narrow, stable tasks like tone or format, and it is chosen far more often than it is actually needed.
Get the technique right before you get the hire right
Companies often start a hiring process with the technique already decided, usually fine-tuning, because it sounds like the serious, bespoke option. That decision is frequently wrong, and it is expensive to be wrong about, because fine-tuning needs a different specialist, a different data pipeline and a different ongoing cost than retrieval or agent-based approaches do.
The fix is a short diagnostic before you write the job spec: what is the symptom, and which technique actually addresses it. Get this step right and the hire mostly chooses itself.
Symptom: the model doesn't know our stuff. Fix: retrieval, not fine-tuning.
If the complaint is that a general-purpose model gives generic answers, or gets your policies and pricing wrong, the usual cause is that the model has never seen your data, not that its underlying behaviour is wrong. Retrieval, feeding relevant documents into the model at the point of answering, fixes this directly, and updates the moment your underlying documents change.
This is a data engineering and generative AI problem, not a model-training problem. You need someone who can build and maintain the retrieval pipeline, advertised at a median £500 a day for data engineering, alongside generative AI expertise, advertised at a median £550 a day, over the six months to August 2026. Fine-tuning a model to memorise your product catalogue means retraining every time the catalogue changes. Retrieval just means updating a document store.
Symptom: it needs to do things, not just answer questions. Fix: agents.
If the requirement is multi-step: check a system, decide what to do next, call another system, then confirm the outcome, that is an orchestration problem, usually described now as agentic. It needs someone comfortable with both the model side and the software engineering side, wiring tools together reliably and handling the cases where a step fails partway through.
This sits closer to MLOps, advertised at a median £575 a day, than to pure model work. The hardest part is rarely the model call itself; it is the plumbing around it, retries, logging, and knowing when to hand a decision back to a human rather than let the agent keep going.
Symptom: it needs to sound like us, or handle one narrow task perfectly. Fix: fine-tuning, and only then.
Fine-tuning earns its place when the task is narrow, stable, and prompt engineering genuinely cannot carry it. Consistently applying a specific tone across large volumes of short outputs, or performing a single repetitive classification task at a level plain prompting cannot reach, are reasonable fine-tuning cases. This is genuine data science and machine learning engineering work, advertised at median day rates of £600 and £575 respectively.
It is chosen far more often than these narrow cases justify, because it sounds like more serious, more bespoke work than 'we fed it better documents'. Prompt engineering and retrieval are less impressive to describe in a board meeting and considerably cheaper to run. That is not a good reason to pick the more expensive, harder-to-maintain option.
Why the wrong choice costs more than the wrong hire
Fine-tuning done where retrieval would do commits you to retraining every time your underlying facts change, plus a specialist skill set to manage that cycle. Retrieval done where fine-tuning was genuinely needed leaves you with a model that never quite gets the tone or the narrow task right, however good the documents you feed it. Both mistakes are recoverable, but both cost real weeks of the wrong specialist's time before anyone notices the mismatch.
The tell is usually visible early, if anyone looks. A fine-tuned model that keeps needing retraining every few weeks as prices or policies shift is a sign the wrong technique was chosen. A retrieval system that answers accurately but never quite sounds like your brand, however good the source documents, is the opposite signal. Neither is a disaster, but both are avoidable with a proper diagnostic before the hire is made.
The decision rule I would use
Default to retrieval for anything about knowledge: policies, pricing, product detail, anything that changes. Reach for agents when the job involves multiple steps across systems, not just an answer. Reserve fine-tuning for narrow, stable, high-volume tasks where prompting and retrieval have already been tried and genuinely fall short. If nobody in the process has tried prompting and retrieval first, that is reason enough to stop and ask why fine-tuning is even on the table.
None of this needs to be complicated to get right. Write down the symptom in plain language, ask which of the three techniques actually addresses it, and only then decide which discipline and which day rate you are hiring against. The specialists exist for all three; the mistake is asking the wrong one to solve a problem that was never theirs to fix.
What to do about it
- Run the symptom-to-technique diagnostic before writing the job spec.
- Treat 'the model doesn't know our stuff' as a retrieval problem first, not a fine-tuning problem.
- Reach for agent orchestration only where the task genuinely spans multiple systems and steps.
- Reserve fine-tuning for narrow, stable, high-volume tasks that prompting and retrieval have already failed on.
- Be sceptical when fine-tuning is proposed before retrieval and prompting have been tried.
- Match the hire's discipline to the technique the symptom actually needs, not to the most impressive-sounding option.
Questions people also ask
Isn't fine-tuning just better overall, since it changes the model itself?
Not for most business problems. Fine-tuning is genuinely better for narrow, stable tasks at high volume, but it means retraining every time your underlying facts or policies change, and it needs a specific skill set to manage that cycle. Most complaints about a model 'not knowing our business' are actually retrieval problems: the model has never seen the relevant documents, not that its core behaviour is wrong.
Can one specialist cover retrieval, agents and fine-tuning?
Some can, particularly at the generative AI or machine learning engineer level, but breadth like that tends to come with a corresponding day rate, and depth on any one of the three usually trades off against the others. For a single, well-defined problem, hiring for the specific technique the symptom needs is usually more reliable than hiring for broad coverage and hoping it includes what you need.
How do we know if our vendor or candidate is defaulting to fine-tuning when we don't need it?
Ask what they tried before proposing fine-tuning. If the honest answer is nothing, prompting and retrieval were never tested, that is worth challenging. A specialist who has genuinely diagnosed the problem should be able to say why prompting and retrieval fall short for your specific case, not simply that fine-tuning is the more thorough-sounding option.
Does agentic work need a different kind of specialist to retrieval work?
Largely yes. Retrieval work leans on data engineering and generative AI skills, building and maintaining a document pipeline. Agentic work leans more on MLOps and software engineering, wiring tools together reliably and handling failure cases across multiple systems. There is overlap, but a specialist strong in one is not automatically strong in the other.
Where the figures come from
Every rate and salary quoted in this article is a median or percentile of figures advertised in UK job postings over the six months to 8 August 2026. They are not rates paid, and the gap widens at the top of a range.
- IT Jobs Watch, UK contract rates, 6 months to 8 August 2026, read 2026-08-08.
- IT Jobs Watch, UK permanent salaries, 6 months to 8 August 2026, read 2026-08-08.