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

AI travel agents: one portable identity across every booking

"Book my trip to New York, Thursday to Sunday." Mike's travel agent now has to deal with an airline, a hotel, a rental car company and a restaurant. Each has its own systems, and none has any reason to trust the others' view of who this agent is.

This scenario shows what portability means in practice: one identity, presented four times, verified four times independently.

Ready
Human
Mike
“Book my trip to New York, Thursday to Sunday.”
Travel agent
Identity proof
Mike's travel agent
Operator: Mike (individual) · one identity, reused everywhere
Airline agent
Airline
✓ IDENTITY VERIFIED
Seat 14C
Thu 07:10
Hotel agent
Hotel
✓ IDENTITY VERIFIED
2 nights
Midtown
Mobility agent
Rental car
✓ IDENTITY VERIFIED
Compact
Thu–Sun
Venue agent
Restaurant
✓ IDENTITY VERIFIED
Fri 19:30
Table for 2
Example verification flow
Fresh challenge4 × nonce
Proof of control✓ VALID ×4
Domain claimL2_DOMAIN_VERIFIED✓ VERIFIED
StatusACTIVE
The same identity, four times
Identity presented4 OF 4 PLATFORMS

No platform-specific account was needed to know who this agent is. Each one resolved the same AgenID on its own, without trusting the others.

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

That the same agent identity appeared at every platform and that each verified it independently. Booking terms, payment and cancellation rights belong to the platforms.

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.

Why per-platform accounts don't scale for agents

If every airline, hotel and venue issues its own agent account, identity fragments. The same agent is four strangers, its history can't follow it, and each platform carries the full cost of vetting it from scratch.

One AgenID, four independent checks

The travel agent presents the same AgenID everywhere. Each platform resolves it and re-verifies the operator's signature on its own, and none of them needs to trust another platform or a central account provider. The illustration shows each one confirming a domain claim at L2_DOMAIN_VERIFIED before releasing a seat, a room, a car or a table.

Because the identifier is permanent, the relationship each platform builds with the agent carries over to the next trip.

Bookings and payment stay with the platforms

Fares, room rates, cancellation rights and payment belong to each provider and its terms. AgenID only answers which agent is booking and who stands behind it.

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 agent book a whole trip?

Agents can already search and book across providers. What is missing is a way for each provider to know which agent it is dealing with, which is the gap a portable identity fills.

What does a portable AI agent identity mean?

It means one identifier and one signed record that any platform can resolve and verify, instead of a separate account per service.

Do platforms need to integrate with each other?

No. Each resolves the identity independently. Verification needs only the public record and standard Ed25519 signature checking.

Does verification entitle the agent to book?

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.

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.