WritingThe two loops every AI process needs

The two loops every AI process needs

An AI process without a human on the judgment and a loop that learns from its misses isn't a finished system. It's a liability that looks fine in week one and rots by month six.

Two loops — and most builds have neither

Every AI process that holds has two loops around it, and they do different jobs. The review loop runs in real time: a human checks or approves the output before anything consequential happens. The feedback loop runs over time: the misses get captured and fed back so the system improves instead of repeating itself. Most builds ship with neither — the demo worked, so it goes live and everyone walks away. That’s the single biggest reason AI ‘works,’ then quietly stops being trusted, and most of what I mean by applied AI is closing that gap.

The review loop: a human on the judgment

Human-in-the-loop doesn’t mean a person checking everything — that just moves the bottleneck and defeats the point. It means a person on the decisions that matter, and the AI running free on the ones that don’t. Match it to what a mistake actually costs:

Type of actionExampleThe human’s job
Reversible, low-stakesInternal draft, tagging, sortingNothing, or an occasional spot-check
Customer-facingA reply, a quote, an outgoing emailRead and approve before it sends
Irreversible or costlyA payment, a filing, a deletionApprove every time, no exceptions

The feedback loop: how it gets better, not worse

The review loop catches today’s mistake. The feedback loop stops you making it forever. Every time a human corrects or overrides the AI, that’s not just a fix — it’s a labelled example of exactly what the AI got wrong, and it’s the most valuable signal you have. Capture those, group them into named patterns, and feed them back into the prompts, rules, and routing. Do that and the system sharpens month over month. Skip it and it repeats the same errors until people give up on it. This is the Group / Present / Feedback method, and it’s the part nobody else owns.

Why ‘set and forget’ is the crappy option

A process with no review loop can’t catch its own mistakes; one with no feedback loop can’t stop repeating them. Put those together and you have something that looks great in the demo and is actively misleading by month six — confidently wrong, unsupervised, and getting no better. ‘Set and forget’ isn’t efficiency. It’s how you end up with a process everyone has quietly learned not to trust.

Designing loops people will actually use

Loops fail when they’re heavy. Make the human’s job small and fast — approve, reject, or correct in one click, never redo from scratch. Route only what genuinely needs eyes, so the queue stays short. And make capturing feedback a byproduct of the review itself: the correction the human makes is the feedback, logged automatically, not a separate form nobody fills in. A loop that costs more than it returns gets abandoned — and then you’re back to set-and-forget.

So, what should you do?

If you’ve got AI running with no human on the irreversible calls, or no way to capture and learn from what it gets wrong, you’ve got a demo in production. Putting the two loops around it — light enough that people actually use them — is what turns it into something you can rely on. That’s the conversation.

The loops themselves are small — a review surface and a feedback path, named and assigned. Most of the work is deciding where they belong, and that goes faster with someone who’s installed them before.

Talk to me →