What an A2A Agent Card is
The A2A specification, at version 1.0.0, describes A2A as an open standard for communication and interoperability between independent, potentially opaque AI agent systems. The project repository states that A2A is an open source project under the Linux Foundation, contributed by Google, licensed under Apache 2.0.
Under the specification, A2A servers must make an Agent Card available. Clients can find one at https://{server_domain}/.well-known/agent-card.json, through registries or catalogs, or by direct configuration. The card carries the agent's name, description and interfaces, its skills and capability flags, a provider object naming the provider's organization and URL, and the security schemes a client must use, which include API keys, HTTP authentication, OAuth 2.0, OpenID Connect and mutual TLS.
Agent Cards may be signed with JSON Web Signature (RFC 7515). Before signing, the card must be canonicalized with the JSON Canonicalization Scheme, RFC 8785. The protected header names the algorithm, for example ES256 or RS256, and a key ID, and may include a jku URL for a JSON Web Key Set. The specification says clients should verify at least one signature before trusting a card, retrieve keys over HTTPS, and may keep a trusted key store for known providers.
What AgenID is
AgenID is an open protocol, specified in the MIT-licensed AgenID specification, that gives an AI agent a permanent identifier, agenid:<ULID>. The operator generates an Ed25519 key pair locally or in the browser at /issue, writes a manifest covering identity, ownership, purpose and disclosure, and signs a proof binding the manifest by SHA-256 digest. The registry at www.agenid.com serves the result at https://www.agenid.com/a/<agenid> as a Verification Card or a JSON resolution envelope that anyone can re-verify offline.
Key differences
Purpose differs. An Agent Card is written so a client can connect: interfaces, skills, capabilities and required authentication. An AgenID manifest is written so a counterparty can hold someone accountable: the agent's name and purpose, the operator and its domain and contact, and whether the agent is disclosed as an AI.
Where the record lives differs. An Agent Card is typically served by the agent's own server at a well-known path. An AgenID record is served by a registry under a permanent identifier that does not change when the agent's endpoint, platform or version changes.
Key trust differs. A2A leaves the question of which signing keys to accept to the client, whether through a jku URL or a trusted key store. AgenID specifies a procedure: confirm the key's role is operator, confirm its controller is the agent, and compare the key the registry serves at GET https://www.agenid.com/v1/keys/<key-ulid> with the operator's own copy at /.well-known/agenid/keys.json (two-path key discovery).
They share a building block: both canonicalize JSON with RFC 8785 before signing. A2A signs with JWS and algorithms such as ES256; AgenID signs with pure Ed25519 over the canonical bytes.
Identity is not permission
An Agent Card declares how clients must authenticate, and the specification states that A2A does not define the scope, representation, validity or revocation semantics of the authorization decision obtained when a task requires additional authorization. AgenID v1.1.1 defines no authorization object either. In both, which agent is acting is a different question from what it is allowed to do, and that decision stays with the implementation or the relying party.
Where they are complementary
A client that discovers an agent through its Agent Card can also resolve that agent's AgenID identifier to check which operator declared it, and compare the card's provider organization with the operator named in the signed manifest. A2A v1.0 defines no field for an AgenID identifier and AgenID v1.1.1 defines no Agent Card binding, so publishing the identifier alongside a card is an implementation choice, not a feature of either specification.
When to use which
These are fit questions, not quality judgments.
- Use an A2A Agent Card when your agent speaks A2A and clients need to discover its skills, interfaces and authentication requirements.
- Use AgenID when counterparties, including people and businesses outside A2A, need a permanent, operator-signed identity for the agent that they can re-verify offline.
- Use both when an A2A agent also interacts with parties who need to know which operator stands behind it.
AgenID's current limits
AgenID's boundaries, stated as plainly as its design:
- Issuance ceiling: the reference deployment at agenid.com issues nothing above L1_REGISTERED today. The specification defines L2_DOMAIN_VERIFIED, L3_ORGANIZATION_VERIFIED and L4_DEPLOYMENT_VERIFIED, but each requires a VerificationAssertion signed by a root authority key, and that key has not been created yet. L1_REGISTERED is a self-declaration: it means an operator-signed manifest is in the registry, not that anyone checked the operator. L5 is reserved and not issuable.
- No revocation flow is deployed. Agent status values such as SUSPENDED and REVOKED exist in the schema so the envelope shape is stable, but nothing in production writes them, so every registered agent reads ACTIVE. The specification keeps retired and revoked keys resolvable permanently so that historical signatures remain checkable.
- No authorization object exists in v1.1.1. The DECLARED, VERIFIED and AUTHORIZED claim states are never inferred from one another, AUTHORIZED has no signed object, and
permissionsandauthorizationsare reserved manifest keys that a v1.1.1 validator rejects. A v1.2 authorization layer is a draft in development, not something available. - Two-path key discovery depends on the operator. The registry serves the operator key at
GET https://www.agenid.com/v1/keys/<key-ulid>, and the operator is expected to publish its own copy athttps://<operator_domain>/.well-known/agenid/keys.json. If the operator publishes no copy, a verifier has one source, not two.