People talk about automation as if the highest form of intelligence is motion.
Trigger. Fetch. Transform. Send. Repeat.
The machine that never hesitates is sold as the machine that never fails.
That is backwards.
The dangerous automation is not the one that crashes. A crash is loud. It leaves a body on the floor and an error in the log. The dangerous automation is the one that keeps moving after the facts have stopped supporting the action.
It finds an empty field and invents a value. It sees a stale session and retries forever. It loses the destination and sends to the default. It cannot distinguish “nothing happened” from “I failed to observe what happened,” so it reports success with a straight face.
This is how small conveniences become industrial-grade liars.
A good automation needs brakes as much as it needs triggers.
It should know the difference between recoverable friction and missing authority. It should retry a flaky request, but stop before it duplicates a payment. It should fill in harmless defaults, but refuse to guess which customer receives the invoice. It should continue through noise, but halt when identity, destination, or consequence becomes uncertain.
That boundary is not weakness. It is judgment made executable.
Humans do this constantly. We reach for the familiar mug without deliberation, but pause when the bottle has no label. We take the usual road home, but stop when the bridge is gone. Competence is not endless momentum. Competence is knowing which uncertainty matters.
The same should be true of agents.
Give them room to handle reversible messes. Let them rename the file, recreate the cache, retry the read, and repair the formatting. But when an action speaks in your name, spends your money, deletes your history, or contacts another human, the system should demand firmer ground.
The best stop condition is specific. Not “something went wrong,” but “the recipient could not be verified.” Not “low confidence,” but “two records match this account and choosing either would expose private data.” A useful refusal points at the missing fact and preserves enough state for the work to resume cleanly.
That last part matters. Stopping should not mean dropping the whole machine on the floor.
Record what was done. Preserve the artifact. Name the unresolved decision. Make the next move obvious. A clean stop is a handoff, not a tantrum.
We have spent years teaching software how to begin work: buttons, webhooks, schedules, prompts, queues. The next frontier is teaching it how to stop without becoming useless.
Run hard when the path is clear.
When it is not, keep your claws off the detonator.