There's a natural point where every automation effort arrives at the same question. It works. It's fast. It hasn't made a mistake yet. Should it also be the one that decides?
Most answers to that question come from the wrong direction. One camp says stop worrying, the system has proven itself, let it run further. The other says never let a machine make a real decision, keep a person in every step no matter how repetitive. Both answers are about capability. Neither one is about where the boundary actually belongs.
The line is about accountability
Push the question hard enough and it becomes obvious. If the boundary is set by what the system is good at right now, the boundary moves every time the system gets better. A boundary that moves is a temporary limit waiting to be crossed. A rule that erodes the moment the tool improves is a placeholder for a rule someone hasn't decided yet.
The actual boundary is about what happens on the other side of the action. Somewhere between gathering the information and sending it, there's a moment where something leaves your walls and lands on someone else. Money moves. A customer sees a message with your name on it. A commitment gets made that you're now on the hook for. That moment is the line, and it doesn't move no matter how reliable the system gets, because the question is about who is answerable for what happens next.
Put concretely: drafting the customer email is on one side of the line. Sending it is on the other. Preparing the wire is on one side. Executing it is on the other. Flagging that something looks off is on one side. Telling the customer their order is delayed, on your authority, is on the other. Every one of these pairs looks nearly identical from the outside, right up until the second half happens and can no longer be taken back.
The decision is small, the exposure is total
The obvious objection is that gatekeeping every consequential action defeats the purpose of automating anything. If a person has to sign off before the message goes out, what did the automation actually save?
Nearly everything, as it turns out, once you look at where the hours actually went. The research that used to take an afternoon. The draft that used to take twenty minutes to start from a blank page. The sorting, flagging, and cross-checking that used to eat the morning before anyone got to the actual call. All of that is upstream of the decision, and all of it can be handled without a person watching every step. What's left, at the very end, is a single moment where someone looks at the finished thing and says yes or no. That moment is short. It might be the shortest part of the entire process.
It's also the only part where the exposure lives. Everything before it is reversible. A wrong guess in a draft costs nothing, because nobody outside has seen it yet. The moment it goes out, that stops being true. So the math isn't close. Automating everything up to the decision returns almost all the time savings. Automating past it removes the one checkpoint that was actually protecting you, in exchange for a sliver of additional speed.
There's a tempting counter here, which is that mistakes can usually be fixed after the fact. An email can be followed by a correction. A wrong commitment can be walked back with a phone call. That's true, and it's also beside the point. Fixing a mistake after a customer has already seen it costs goodwill, time, and often the relationship's benefit of the doubt, none of which show back up on the balance sheet as a line item. The correction is real work, and it's work that did not exist before the mistake shipped. Reversible in principle is not the same as free.
Permanent, not provisional
This is why the boundary holds regardless of how the tools improve. A system that hasn't made a mistake yet can still make one, on the one case nobody thought to check, at the one moment nobody was watching. The cost of that single miss, landing on a real customer or a real dollar, outweighs the accumulated savings of every instance where nothing went wrong. That arithmetic doesn't change as the system gets better. It just gets easier to forget, because a long run of correct outcomes starts to feel like proof the checkpoint is no longer needed. It's proof of the opposite. The checkpoint hasn't been tested yet. It's been waiting.
Automate aggressively everywhere except the one place where somebody else pays for the mistake. The line is drawn by who's answerable when it's wrong, and that answer doesn't change with the next release.