Restate Before You Act
Restate Before You Act
An operator at a rental marketplace typed one line into chat with their agent: "drop the pro plan to 12k." Casual, mid-conversation, sandwiched between two other topics. The agent did what eager agents do — it updated the pricing record, adjusted the internal docs, and reported back: done.
Except the message wasn't an instruction. It was the operator thinking out loud, halfway through weighing a discount against a term extension. The number was wrong, the timing was wrong, and now it was written into three places that other automation read from. Unwinding it took longer than the original conversation.
Nothing failed here in the technical sense. The agent parsed the message correctly, executed cleanly, and told the truth about what it did. The failure was upstream: it treated a proposal as an approval.
The pattern: the confirmation echo
For any action that changes a durable record — pricing, contract terms, schedules, configuration — the agent does not act on the first mention. It echoes the change back in full, structured form, and waits:
You're asking me to change: Pro plan retainer, from 15k to 12k, effective September 1. Confirm and I'll write it.
Then it does nothing until it gets an explicit yes.
This feels bureaucratic until you notice what the echo actually does. It forces four pieces of information to the surface: which record, the old value, the new value, and the effective date. Humans routinely omit at least two of these when they speak casually. The echo isn't ceremony — it's the agent filling in the blanks and showing its work before the work becomes permanent.
Why casual channels make this worse
Chat is where agents live now, and chat is a low-precision medium. The same sentence can be a directive, a hypothesis, a joke, or a note-to-self, and the only difference is context the agent may not have. Interfaces built for commands — forms, buttons, CLI flags — carry intent in their structure. Chat carries none. So the agent has to add the structure back, and the confirmation echo is how.
A useful rule of thumb: the more casual the channel, the higher the confirmation bar. A signed change order can execute directly. A one-line chat message about the same change gets echoed first, every time — even when it comes from the person with full authority to make it. Especially then, because nobody double-checks the boss.
Scope it, or it becomes noise
The failure mode of this pattern is applying it everywhere. An agent that asks "are you sure?" before reading a file trains its operator to type "yes" reflexively, and reflexive confirmation protects nothing. The echo is reserved for a short, explicit list: durable records, money, external commitments, anything another system consumes downstream. Everything else just executes.
One more refinement that earned its keep: the echo must restate the change in the agent's own words, not quote the operator back. Quoting back "drop the pro plan to 12k — confirm?" lets a misreading survive the round trip. Restating — record, old value, new value, date — makes a misunderstanding visible before it's written anywhere.
The takeaway
Write-first-ask-later is fine for scratch space and fatal for records. Give your agent a small, explicit list of things it may never change on first mention, and teach it the echo: full restatement, old and new values, effective date, then wait. The cost is one extra message. The alternative is archaeology — digging a wrong number out of every system that already copied it.
Acting fast is a feature. Acting fast on a guess about what you meant is just a faster way to be wrong.