Notes from the workbench.

Teams spend weeks debating which model to use and almost no time on how they will know whether their agent is any good. That is backwards. The single strongest predictor of a reliable agent is not the model behind it — it is the quality of the test set the team runs against it. A good evaluation set is a collection of real cases with known-good outcomes, graded automatically on every change. It turns a vague feeling of "this seems better" into a number you can defend to a stakeholder.

Without evals, every model upgrade is a leap of faith and every prompt tweak is a guess. With them, you can swap models freely, because you can prove in an afternoon whether the new one is better on the cases you care about. We have watched a mid-tier model with a sharp eval harness comfortably outperform a frontier model wired up on vibes, simply because the team could see and fix its failures. Build the test before you fall in love with the technology. The model will change three times before your problem does.

The two techniques get confused constantly, and the confusion is expensive. Here is the rule we use. Retrieval-augmented generation is for knowledge: facts that change, that must be cited, and that the agent should not be trusted to memorise — your policies, prices, product details, support history. Fine-tuning is for behaviour: a consistent tone, a specific output format, a way of reasoning that is hard to describe in a prompt. Ask what is failing. If the agent is confidently wrong about facts, you have a retrieval problem, and no amount of fine-tuning will fix it — you will just teach it to be wrong more fluently.

If the agent knows the facts but formats them badly or drifts off tone, that is a candidate for fine-tuning, though a better prompt often solves it first and far more cheaply. Most production agents we build are mostly retrieval, occasionally fine-tuned, and always evaluated. Reach for RAG by default; it keeps knowledge outside the model where you can update it in minutes rather than retraining for days. Fine-tune only when you have hit a wall that prompting and retrieval genuinely cannot climb.

Autonomy is a dial, not a switch, and where you set it should be a deliberate design decision rather than an accident of what was easy to build. The interesting question is never "can the agent do this alone?" but "what does it cost to be wrong here, and how quickly can a human catch it?" A support agent drafting a reply that a person approves before it sends is a very different risk than one issuing refunds unsupervised. Same technology, completely different guardrails.

We design explicit hand-off points: moments where the agent must pause and defer because the stakes are high, its confidence is low, or the action is irreversible. Done well, these are not a sign of a weak agent — they are what makes a strong one deployable. The humans reviewing those cases are also your best source of new evaluation data; every correction they make is a labelled example of where the agent needs to improve. Over time the dial can turn up, case by case, backed by evidence rather than optimism. That is how autonomy should grow: earned, measured, and reversible.