How to train reviewers to write reasons a colleague can follow

A good reason names what was wrong, the fact that shows it, where that fact came from, the rule it breaks and what happens next. Train reviewers to write that through rewrite drills on real reasons, a cold-read test by a colleague on another shift, and weekly scored feedback, until anyone could act on it without asking.

Why do reasons matter so much?

Every time a reviewer declines or edits an agent's draft, the reason is filed in the append-only record. Three people rely on it later. A colleague on the next shift who picks up the case. The builder who decides whether to change the agent's brief, sources or bounds. And an auditor or complaint handler reconstructing what happened months later.

A reason like "wrong" serves none of them. A reason like "Declined: refund requested on an order the ledger shows as already refunded; told customer, no action needed" serves all three. The difference is a skill, and it can be taught in a few weeks.

The team lead owns this training. A senior reviewer acts as marker. The builder joins one session a month to show how reasons turned into changes.

What does a reason a colleague can follow contain?

Teach a five-part pattern and let people compress it once it is habit:

1. Decision. Declined, edited, held for someone else, escalated.
2. The fact. What specifically was wrong or missing.
3. Its source. Where the reviewer saw it: the ledger, the policy library, the customer's message. This mirrors the agent's own provenance stamps.
4. The rule. The policy, limit or red line involved.
5. Next step. What the reviewer did or what the colleague should do.

Not every reason needs all five parts in full. An edit to fix tone might need only "Edited: softened opening for a bereaved customer, per the bereavement guidance." But a decline almost always needs the fact and the source.

The steps

1. Person (team lead): collects 50 real reasons from the last month's record, anonymised, ranging from good to useless.
2. Person (reviewers): rewrite drill. Each person rewrites ten weak reasons using the five-part pattern, then compares versions in pairs.
3. Person (marker): scores each rewrite on whether a colleague could act on it without asking a question.
4. Agent, depth 2: drafts live work as usual; reviewers write reasons on every decline and edit.
5. Person (colleague on another shift): cold-reads a sample of five reasons per reviewer per week and notes any question they would have had to ask.
6. Person (team lead): gives feedback weekly, with one example of the reviewer's best reason and one to improve.
7. Person (builder): shows the team monthly which reasons led to a change in the agent's brief, sources or limits.
8. Agent, depth 1: logs reasons and scores against each reviewer for trend reporting.

What do weak and strong reasons look like side by side?

Show the team pairs like these, all illustrative:

• Weak: "Not policy." Strong: "Declined: agent offered a goodwill credit of 50, above the 30 allowed for this tier in the service policy; offered 30 instead."
• Weak: "Customer unhappy." Strong: "Edited: removed the line blaming the courier, since the tracking record shows our dispatch was late; apologised plainly."
• Weak: "Check this." Strong: "Held for fraud team: delivery address changed by an email the agent marked external, the day before dispatch; not released."

The strong versions are longer, but not much. They take seconds more to write and save minutes for whoever reads them.

Which controls matter, and what evidence do they leave?

• Mandatory reason on declines and edits. Evidence: no decision filed without one.
• Cold-read sampling. Evidence: the sample, the questions raised and the lead's feedback.
• Builder review of reasons. Evidence: the change log linking each brief or source change to the reasons behind it.
• Scores by reviewer. Evidence: a weekly trend for each person.

What should you measure?

Reasons a colleague could act on without asking, out of each week's sample. Reasons containing a source. The number of agent changes traced to reviewer reasons. And repeated declines for the same cause, which should fall as reasons feed changes.

Where does it usually go wrong?

Reasons are marked for grammar. Clarity and the presence of a fact and source are what matter.

Reviewers are told to write more without being shown what good looks like. Examples from their own record teach faster than any guide.

The builder never reports back. If nobody sees their reasons used, reviewers stop bothering. Teams in high-volume sectors feel this sharply; see the arguments in legal services will not scale agents without trained reviewers and payments will not scale agents without trained reviewers.

Shift work makes the cold-read test more important, because the reader may never meet the writer; training reviewers who work different shifts covers the handover side. A short answer to the core question is in training people to give good reasons when they decline a draft. The guide to training teams for AI agents places this skill in a wider programme.

Where the Academy fits

Pryme Intelligence Academy covers writing reasons in the Operator track's modules on human review and teaching the agent, because a reviewer's reason is how the agent improves without anyone changing model weights. The practicum for Certified Pryme Operator is two weeks of real review decisions, and the reasons are part of what a Pryme assessor reads before signing off.