That report may be accurate. It is not evidence that the intended change occurred.

A dependable system must distinguish requests, authorization, attempts, observations, and confirmed effects. Otherwise a confident completion message can conceal a failed action-and an automatic retry can turn uncertainty into a duplicate or conflicting result.

Completion is not a tone. It is an evidence claim.

1. Give “done” a finish state

Suppose an agent submits a consequential form. At least six events may occur:

  1. The user requests a change.
  2. The system resolves the material parameters.
  3. The user or policy authorizes that exact action.
  4. The agent attempts the submission.
  5. The external service applies the change.
  6. The system obtains evidence of the new state.

A conversational interface makes these events feel continuous. Operationally, they are different states.

A request is not authorization. Authorization is not execution. A successful API response is not always the intended business outcome. An attempted handoff is not an accepted transfer of responsibility.

Before implementation, write one sentence that defines completion:

If the team cannot fill in both blanks, the agent cannot safely claim success.

2. Keep the action lifecycle outside the model

Represent consequential actions in explicit workflow state:

  • Proposed: The agent identified an action.
  • Authorized: A user or policy permitted the exact action.
  • Attempted: An execution request was sent.
  • Confirmed: Independent evidence shows that the intended effect occurred.
  • Unresolved: An attempt occurred, but its effect is unknown or partial.
  • Recovered: The uncertainty or failure was reconciled and a safe next state exists.

The model may recommend a transition. The workflow must decide whether that transition is allowed and persist the result.

This prevents the central category error: treating the model’s account of the workflow as the workflow itself.

Release bar: after interruption or restart, the system can reconstruct the last confirmed state without asking the model what happened.

3. Bind authorization to the action

“Go ahead” may authorize the proposal immediately above it. It does not necessarily authorize a changed price, a different recipient, an additional operation, or future attempts.

For a consequential action, record:

  • The operation being authorized.
  • Its material parameters and limits.
  • The identity or policy granting authority.
  • Whether permission covers one attempt or continued execution.
  • The conditions that invalidate it.

If a material parameter changes, return to proposed. Do not stretch old approval over a new action.

Authorization should be only as broad as necessary to reach the agreed outcome. The consequence of the action determines how precisely it must be represented.

4. Treat “unknown” as a real state

Distributed systems produce ambiguous results. A request times out after leaving the client. A connection closes before the response arrives. A downstream system accepts work but delays confirmation. A multi-step operation completes only in part.

In each case, “failed” may be the most dangerous interpretation. Repeating the request can create a duplicate booking, payment, notification, or record.

An unresolved result must block blind repetition. The next permitted action should reconcile before it retries:

  • Query using an idempotency key or stable identifier.
  • Compare the observed state with the requested state.
  • Wait for a bounded confirmation window.
  • Compensate for a confirmed partial effect.
  • Transfer the case to a person with the full action record.
  • Stop if no safe automated resolution exists.

Unknown is not missing state. It is a state with stricter permissions.

Release bar: every ambiguous result enters an explicit unresolved state with a bounded reconciliation path.

5. Design retries around effects

A retry policy based only on transport errors is too shallow. The relevant question is not “Did the call return successfully?” It is “Can this operation be repeated without causing a second effect?”

Safe repetition usually requires at least one of these mechanisms:

  • An idempotency key enforced by the receiving system.
  • A stable external identifier that can be reconciled.
  • A compare-and-set or read-before-write condition.
  • Naturally idempotent operation semantics.
  • A compensating action with known limitations.
  • Human resolution when the effect cannot be established safely.

The model can propose retrying. The workflow must prove that retrying remains permitted.

6. Report the state, not the aspiration

User-facing language should match the evidence:

  • Proposed: “I’m ready to submit this after you confirm the time.”
  • Attempted: “I submitted the request and am waiting for confirmation.”
  • Unresolved: “The provider returned no conclusive result. I have not retried because that could create a duplicate.”
  • Confirmed: “The appointment is confirmed for 3:00 p.m.; the provider’s reference is …”

This is not cosmetic caution. Users and operators make decisions based on what the system claims. False certainty becomes a second failure layered on top of the first.

7. Hold ownership until it transfers

Agents often treat escalation as an action they can complete unilaterally: post a message, open a ticket, name a person, mark the task handed off.

A real handoff requires:

  • An identified recipient.
  • Enough context to continue.
  • An explicit ownership state.
  • Evidence that the recipient or receiving system accepted responsibility.

Opening a ticket is an attempted transfer. Until responsibility is accepted, the original workflow still owns the unresolved outcome.

Release bar: no task becomes ownerless because the system confused notification with handoff.

Require evidence for the claim

An agent can help decide what should happen next. It should not be the sole authority on what already happened.

The surrounding system must preserve the boundary between language and state, attempts and effects, notifications and accepted responsibility.

When the agent says it is done, ask one question: what evidence would make that true?