What A2A is
A2A is a protocol for one agent to ask another agent to do work. A client agent discovers what this platform can do, sends a task, and polls it to completion - without knowing anything about X12, Availity, or the practice's EHR.
#Why it fits this problem
Prior authorization is a natural task boundary. A client agent - an EHR vendor's assistant, a revenue-cycle bot, a workflow in IBM watsonx Orchestrate - knows a patient needs a procedure and does not want to learn a clearinghouse. It hands over a task and gets back a decision or a reason.
#The important part
A2A does not route around the gate
An external agent is a principal like any other. It passes the same gateway, the same atom check, the same practice binding, and the same human release. What A2A adds is a vocabulary for expressing "this task is blocked on a person" back to a caller that is itself software.
#How a task maps
| A2A task state | What it means here |
|---|---|
submitted | Accepted, nothing done yet. |
working | The agent is assembling - reading rules, validating, checking for duplicates. |
input-required | Held at the human release gate. The caller cannot satisfy this; a licensed human at the practice must. |
completed | A decision exists. It may be an approval, a partial, or a denial. |
failed | Something went wrong that is not a decision - a validation failure, a vendor outage. |
canceled | Withdrawn before completion. |
The mapping of the release gate onto input-required is the one design decision in this whole surface worth arguing about, and it is covered in input-required.
#What an external agent is not permitted to do
- Reach a practice that has not authorised its channel.
- Exceed the practice's external autonomy ceiling, which a practice can set lower than its own.
- See unmasked PHI unless the practice has granted that specifically.
- Call anything not in the tool registry - and the registry is what generated the descriptor it read.