input-required

The interesting part of putting a human gate behind a machine protocol: the caller cannot satisfy the thing that is blocking.

#What a client sees

json

{
  "id": "task-1",
  "status": {
    "state": "input-required",
    "message": {
      "role": "agent",
      "parts": [{ "kind": "text", "text":
        "Held for a licensed human at p_north. This is not something the calling agent can supply: an authorization is transmitted only after a named clinician releases this exact submission. Nothing has been sent to the payer." }]
    }
  }
}

#Why input-required rather than working

A task sitting in working for six hours tells a client nothing about whether to keep waiting, escalate, or tell a user. input-required says the task is blocked on something outside the machine loop - which is true, and which lets a client surface it to whoever is actually waiting.

#Why not failed

Nothing has failed. The task is proceeding exactly as designed, and it will complete when a clinician looks at it. Reporting a gate as a failure would train every client integration to retry it, which is the opposite of what should happen.

The caller cannot release

There is deliberately no A2A method that releases a gate. A release requires a named licensed human authenticated at the practice, and exposing it over a machine protocol would make the entire control a formality. A client polls; it does not approve.

#What a client should do

Surface the state to whoever is waiting, with the practice named.
Poll on a sane interval. Minutes, not seconds - a human is reading a chart.
Do not retry message/send with the same content. That creates a second task and a second thing for a human to review.
Expect completed to carry a denial as readily as an approval. A decision is a decision.