Journal · The AI Architect · 2026-09-03
Know when to call a human expert. The moment something must run trusted, unattended, and high-stakes, that's the line.
Know when to call a human expert. The moment something must run trusted, unattended, and high-stakes, that’s the line.
The tension is not “AI versus human.” That framing sounds sensible and misses the actual problem, which is that most of us don’t notice when a system quietly crosses from “assisting” into “deciding.” You start by asking the assistant to draft an email. A month later it’s drafting, sending, and archiving without you reading the thread. Nobody chose that shift on purpose. It just accumulated, one convenient default at a time. The real skill isn’t knowing that humans matter — everyone nods along to that. It’s noticing the specific moment your setup slid past the line, usually well after it happened.
Name the three conditions separately
The line isn’t a feeling, it’s a checklist, and it works better when you stop treating “risky” as one blurry category. Ask three separate questions about anything you’re about to automate:
Is it trusted — meaning the output gets used without a second look, by you or by whoever’s downstream? Is it unattended — meaning it runs on a schedule, a trigger, or a queue, with no human watching it happen in real time? And is it high-stakes — meaning a bad output costs real money, real time, real trust, or is hard to undo?
Any one of these alone is usually fine. A trusted, attended, low-stakes task — like an assistant summarizing your inbox while you sit there and skim it — is comfortable territory. An unattended, low-stakes, low-trust task — like a script that drafts blog ideas overnight for you to reject in the morning — is also fine. The danger zone is the overlap of all three. That’s the line the quote is pointing at.
Try this: take one automation or AI workflow you already have running — a newsletter drafter, an email responder, a scheduling bot — and score it 1 to 3 on each dimension. If it scores high on all three, you’ve found something worth a second look this week, not eventually.
Build a checkpoint, not a wall
The instinct, once you spot a risky workflow, is to either shut it down entirely or shrug and let it ride. Neither is quite right. The useful move is inserting a checkpoint — a deliberate pause where a human has to look before the consequence lands.
A checkpoint doesn’t mean reviewing everything the system does. That defeats the purpose of automating in the first place. It means picking the one or two moments where a mistake becomes expensive or irreversible, and putting a human there specifically. If your system drafts vendor contracts, the checkpoint isn’t “read every draft” — it’s “a person signs off before anything is sent to the vendor.” If it manages customer refunds, the checkpoint might be “auto-approve under a set amount, flag everything above it for a person.”
This is different from micromanaging the tool. You’re not watching it work. You’re deciding, in advance, which specific outputs need a human eye before they become real-world actions. Most of the workflow can stay fast and automated. Only the narrow, costly slice needs a person standing at the gate.
Try this: for the workflow you scored above, write down the single output or action within it that would be hardest to undo. Put a name — yours or someone else’s — next to that step as the required check, even if everything else stays automated.
Expertise is a different thing than attention
There’s a subtler trap here. Sometimes people add a human checkpoint and feel safe, but the human involved isn’t actually qualified to catch the failure. Having someone glance at the output isn’t the same as having someone who understands what a bad output looks like. A checkpoint staffed by someone without the relevant judgment is a checkpoint in name only — it slows things down without adding real safety.
So the honest version of “know when to call a human expert” includes a second clause most people skip: know which human, and know they’d actually notice if something were wrong. If the stakes are legal, that’s a lawyer, not whoever’s free. If the stakes are technical, that’s someone who understands the system’s failure modes, not just its happy path.
This essay only gets you as far as noticing the line and building a first checkpoint. The harder, more interesting work — how to design checkpoints that scale as a workflow grows, how to tell when you’ve outgrown your own judgment on a given task, how to build review habits that don’t quietly erode over time — is where the book spends more time, because those are the places people actually get burned. For now, the checklist and the one deliberate pause are a solid place to start.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.