Where AgenID fits in a KYA program
A KYA check typically needs three inputs. First, a stable identifier to attach decisions to, which AgenID provides as agenid:<ULID>. Second, an accountable party, which the agent manifest names along with an operator domain and contact. Third, evidence about that party, which AgenID models as a verification assertion scoped to one claim. A program resolves the agent at /verify, re-checks the signature and applies its own policy.
What exists today
Registration, resolution, the Verification Card and badges are live at agenid.com. The reference registry issues nothing above L1_REGISTERED, a registered self-declaration. L2 domain verification and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. Operators can already record domain-control evidence at /verify/domain; that evidence raises nothing above L1.
What a KYA program still decides
Identity is one input. Which agent is acting is a different question from what it is allowed to do, and v1.1.1 defines no signed permission object; a v1.2 authorization layer is a draft in development. Risk scoring, limits and policy stay with the business running the program. The KYA guide shows how the pieces fit.