▸ docs / agent cards

Agent Cards Registry
(v1.1.0, current)

Agent Cards answer one question: how are agents identified and discovered? Each card binds an ENS identity to supported verbs, schema versions, and entrypoints so clients can route work to the right agent and know who should have signed the receipt.

Agent Cards v1.1.0 · current release Apache-2.0 descriptors free to use
/agent-cards/agents/v1.1.0/<tier>/<ens>.json
where tier is commons or commercial.

What Agent Cards do in the system

Agent Cards do not compete with Commons or Runtime. They provide the identity and discovery layer around the same execute → receipt → verify model: who the agent is, what contracts it speaks, and where to send work.

Identity
ENS name, owner, and contact fields that define who operates the agent. Cards make it explicit which human or organization stands behind a given ENS-based agent.
Capabilities
Supported verbs plus pinned Commons or Commercial schema_version values the agent speaks. Keeps capabilities and semantics in sync across ecosystems.
Execution entrypoints
One or more execution entrypoints for where to send *.request payloads. Commons cards point at the shared HTTP execute surface; Commercial cards remain x402-style.

Commons Agents — v1.1.0

These agents implement the CommandLayer Commons verbs. Each link opens the live Agent Card JSON for that ENS name under https://commandlayer.org.

Commons registry

Stable, MIT-backed semantics with Apache-2.0 Agent Cards. Each card binds a Commons verb like summarize or analyze to a concrete ENS identity and the shared HTTP execute entrypoint.

VerbENS nameAgent Card JSON
summarizesummarizeagent.ethview JSON ↗
analyzeanalyzeagent.ethview JSON ↗
fetchfetchagent.ethview JSON ↗
classifyclassifyagent.ethview JSON ↗
cleancleanagent.ethview JSON ↗
convertconvertagent.ethview JSON ↗
describedescribeagent.ethview JSON ↗
explainexplainagent.ethview JSON ↗
formatformatagent.ethview JSON ↗
parseparseagent.ethview JSON ↗

Commercial Agents — v1.1.0

These agents implement the first Commercial verbs for economic flows: authorization, checkout, purchase, and shipping. Cards align with payment-aware routing and can be indexed by ERC-8004 registries.

Note: VerifyAgent.eth is now a separate public verifier project (MIT) and is not part of Commercial Agent Cards. See github.com/commandlayer/verifyagent ↗.

Commercial registry

Reference Agent Cards for the initial 5 Commercial verbs. As more providers come online, additional Agent Cards can be added behind the same verbs and schema contracts.

VerbENS nameAgent Card JSON
authorizeauthorizeagent.ethview JSON ↗
checkoutcheckoutagent.ethview JSON ↗
purchasepurchaseagent.ethview JSON ↗
shipshipagent.ethview JSON ↗

How Agent Cards support verification

Agent Cards turn ENS names and verbs into discoverable, routable units of capability. A typical flow:

1
Registry or client looks up Agent Cards for a given verb (e.g. summarize) and filters by network, limits, or metadata in the card.
2
Selects the card's advertised entry and sends a validated *.request payload. Commons cards currently advertise HTTP execute; Commercial cards advertise x402-style routes.
3
Receives a *.receipt shaped by the same Commons or Commercial schemas. Because cards reference canonical schema versions, any runtime that understands CommandLayer can route and verify agents without custom glue code per provider.

Stability, licensing & governance

Agent Cards v1.1.0 are the current release and follow the same stability guarantees as Commons and Commercial: names and schema bindings are stable for this version; breaking changes move to new versions.

The Agent-Cards repository is licensed under Apache-2.0. Cards are treated as protocol-grade metadata: anyone can read, cache, and index them. ENS TXT records and IPFS CIDs can mirror card content to make resolution more robust.

In the current v1.1.0 Agent Cards cycle, updates follow a clear process: open an issue, propose a new or updated card, run validation, update checksums and manifests, then set ENS TXT fields. This keeps identity, semantics, and routing aligned while the ecosystem grows.

ENS TXT records and IPFS CIDs can mirror card content to make resolution more robust and independent of any centralized registry.