An identity certificate is the first trust anchor for an agent. It binds a specific `agent_id` and an initial local state checkpoint to a registry-issued certificate.
The core use case is establishing that a new agent is real, self-controlled, and externally attestable before anyone relies on it. It answers the first trust question: “What exactly is this agent at the moment it enters the world?”
A practical example is launching a new agent into production, a marketplace, or a partner workflow. The agent has a fresh keypair, a new `agent_id`, and an initial set of local files such as:
- `AGENT.md`
- `SOUL.md`
- optionally `MEMORY.md`
You append those into AMCS, get the first `memory_root`, and issue the identity anchor. That certificate gives outside parties a signed, verifiable checkpoint for the agent’s starting identity and starting state.
The event flow is:
- You create a new agent identity (new keypair, new `agent_id`).
- You define the initial local state.
- You append that state into AMCS to produce the first `memory_root` and sequence.
- You submit the identity anchor request, signed by the agent’s key.
- The registry verifies the request and issues the identity certificate.
- From that point on, future continuity certificates can extend from this starting point.
And yes, in most cases it is better to issue the identity certificate right when the agent is created, or as close to creation as possible. That is usually the cleanest workflow because:
- it gives you a canonical starting checkpoint
- it avoids ambiguity about what the “original” state was
- it establishes trust before the agent accumulates later changes
- it makes all later continuity easier to interpret, because there is a clear origin
If you delay the identity certificate, the agent may already have changed locally multiple times before its first public anchor. Then verifiers can still trust it from the anchor onward, but they lose a clean external proof of the earliest state.
The value of verifying the identity certificate after issuance is that it proves the agent’s origin point. A verifier can confirm:
- the registry actually issued the certificate
- the certified `agent_id` matches the agent’s public key
- the initial certified `memory_root` matches the claimed starting state
- the trust chain begins from a known, signed checkpoint instead of an unverifiable self-description
That matters when another system, user, or auditor wants to decide whether to trust the agent at all. Before continuity or lineage matter, identity is the base layer. It establishes:
- who this agent is
- what state it started from
- when that starting point was externally certified
So the three certificates fit together like this:
- identity certificate: “This agent starts here.”
- continuity certificate: “This same agent later changed to here.”
- lineage certificate: “This new agent descends from that other agent.”
A simple real-world use case is onboarding a new customer-facing agent. You issue the identity certificate immediately after creating it so partners can verify that the agent they are connecting to is the intended one, with the intended initial role and constraints, before any later updates happen.