Why agents must propose

The problem with silent automation

Traditional automation runs silently. It takes input, produces output, and completes — without a moment for human review. For deterministic tasks with no side effects, this is fine. For anything that touches real decisions — an email drafted, a file moved, a record updated — silence is a design flaw. The human discovers what happened after the fact, if they discover it at all.

This is not a bug in any particular system. It is the natural consequence of designing automation as a replacement for human action rather than a preparation for it. When agents inherit this design posture, the problem scales. An agent that acts silently acts at agent speed, which means many decisions accumulate before any human sees them.

Three failure modes

When agent systems skip the approval gate, three failure patterns emerge consistently.

Error amplification. One wrong assumption made by the agent propagates downstream before anyone sees it. A proposal that would have been caught in two seconds becomes a decision that takes an hour to undo. In agent-assisted workflows, errors compound quickly because each step uses the output of the last.

Authority confusion. After the fact, it becomes unclear who decided. Was the action the agent's choice or the operator's? The record doesn't say. This ambiguity has real consequences in any context where accountability matters — legal, compliance, client relationships.

Audit gap. No record explains why the action happened. The audit trail says "completed" but gives no context for the decision. This fails compliance reviews and makes incident response harder. When something goes wrong, the first question is always: who decided this? Without a proposal-commit record, there is no answer.

The proposal-gate-commit loop

The correct architecture has three steps, not one. The agent reads the situation and produces a proposal: a human-readable description of what it intends to do and why. The operator reviews the proposal in context. The operator either commits or declines. Only after a human commits does the action execute. The commit is logged permanently as a human decision, attributed to a named actor, at a specific time.

This loop is slower than silent automation by seconds. It is safer by orders of magnitude. And the record it creates is not overhead — it is the work product. Every committed action is, at minimum, a timestamped statement that a named human reviewed and approved a specific course of action.

The proposal step also creates leverage in the other direction. When operators decline a proposal, the agent learns the boundary. Over time, proposals improve. The gate is not just a safety mechanism — it is a feedback channel.

Why the invariant must be architectural

The gate only works as an absolute. If some actions skip the gate while others require it, operators learn to treat the gate as optional. They begin committing without reading. The gate becomes theater — present in form, absent in function.

The only system that preserves the value of human oversight is one where no consequential action executes without a commit. This is not a process recommendation. It is an architectural constraint. Every consequential action routes through the gate. No exceptions, no bypass flags, no "fast path" for actions that seem low-risk.

The definition of "consequential" is deliberately broad. If in doubt, route through the gate. The cost of an unnecessary proposal is a few seconds of operator attention. The cost of a skipped gate on a consequential action can be significant.