A single-step task is easy to supervise. You ask for something, you get an answer, you judge the answer. If it is wrong, it is wrong in front of you.
Long-horizon work does not behave that way. When a system plans, retrieves, calculates, drafts and then acts, each step takes the previous step's output as its input — and takes it as settled. Nothing downstream goes back to ask whether the thing it was handed was true. It builds on it.
That is the whole difficulty in one sentence. An error early in a chain is not an error by the end of it. It is a premise. Everything after it is sound reasoning from a bad starting point, which is exactly why it reads so well.
Why the quiet part matters
A chain is only as reliable as its links multiplied together, and multiplying numbers below one moves in one direction only. Lengthen the workflow and the odds that every step held fall away — even when each individual step is good enough that you would happily accept it on its own.
The arithmetic is the smaller problem. The bigger one is that an error gets tidier as it travels. At the point of the mistake there is usually some hedging attached: a retrieved figure with a source, a classification with a caveat, an assumption flagged as an assumption. A step or two later the hedge has been paraphrased away and the number is simply the number. By the final output it arrives as a finding, with the working gone and the confidence intact.
So the step that makes the mistake and the step where the mistake becomes visible are almost never the same step. That is what compounding quietly means — not that failures are hidden, but that they surface somewhere with no obvious connection to their cause, dressed as a conclusion.
Why end-of-chain review doesn't fix it
The instinct is to check the output. Put a person at the end, have them read it, sign it off.
Better than nothing, and weaker than it looks. At the end there is nothing left to check except the answer, so you are back to grading plausibility — the failure we wrote about last time. The working that would let someone catch the error has been compressed out of the chain along the way. A reviewer at the end is not verifying. They are forming an impression of something that has already been made impressive.
Checking every step has the opposite failure. A checkpoint that fires constantly stops being read. Attention is the scarce input in the whole system, and spreading it evenly is much the same as not spending it.
So where do they go?
Three placements earn their keep.
Where uncertainty would be dropped. The moment a retrieved thing becomes an assumed thing is the moment the hedge disappears. Require the step to carry its source forward rather than only its conclusion, and the error stays visible for longer.
Where the output changes kind. Text becoming a figure, a figure becoming a decision, a decision becoming an action. A wrong word can be corrected by later context; a wrong figure propagates as fact. Type changes are where an error stops being recoverable downstream.
Before anything the system cannot take back. Sending, posting, paying, filing, deleting. We treat that class as needing confirmation per action rather than a blanket approval at the start of a run, because one yes at the top of a chain is consent to a plan and not to what the plan turned into.
Where this sits
Vet, disclose, verify is our operating model, and this is a placement problem inside verify. Verification exists in most AI workflows. It is usually at the end, where the least is left to verify.
If you are moving a multi-step workflow towards production and the checkpoints went wherever they were easiest to add, that is a cheaper conversation now than after the first incident — [email protected]
AI projects fail at evaluation, not at the demo — what a checkpoint is checking against.
The 15-point gate we run before any AI touches a real person — the checkpoints we run before a system meets anyone.
We ran our own governance audit on ourselves. It failed. — a chain of our own, checked late.
TL;DR: In a long-horizon AI workflow an early error is treated as settled by every step that follows, so it arrives at the end as a confident finding with the working stripped out. Reviewing only the final output means grading plausibility again. Checkpoints belong where uncertainty would be dropped, where the output changes kind, and before any action the system cannot take back.