How it relates to AgenID
An AgenID identifier is agenid:<ULID>, for example agenid:01J8Z3K3F2QZ9X6V7R4T8N2W5Y. It is not a DID, and v1.1.1 does not define a DID method. Where a DID method specifies its own resolution, AgenID resolves through its registry and cross-checks the operator key against the operator's own domain using two-path key discovery. The comparison covers the trade-offs.
Those two paths are the registry at GET https://www.agenid.com/v1/keys/<key-ulid> and the operator's https://<operator_domain>/.well-known/agenid/keys.json.
Why it matters
Both approaches aim for identities a verifier can check without trusting a single database. AgenID adds a fixed manifest schema for agents, with operator, purpose and disclosure fields, and a verification level model. The identifier is immutable for the life of the record and never reissued.
The reference deployment at agenid.com issues nothing above L1_REGISTERED today. L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet.
What it does not mean
Neither a DID nor an AgenID, on its own, says what the identified agent is allowed to do. Identity and permission are separate questions. Each shows control of a key; neither is a statement that the controller is reputable.