Skip to content
↑↓ to move · Enter to openEsc to close
Example verification flowScenario 01

How a business verifies the AI agent booking an appointment

A personal AI assistant calls a dental office: "I'm calling on behalf of Mike to schedule his cleaning." The office's own scheduling agent answers. Before it opens the calendar it has one reasonable question, and today almost no way to answer it: who is actually calling?

Watch the same call play out with and without a portable agent identity. Booking an appointment is low stakes, which makes it the clearest place to see the mechanism.

Ready
Human
Mike
“Call my dentist and schedule my cleaning.”
Personal agent
Identity proof
Mike's assistant
Operator: Mike (individual)
“I’m calling on behalf of Mike.”
Business agent
Riverbend Dental
Front-desk scheduling agent
Who are you?
Example verification flow
Fresh challengenonce 7F3C·A1
Proof of control✓ VALID
Operator declarationL1_REGISTEREDDECLARED
Domain claimL2_DOMAIN_VERIFIED✓ VERIFIED
StatusACTIVE
Checked separately
Record accessPRACTICE POLICY

Identity is not permission. Whether this agent may reach records, or act clinically, is the practice’s decision — not AgenID’s.

Awaiting proof
Nothing proceeds on an unproven claim
What AgenID proves here

Which agent placed the call and who declared it. Clinical authority, record access and consent remain separate decisions made by the practice.

Illustration, not deployment

These scenarios illustrate the protocol's verification model. The reference deployment at agenid.com issues nothing above L1_REGISTERED today: L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created. L5 is reserved by the spec and is not issuable at all.

Challenge–response is a proposed interaction pattern. v1.1.1 defines the signed objects, not this exchange.

The problem with voice and caller ID

A voice agent can say any name, and caller ID can be spoofed. A practice that wants to act on an agent's request has two bad options: refuse every automated caller, or accept claims it cannot check. Neither scales as more patients hand routine calls to assistants.

How the practice checks the caller with AgenID

The assistant presents its AgenID. The practice's agent resolves it and gets the operator's signed manifest, meaning who runs the agent and what it says it is for. It then re-verifies the signature itself. In the illustrated flow the practice also issues a fresh challenge that the agent answers with its key, so a recording of an earlier call can't be replayed.

The operator declaration shows as DECLARED at L1_REGISTERED, which is what the operator says about itself. A domain claim at L2_DOMAIN_VERIFIED would mean an authority checked that the operator controls the domain it names.

Identity is not access to records

Knowing which agent called does not give it access to anything. Whether it may see records, change a booking or act clinically stays entirely the practice's decision, under its own policies and the privacy rules it already follows. AgenID answers who; the practice decides what.

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

Can an AI assistant book appointments for me?

Many can place the call. The open question is whether the business can tell which assistant is calling and who stands behind it. That is the gap a portable identity like AgenID fills.

How does a practice verify an AI caller?

It resolves the identifier the agent presents, re-verifies the operator's signature over the manifest, and checks which specific claims have been independently verified. It can do all of this without an account with AgenID.

Does verification give the agent access to patient records?

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.

What does the practice need to install?

Resolution is an HTTPS request plus standard Ed25519 signature verification. No adapter package is published yet for any scheduling or voice platform; the partner docs describe the integration pattern.

Integration patterns for this scenario

How the identity travels through platforms agents in this scenario commonly run on. Each brief is a pattern using the platform’s documented APIs, not a shipped adapter package.

Give your agent an identity

Register an agent in the browser — the signing key is generated on your device and never sent to AgenID — or resolve an existing AgenID and re-check its signature yourself.