Quiet on the line

At masad, a large share of the day-to-day work runs on an autonomous system we built. AI agents move work orders forward stage by stage, with review at the end, and anything that touches the outside world stops and waits for a person to approve it: money, customers, anything going live.

On paper, human approval sounds like the simple part of the story. The system works, a person approves, everyone moves on. In practice, the most important lesson we have learned about autonomy so far came from exactly this point. It did not come from a mistake the system made. It came from silence.

One work order, adding analytics to our own site, cleared every stage. The build was finished, review had covered everything, and one blocker remained. The site's privacy notice was placeholder text, and wording like that must be approved by a person before it goes live. The reviewing agent noted it for itself: stop here, this waits for a decision.

Then, for about twenty hours, nothing happened.

Not because of a technical fault. Because the instruction to stop and wait for a decision was written in language a person understands, and meant nothing to the machine. No status changed, no notification went out. The real question, what the final wording should be, stayed buried in a text output no mechanism reads. And from the outside, a system waiting quietly looks exactly like a system still thinking.

In hindsight it looks obvious. In advance, we too were planning mostly for the opposite scenario, what happens if the system does something without permission. It turns out the more elusive failure runs the other way. A system that waits for permission politely, endlessly, with nobody knowing it is waiting.

Three principles came out of that failure. All of them reach well beyond AI.

The first principle is that waiting for a person has to be a real state in the system, not a note in the instructions. We now have one place where every question that needs a human decision arrives, from any stage of the process. The moment something lands there, a notification goes out, and the question itself is spelled out inside. Not "something is waiting" but "this is the placeholder text, a final wording is needed".

The second principle is that silence is not allowed. Every stage has to end in one of three explicit outcomes. It passed, it was rejected, or it goes up for a decision. A stage that ends without one of these is itself a fault, and raises an alert. Underneath all of that sits a safety net. Work that lies untouched for more than eight hours raises an alert, even if no other mechanism caught it. That incident would have surfaced after eight hours instead of twenty.

The third principle, the deepest of them, is that the system must have a legitimate way to say it is missing something. An autonomous system with no orderly way to stop does not stop. It fills the gap with something that looks reasonable, a placeholder text, a quiet assumption. That is more dangerous than an ordinary error, because an error is visible, and a plausible fill-in looks like finished work. In our system, a role that cannot finish because a real input is missing stops and asks. And the system refuses to start a build while such an input is declared missing. That is not a failure of the autonomy. That is exactly how it is supposed to work.

And now the part that applies to any business, without a single line of AI. Every business has points where a process stops and waits for a person. A quote waiting for a manager's signature, a refund waiting for approval, a supplier waiting for an answer by email. At each of those points, two questions are worth asking. How does the question reach the person who decides, and who notices if it never arrived. If the answer is "someone will remember", there is a gate there that can go silent.

The same holds when you look at a new automation tool. What the tool can do on its own is only half the picture. The other half is what happens the moment the tool needs you. Where does the question show up, who gets notified, and what happens if nobody answered. A tool without good answers to those questions will do well in a demo, and stall quietly in real use.

Today, the approval gate in our system is not a button. It is a whole channel, with a defined state, a spelled-out question, a notification that goes out, and a safety net for silence. Building that channel took longer than building the button, and that is the right ratio. Because the hard part of autonomy is not getting the machine to stop. The hard part is making sure that when it stops, someone hears.