Ask one AI prompt to research, write and polish a report and you get something plausible, mediocre and unaccountable. Ask three narrow steps to do it - one gathering, one drafting, one checking - and you get something you can actually use, improve and trust. That three-step shape is the pattern we teach first, because it fits an enormous amount of knowledge work. It is worth understanding properly.
The scout: gather before you generate
The scout’s only job is to collect the raw material: pull the figures, find the documents, extract the relevant passages, list what changed since last time. It produces no prose and makes no judgements - it assembles the evidence the next step will work from.
Separating this out matters because most bad AI output fails at the input, not the writing. A model asked to draft from nothing invents; a model asked to draft from a scout’s evidence pack has something true to say. When a workflow goes wrong, the scout’s output is the first place to look - and because it is a separate step, you can look.
The drafter: one version, from the evidence
The drafter turns the scout’s material into a first version of the thing you actually need: the summary, the report section, the reply, the comparison. It works only from what the scout gathered, in the shape and voice you have specified.
Keeping the drafter narrow is what makes it good. It is not deciding what matters or checking itself - it is doing the one thing models do best, turning structured material into clear prose, with the ingredients already on the bench.
The reviewer: check against a standard, in writing
The reviewer reads the draft against a stated standard before any human sees it: is every claim supported by the scout’s material, does it follow the format, did it answer what was asked, does it break any of your rules. It flags or fixes what fails.
This is the step people skip, and it is the step that makes the whole thing trustworthy. A pipeline that drafts and stops produces work you must check line by line, which quietly costs the time you saved. A pipeline that checks its own draft - and shows you what it checked - produces work you can review at a glance. Writing the standard down is also clarifying in itself: it forces you to say what good actually looks like, which most of us have never put into words.
Why three narrow steps beat one clever prompt
Three reasons, all practical:
- You can see where it went wrong. One giant prompt fails as a blob; a pipeline fails at a step, and you fix that step.
- Each step can be improved alone. A better scout raises the quality of everything downstream without touching the drafter. Improvements compound.
- Trust is earned per step. You will trust the scout’s gathering long before you trust anything’s judgement. The pattern lets you hand over the parts you are ready to hand over and keep the rest.
The pattern also places the human deliberately: after the reviewer, at the point of judgement - approving, correcting, deciding - rather than in the middle, retyping context between tools.
Where it fits, and where it does not
Anything with the shape gather, produce, check is a candidate: the weekly report, the meeting minutes, inbound triage, first-draft anything, the comparison you rebuild every month. That is most repeated knowledge work.
It is the wrong shape where the output is a judgement about a person, where being subtly wrong is expensive and hard to spot, or where the task runs on information you cannot give the scout. Those are the tasks to keep, not to force into the pattern.
Will this still be true when the tools change?
The tools move every few months, so the question is a fair one: how much of this has a shelf life.
Does what I learn go out of date in six months?
Some of it does, and it is the part that matters least. Which agent you opened, where the button sat, what the menu was called in April - all of that moves, and quickly. The shape does not, because gather, produce, check describes the work rather than a product. A report that needs its evidence assembled before anyone writes prose needed that before these tools existed and will need it after they have been replaced. What the pattern actually makes you do is write three things down - what the scout may use, what the drafter is for, and the standard the reviewer checks against - and not one of them is an instruction for a particular tool. It is also why no tool is being sold on the day itself. A day built around a product dates when the product does.
If the models keep getting better, will one prompt not just do it?
The models have got better and the split has not stopped earning its keep, because the reasons for it were never mainly about the model being weak. You keep the steps apart so you can see which one went wrong, improve one without disturbing the others, and hand over the parts you have come to trust while keeping the rest. A better model makes each of the three steps better and leaves all three reasons standing. The honest version: for a small job nobody else depends on, a strong model can do the lot in one pass, and you should let it. From the moment someone else relies on the output, you will want to know which step produced the sentence you are being asked about.
Should I wait until the tools settle down?
They are not going to settle, so waiting is a decision to carry on without anything running rather than a decision to get something better later. It also improves the half that was never the constraint. What decides whether one of these is worth the effort is the task you point it at, which is your own and is not changing, and choosing that task well is the part most people get wrong. There is a longer version of the same argument about waiting for the right cohort, and it ends in the same place.
Where this gets practical
Reading about the pattern and having one running against your own work are different things, and the second one is a day’s work with someone on hand. That is what the Oxford Agentic Bootcamp is for: you bring one real task, build the scout, the drafter and the reviewer against it, and leave with the pipeline running and a written recipe to rebuild it. No coding required.