The agent card

The agent card is how a client discovers what this platform can do. It is served at /api/agent-card and it is generated, not maintained.

Generated, so it cannot drift

The card is derived from the same tool registry the gateway checks at call time. A hand-written descriptor that drifts from the route it claims to describe is a named failure mode - a client builds against a capability that is not enforced, or is refused something the card advertised.

#Shape

json

{
  "name": "priorauth.in",
  "description": "Prior authorization over X12 278. Every consequential action stops for a licensed human.",
  "version": "1.0.0",
  "capabilities": { "streaming": false, "pushNotifications": false, "stateTransitionHistory": true },
  "defaultInputModes":  ["application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "prior_auth_intake",
      "name": "Prior Authorization Intake",
      "description": "Checks payer support, fetches payer rules, validates the draft, then stops at the human release gate.",
      "tags": ["prior-authorization", "x12-278", "human-gated"]
    }
  ]
}

#Skills are agents, not tools

A skill in the card corresponds to a registered agent, not to an individual tool. A caller asks for an outcome - "get this authorized" - rather than orchestrating twelve calls it would have to understand. The tools behind a skill are an implementation detail, and one that changes when a payer moves rails.

#What the card deliberately does not carry

No practice list. Which practices exist is not discovery information.
No atom names. A client does not construct permissions; it is granted a scope by a practice.
No streaming. Set to false honestly. Prior authorization is measured in days, and a streaming channel held open for a week is a liability, not a feature.