Leave room for an answer

Some answers arrive later. A person may need to review a draft, or an external operation may still be running. Flow expresses the wait through an ordinary declared Tool call whose reply is not yet available.

Waiting does not invent a result

Return to Let the outside answer and select Wait for a reply. The run remains waiting because the function still needs the reply. It has not returned an empty amount or silently chosen the failure branch.

The same idea works when a person answers. A review Tool can return a typed choice such as approve, revise or decline. Those are protocol values supplied by the application, not a privileged channel that can arbitrarily rewrite a running program.

Replay and resume ask different questions

Replay asks whether the recorded execution can be reconstructed. It does not ask an implementation for a new answer. Resume continues a run using the retained record and the inputs or replies that its host admits at the declared boundary.

An application manages where the record lives and how a later reply reaches the run. The browser lesson demonstrates waiting and replay of completed records. An application's persisted run and resume interface is where you practice continuing a parked workflow.

Checkpoints shorten the path back

A long program can retain a checkpoint so reconstruction starts partway through. A checkpoint does not turn an outside reply into a deterministic calculation; it provides a cut from which the program can continue under the history rules.

Read the waiting-for-people pattern. Identify the Tool declaration, the possible reply values, and the code that handles each answer. Those three pieces make the wait understandable without assuming a particular user interface.

Exact rules: history, replay and resume, checkpoint practice.