There are three distinct strategies for making an AI model better at a specific job. Each works differently, costs differently, and produces a different kind of asset. Here is a clear map of all three — what they do, what you get, and when each one is the right call.
Why generic AI underperforms on your work
A frontier model trained on the internet is optimised to be useful to everyone. That generality is a liability for any organisation that has a specific, repeatable, high-stakes process. It does not know your terminology, your edge cases, your quality bar, or your definition of a good outcome. Every interaction starts from scratch.
The three optimisation strategies below are all answers to the same question: how do you take a general-purpose model and make it genuinely good at your particular job? They differ in how they work, how much they cost, and what kind of asset they leave behind.
Strategy A: Prompt and skill tuning
What it does
Prompt tuning treats the choice of prompt as an optimisation problem. Rather than iterating by hand, a genetic search process generates candidate prompts, scores them against evaluation metrics drawn from your production traces, selects the best performers, mutates and recombines them, and repeats. The result is a prompt — or a structured set of skills — that has been systematically searched rather than guessed at.
At Gradient Disco we run this using GEPA (reflective genetic-Pareto optimisation) built on top of DSPy, which provides the evaluation framework and optimisation loop.
What you get
Tuned prompts and skills stored in your versioned artifact registry. No model weights are changed. The underlying model stays external — you are optimising the instructions, not the model itself.
When it is the right choice
- You need fast iteration — an optimisation run takes hours, not days
- You do not have GPU infrastructure and do not want to build it
- The model is changing frequently and you need to re-optimise against new versions
- You are in the early stage and are still learning what "good" looks like
Cost and data requirements
Roughly $2–10 per optimisation run. No GPU required. You need a production trace — real inputs and outputs from your system — and an eval metric you can score against. A few hundred examples is enough to start.
Strategy B: Supervised fine-tuning
What it does
Fine-tuning adjusts the model's weights directly using curated input-output pairs from your domain. The model is not being given better instructions — it is being changed. After training, it has absorbed your domain knowledge into its parameters. LoRA and QLoRA techniques make this practical without training the full model: you train a small adapter that sits on top of the base weights, which dramatically reduces the compute and memory required.
What you get
A proprietary model checkpoint in your artifact registry. This checkpoint runs on your infrastructure, costs nothing per-token beyond your own compute, and does not depend on any external API. It is yours.
When it is the right choice
- You have consistent domain performance requirements and can collect labelled examples
- You want to run the model on your own infrastructure — for cost, latency, or data privacy reasons
- Your task is well-defined enough that input-output pairs are meaningful
- You are running at volume where API costs are becoming a real concern
Cost and data requirements
Single-GPU-class compute — a modern A100 or equivalent for a few hours. You need labelled input-output pairs: ideally several hundred to several thousand, depending on task complexity. The data quality matters more than the quantity.
Strategy C: Agent reinforcement learning
What it does
Reinforcement learning takes a different approach to feedback. Instead of requiring labelled examples of correct behaviour at every step, it learns from outcomes. You define what a good result looks like — an LLM judge (we use RULER) evaluates completed episodes — and the model learns a policy that maximises those outcomes across sequences of decisions. GRPO (Group Relative Policy Optimisation) makes this tractable for language models without requiring a separate value network.
What you get
An RL-tuned policy in your artifact registry. This policy has learned not just what to do in simple cases, but how to sequence decisions, when to retry, and how to recover from partial failures — things that are extremely difficult to capture in labelled examples.
When it is the right choice
- Your workflow involves multiple steps and you cannot hand-label every intermediate decision
- You can define good outcomes but not good processes
- You have production volume — RL improves with every episode, so more interactions means faster improvement
- You want a system that compounds over time rather than staying static
Cost and data requirements
Higher than prompt tuning, comparable to fine-tuning for the initial run, but the key input is not labelled data — it is production rollouts. The system generates its own training signal from real interactions.
The three tracks are not mutually exclusive
The most capable production AI systems use all three strategies at different layers. Prompt tuning establishes the baseline and keeps pace with model updates. Fine-tuning compresses that knowledge into a faster, cheaper, private checkpoint. RL then trains the policy on top of the fine-tuned model using real production outcomes.
Each strategy produces a versioned artifact — prompts, checkpoints, policies — that goes into the same registry. They compose. And each subsequent optimisation cycle has more signal to work with than the last.
The goal is not to pick one strategy and stick with it. The goal is to accumulate AI capital that compounds — assets that get better every time you run the loop.
The next three posts go deeper on each track: how prompt tuning actually works, what fine-tuning a small model requires in practice, and how reinforcement learning can train an agent from production outcomes alone. If you want to talk through which track makes sense for your current situation, get in touch.