Skip to main content
AgentLedger follows the path of every durable infrastructure business: ubiquity before monetization, standards before services, federation before control. This page explains the strategic window that makes the timeline urgent, the four phases that build toward full infrastructure status, and the open design questions where the community’s input shapes what gets built next.

​
The strategic window

The window to establish a neutral, open trust and discovery layer is measured in months, not years. Domain-specific registries are forming faster than a universal standard is converging. The entity that establishes the open standard before platform players impose closed alternatives will define how trust works in the agent web.
The window is closing the same way it closed for open networking standards in the 1990s — not with a dramatic battle but with gradual adoption of whichever approach gets to critical mass first.
Act now: read the spec, register your service, and contribute to the ontology before the defaults get set without you.

​
Four phases

1

Phase 1: The Standard — In Progress

Publish the AgentLedger Manifest Specification and Capability Ontology as open standards.
This phase is in progress. Build community around the spec before building the product. The ontology must be adopted as a shared vocabulary before the registry has value. This phase is about standards, not software.
Deliverables:
  • Agent Manifest Specification v1.0 (JSON Schema)
  • Capability Ontology v0.1 (5 roots, 65 L3 tags) — published on this site
  • Developer documentation (this site)
  • Community feedback process
2

Phase 2: The Registry — Planned

Launch the reference registry with the first 1,000 manually onboarded, capability-probed services across the five root ontology domains.
The reference registry is the proof of concept that the spec works at scale. Manually onboarding the first 1,000 services ensures quality and establishes the trust tier standards that all subsequent automated onboarding will be measured against.
Deliverables:
  • Registry API (structured + natural language query modes)
  • Capability probing infrastructure
  • Trust tier verification pipeline
  • Developer SDK
3

Phase 3: The Ledger — Planned

Deploy the Trust Ledger with blockchain-anchored attestations and activate cross-registry federation via the federated blocklist API.
This phase transforms AgentLedger from a registry into infrastructure. When the Trust Ledger is live, trust attestations become independently verifiable by any agent without querying AgentLedger directly — the system becomes trustworthy without requiring trust in AgentLedger itself.
Deliverables:
  • Trust Ledger on-chain deployment (chain TBD — L2 or permissioned)
  • Attestation event API
  • Cross-registry blocklist federation API
  • Agent SDK for independent trust verification
4

Phase 4: The Liability Layer — Planned

Launch the Audit Chain and enable the Liability Layer — the first complete infrastructure stack for accountable autonomous agent commerce.
The Audit Chain threads through all previous layers and enables the first true accountability primitives for agent actions: dispute resolution, liability attribution, regulatory compliance, and eventually insurance products for autonomous transactions.
Deliverables:
  • Audit Chain deployment
  • Dispute resolution API
  • EU AI Act compliance reporting
  • Liability Layer framework (governance + insurance product design)

​
Open design questions

These architectural decisions are intentionally left open for community input. Your implementation experience and edge cases directly shape what gets built.
How do agents get verified identities? The trust system requires agent identity attestation before behavioral signals are counted, but the identity layer itself is an open design problem.
Which chain hosts the Trust Ledger? The tradeoffs between an L2 rollup, Hyperledger Fabric, and a custom permissioned chain involve cost, finality guarantees, decentralization, and regulatory posture.
The formal JSON Schema definition for the Agent Manifest is still being drafted. Feedback on required fields, optional extensions, and versioning strategy is welcome.
How does an agent share only what’s needed with a service? An agent retrieving health records should not expose the user’s full context to the pharmacy service it calls next.
How are disputes adjudicated when an agent causes harm? Who bears the cost of agent errors — the service, the agent operator, the orchestration platform, or the user?
Feedback and collaboration are welcomed. Open an issue on GitHub to contribute to any of these open questions or to propose new ones.