Automate what you can check. Hand off what you can't.

A message at 23:47

Picture a small physiotherapy clinic that runs its bookings over WhatsApp. Late one night, a message comes in. Is there a slot tomorrow morning? An automated reply can answer that in a second, because there's a fact sitting behind it. The calendar either has 9:15 open or it doesn't.

The next message from the same person is different. I've had terrible back pain for a week, is this the right kind of appointment for that? No automation should answer that one, because there's nothing to check. It's a judgment call, and it belongs to whoever actually runs the clinic.

That gap, between a question with a checkable fact behind it and a question that needs a person's judgment, is the whole decision that matters before you automate anything.

Verify first, then hand it over

The clearest version of this rule comes from how some engineering teams now handle bug fixes. An error shows up in a log, or a test starts failing. Instead of asking an agent to just fix it, the process asks one question first. Can it reproduce the problem itself? If it can, the fix only counts once it has confirmed, on its own, that the problem is actually gone, not once the code merely looks right. Only then does it hand the fix to a person for a final look.

Reproduce is the word doing the work in that sentence. An agent that reproduces a bug is working from a fact. An agent that can't is guessing, and a guess dressed up as a finished fix costs more than no automation at all, because someone still has to spend time discovering it was wrong.

The same split works for a business that has nothing to do with code. Whatever your version of reproducing the bug is, an available slot, a stock count, an order status, automation can own it end to end. Whatever requires judgment, how urgent a complaint sounds, whether a discount is fair, what a customer actually meant, still needs a person.

The failure nobody warns you about

I run an agent team that builds and maintains our own site, and the mistake I've actually watched happen, more than once, isn't an agent shipping something broken. It's an agent doing real work, getting most of the way there, and then quietly stalling. A pull request gets opened and never finished. A fix gets half applied. From the outside, the thread looks active. From the inside, nothing shipped, and nobody notices for a day or two because the last comment still reads like progress.

We ended up building something whose only job is to come back later, on its own schedule, and check whether work that looked finished actually was. It doesn't do any of the work itself. It just refuses to let something that looks done pass as something that is done. That one addition caught more real problems than any amount of tightening our original instructions did.

The clinic version of the same failure is a WhatsApp thread that got a promise to follow up, and then genuinely didn't, because everyone assumed someone else had it. The fix isn't a smarter bot. It's a habit, or a tool, that checks back on anything left hanging.

The problem that keeps coming back

There's a second layer worth building once the daily loop is working. Call it a weekly look at what's recurring. A single stalled reply is a one-off. The same kind of complaint showing up every Friday for a month is a pattern, and it's usually invisible if you only ever look at one case at a time. Once a week, it's worth asking what kept happening even after you thought you'd fixed it, because that's where the real fixes live, not in the individual case but in whatever keeps producing it.

Where I'd start

Pick one thing in your business you already know how to check for certain, a calendar slot, a stock level, whether a form was filled out completely. Let automation handle only that, end to end, and route everything else to a person, including anything that sounds even slightly like a judgment call.

Then try this. Open Claude and hand it your last ten customer messages, from WhatsApp, email, wherever you get them. Ask it to sort them into two piles, ones with a checkable fact behind them and ones that need a real decision. You'll probably be surprised at how small the first pile actually is, and that's the useful part. It tells you exactly where automation earns its keep, and exactly where it shouldn't.