Why delegation chains break without identity
In a multi-agent system each hop is a trust decision. If an agent can't check who it is handing work to, a single impersonated link can redirect the whole chain. After the fact, reconstructing what happened depends on the logs of whichever participant you ask, and each has a reason to tell it their way.
Resolve, verify, delegate at every hop
Before handing anything over, each agent resolves the next agent's AgenID and re-verifies its operator's signature. Every hop is attributable to a persistent identifier, so the chain can later be reconstructed from the public records rather than from any one participant's account of it.
That gives the pattern this scenario ends on: identify, verify, delegate, act, audit.
What the protocol does and does not define today
Protocol v1.1.1 defines identity, the signed manifest and verification assertions. It does not yet define a signed object for what an agent is permitted to do or how far a delegation reaches; that scope is set by each operator. Signed authorization is being designed for a later protocol version and is not available today.
Today the reference registry at agenid.com issues DECLARED and L1_REGISTERED. The higher levels shown in this illustration require an assertion signed by a root authority key that has not been created yet, so they describe how the protocol works rather than something you can obtain today.
Frequently asked questions
What is agent-to-agent delegation?
It is when one AI agent hands a task, or part of one, to another agent, which may hand it on again. Multi-agent systems depend on it.
How do you audit a chain of AI agents?
Give every agent a persistent, resolvable identity and have each one verify the next before delegating. The chain can then be reconstructed from identities that anyone can re-check, not from one party's logs.
Does AgenID limit what a delegated agent can do?
No. AgenID answers which agent is acting and who declared it. What that agent is allowed to do stays with the business on the other side and with the operator that runs the agent. Protocol v1.1.1 defines no signed authorization object.
Does this work across different agent frameworks?
Yes. Verification uses the public record and standard Ed25519 signatures, so it doesn't depend on the framework or platform each agent runs on. No framework adapter packages are published yet.