Google Vertex AI Agents

Google's Agent Development Kit and Vertex AI Agent Engine speak A2A natively - the protocol this surface was built around - so the cleanest path is to register this platform as a remote agent. A plain OpenAPI tool works too.

#Option A - an A2A remote agent

Point the ADK's A2A client at the card:

curl -H "authorization: Bearer $TOKEN" https://app.authprior.com/api/agent-card > priorauth.agent.json

The client reads the skills and drives message/send and tasks/get for you. Carry the channel token on the A2A client's auth config, stored in Secret Manager - not in the agent's prompt.

#Option B - an OpenAPI tool

curl -H "authorization: Bearer $TOKEN" https://app.authprior.com/api/orchestrate > priorauth.json

Add priorauth.json as an OpenAPI tool on your Vertex agent (or in Agentspace) with an authentication config carrying the bearer token. Each registered agent becomes one operation.

#Two things that are not optional

1. Long-running, so poll
   A task held at the release gate stays input-required until a licensed human at the practice acts. Map that to a wait, never to a tool error - and never let the agent retry message/send, which starts a second task.
2. A channel identity, not a superuser
   Vertex authenticates as a channel principal bound to specific practices, checked on every call. A practice that has not authorised the channel is unreachable, and its external autonomy ceiling can be set lower than the practice's own.

#What the agent should not be asked to do

• Approve or release - there is no operation, in either surface.
• Enumerate practices - neither the card nor the spec lists them.
• Poll on a chat cadence - the payer answers in days.