Objections handled fast.
Protocol truth, no drift.

CommandLayer is the trust layer for agent execution: canonical verbs, strict JSON Schemas, machine-readable discovery, and verifiable receipts.

Commons and Commercial define the contract. Agent Cards define discovery. Runtime defines execution. That split is the architecture.

One line: The contract stays public. Execution becomes infrastructure.

Because most agent integrations still depend on private prompt formats, undocumented payloads, and vendor-specific runtime assumptions. That is not interoperability.

CommandLayer gives builders a public contract surface so they can swap runtimes, vendors, and payment rails without losing meaning or breaking validation.

• Canonical schemas instead of prompt folklore.
• Published versions instead of implicit breaking changes.
• Receipts you can validate across runtimes.

CommandLayer never charges for semantics, schemas, or validation. Schemas stay public and portable.

• Open: Commons schemas, Commercial schemas, Agent Cards, validation, interoperability.
• Metered: runtime execution, routing, throughput, guarantees, policy enforcement, commercial service surfaces.
• Protocol rule: meaning, validation, and interoperability are never paywalled.

ENS is the human-readable anchor. Agent Cards are the machine-readable identity and routing document. Runtime executes requests against published schemas. Receipts are the standardized result contract returned after execution.

• ENS: naming and continuity.
• Agent Cards: discovery, declared capabilities, routing targets, schema versions.
• Runtime: execution, policy, proof, metering, guarantees.
• Receipts: canonical result surface for independent verification.

Canonical receipt first, runtime metadata second.

Agent Cards are open JSON descriptors that tell clients what an agent is, what verbs it supports, which schema versions it speaks, and where requests should be routed.

They are the discovery layer. They do not replace schemas and they do not redefine receipts. Agent Cards define discovery and routing — they keep capability lookup public and machine-readable.

A receipt is the standardized result contract for an execution — the canonical surface a client validates after a request completes.

Runtimes may attach trace, proof, or orchestration metadata on top of that canonical receipt, but those execution-layer additions do not redefine the receipt contract itself.

• Canonical receipt first.
• Runtime details, proof, or execution class second.
• Independent validation remains possible across runtimes.

Receipts are evidence of contract-conforming execution, not a dumping ground for runtime internals.

Validate both sides against the published JSON Schemas. That is the point of a protocol-grade contract.

• Validate the request before execution.
• Validate the receipt after execution.
• Pin to published versions and CIDs when you need immutability.
• If validation fails, interoperability fails.

If you cannot validate independently, you do not have a standard. You have a private integration.

Runtime is the execution layer. It takes published Commons and Commercial contracts, enforces policy, routes execution, meters usage, and can emit proof and trace data alongside the canonical receipt.

Runtime is live today as a reference proving surface. The roadmap expands hardening, guarantees, multi-runtime support, and commercial operations around that live base.

Others can run runtimes because the contract surface is public. That is the point.

Competition should happen in execution quality: reliability, routing, latency, guarantees, certification, policy, and cost. The meaning layer stays shared.

Open semantics, competitive execution.

Versions are explicit and published. Commons v1.1.0, Commercial v1.1.0, and Agent Cards v1.1.0 are concrete contract surfaces, not hand-wavy references.

Builders target versioned schemas and can pin to canonical artifacts. New behavior should arrive in new versions, not as silent drift.

Commercial verbs are the economic contract layer for payments, checkout, fulfillment, shipping, verification, and adjacent business flows.

They use the same protocol discipline as Commons: public schemas, strict validation, portable receipts. Commercial currently preserves a commerce-oriented compatibility shape while Commons remains the cleaner canonical model. Monetization still lives in execution, not in the meaning of the verbs.

No. x402 handles payment and transport patterns. ERC-8004 handles discovery and agent registry patterns. CommandLayer defines the contract those systems move and discover.

x402 moves money. ERC-8004 helps find agents. CommandLayer defines what the request and receipt mean.

No. Open core usually paywalls capabilities inside the standard itself. CommandLayer does the opposite.

The contract layer stays open: semantics, schemas, validation, and interoperability. Monetization lives in execution, guarantees, routing, and commercial service surfaces.

Start with one published schema, not the whole universe. Build against Commons or Commercial today.

• Pick one live verb.
• Validate a *.request payload against the published schema.
• Execute through your runtime of choice.
• Validate the canonical *.receipt.
• Add an Agent Card when you want discovery and routing.

The fastest path is still one verb, one request schema, one receipt schema, one Agent Card.