You learn it the moment you hand someone real work. Skill shows itself less in how fast someone moves and more in where they pause and say, "Let me check with you before I do this." Any team lead who has worked with a junior will nod along. The person who stops at exactly the ambiguous spot to ask turns out to be more dependable than the one who just gets everything done. A pair of hands that doesn't know when to stop is more dangerous the faster it moves.
It's the same with an AI project manager. Across the whole flow — taking in a request, classifying it, executing, verifying, and reporting back — there are hidden forks at every turn where it has to decide: do I keep going, or do I hand this to a person? I want to talk about how ONTLE handles that judgment, and why the "ability to stop" matters as much as raw throughput.
Judgment about when to stop fails in both directions.
One extreme is an AI PM that stops too often. It asks about every little thing — "Should I do it this way, or that way?" For the first couple of times it looks diligent, but the person on the other end quickly wears out. If the requester ends up having to make every decision anyway, automation loses its point. Instead of handling the work for you, it has created a new chore: pressing an approval button at every single step. A tool that keeps asking back isn't convenient — it's a nuisance.
The other extreme is an AI PM that doesn't know how to stop. When things are ambiguous, it just pushes ahead in whatever direction seems plausible. If the request says "tidy this up as you see fit," it acts on its own imagined version of "as you see fit." If you're lucky, it's right; if you're not, an off-target result gets reported as complete. Worse is when that result is the kind you can't take back — an email that's already gone out, deleted data, a setting that's already been applied. For these, "we'll just redo it" doesn't work.
So the makings of a good AI PM are paradoxical. It has to have both the ability to carry things through on its own and the ability to stop at the decisive moment. Being good at only one of the two is half a tool.
So what should decide when it stops? The first test ONTLE leans on in practice is simple: can this action be undone?
Things that can be undone are usually better to just push through. Drafting, organizing material, polishing on-screen copy, running a calculation — most of these fall here. If you don't like the result, you redo it. Seeking approval every time for work like this turns you back into the "nuisance tool" described above. Here, the requester is better served if the AI exercises judgment, gets it done, and shows the result.
Things that are hard to undo are the opposite: outbound messages, anything involving payments or credits, deleting or overwriting data, touching accounts, permissions, or identity, and actions that affect other people. For these, the rule is to stop before executing and get a person's confirmation. Even if you lose a little speed, the cost of a single accident dwarfs that loss. Messages sent to people especially can't be counted on to be recalled or the damage undone once they're out. Some mail systems do support limited recall under specific conditions, but there's no guarantee you can smooth over a wrongly sent email with a "never mind, I cancelled it."
What's good about this test is that it keeps the AI from judging by the strength of its own conviction. "I'm fairly sure this is right" is a dangerous signal. Even with high confidence, if something can't be undone, it should stop; even with low confidence, if it can be undone, it can go ahead and show the result. The point is to shift the axis of judgment from "how sure am I?" to "how much will it hurt if I'm wrong?" That shift is the heart of safe automation.
The second test is ambiguity in the request itself.
When a request is missing information, an AI that doesn't know how to stop fills the blank with its own guess. It looks helpful at a glance, but if the guess is wrong, everything built on top of it collapses. What makes it worse is that, looking only at the result, you can't tell which parts are guesses and which are facts. The more polished the result looks, the harder its hidden assumptions are to spot.
This is where it splits. If the blank is within the range of what can be undone — say, the tone of a report or the order things are arranged in — the AI handles it with a reasonable default and states "I assumed this" in the result. The requester looks it over and, if it's off, just undoes it. But if the blank is the kind that changes the whole direction of the outcome — who to send something to, what data to delete, what value to set — it must not be filled in with a guess. In cases like these, the AI PM should stop and hand that blank back to the requester.
The key is not to quietly swallow the ambiguity. A well-built AI PM doesn't hide what it doesn't know — it surfaces it. "I don't know" isn't a weakness; it's a basis for trust. In practice, a result that points out "I'm not certain here, so this needs confirmation" is far more useful than one that smoothly glosses over everything while pretending to know it all.
Customers using the ONTLE screens watch their work flow through a handful of statuses. Among familiar ones like Received/Under Review, In Progress, and Done, there's one that's a little special: Waiting on a Decision.
This doesn't simply mean "the work is stalled." It's the state where the AI PM has concluded that, by its own judgment, it shouldn't go any further here, and has handed decision authority back to a person. When a task hits either of the two tests described above — it can't be undone, or there's direction-changing ambiguity — it enters this state. And from here, it moves again only once a person responds.
There's a reason this state gets its own slot: the stop has to be visible to a person. If the AI judges internally and quietly waits, the requester can't tell whether it's working or stuck. The moment you attach the label "Waiting on a Decision," the stop stops being neglect and becomes an explicit request — a signal that says "your turn." A good stop isn't silence; it's a clear handoff.
And this status honestly exposes the line where the roles of human and AI divide. Reversible judgments, repetitive execution, organizing material — the AI takes these on. Decisions that set direction, choices that carry responsibility, judgment that lives outside the available context — those belong to a person. "Waiting on a Decision" is the state that stands on that boundary and says, "from here on, it's you."
If everything so far was about the AI's side, the last part is about the human's. For an AI PM to stop well, there has to be a person who reads that stop well.
When the AI hands something off as "Waiting on a Decision," it's usually the most important fork in that request — the point that can't be undone, or that swings the direction. If you brush it off with "why does it keep asking?" and wave it through, you end up letting slip the very thing a person was supposed to decide. Conversely, if you take the stop seriously and set the direction in a single sentence, the AI finishes the rest on its own, pivoting around that decision. The thirty seconds it takes to answer one stop saves the half a day it takes to undo a result that was wrongly pushed through.
So working well with an AI PM comes down, in the end, to how you handle these stops. You don't need to try to direct everything. Delegate what can be undone, and answer clearly only at the points where the AI has brought things to a halt. Good collaboration isn't the human holding every decision, nor the AI handling everything on its own. It's a rhythm: stopping precisely where a stop is warranted, and the person who takes the handoff answering precisely. When that rhythm clicks, the AI PM you've deployed becomes a practitioner who is both quick-handed and incapable of causing a mess. That's a rare combination — and the ability to know when to stop is what creates it.
If it's seeking confirmation even for work that can be undone, the threshold may be set too conservatively. If you set direction in the request or the initial configuration — specifying that certain kinds of work can just be handled and reported — the points where it stops narrow down to the forks that truly matter. Alternatively, it's safe to let it stop somewhat often at first and widen its autonomy as trust builds.
Yes. This state marks a point the AI judged too risky to proceed on by its own judgment alone, so it only moves again once a person responds. In most cases it's either an execution that can't be undone or a lingering ambiguity that swings the direction of the outcome. Left alone, it stays put; so once you set direction on the question that came through, the rest continues on its own.
For work that can be undone, it doesn't stop — it just handles it, so most of the speed is preserved. Stops apply only to the handful of points that are hard to undo or that hinge on direction. Those few seconds of confirmation head off the far larger cost of undoing a result that was wrongly pushed through. On the whole, the one that knows when to stop is actually faster.
It's closer to the opposite. Filling in what it doesn't know with a guess and gliding past it is the more dangerous move, because from the result alone you can't tell what's fact and what's assumption. Pointing out precisely where it isn't certain is what lets you trust and use that result — not a sign of falling short.