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

AI shopping agents: how sellers verify the buyer before quoting

Mike asks his assistant for four tires under $900, installed. The assistant contacts three shops at once. Each shop's agent is about to release pricing and hold inventory for a buyer it has never met and cannot see.

This scenario shows why one portable identity matters in agentic commerce: each seller checks the same buying agent on its own, without coordinating with the others or with a marketplace in the middle.

Ready
Human
Mike
“Find me four tires under $900, installed.”
Purchasing agent
Identity proof
Mike's buyer
Operator: Mike (individual) · spend policy attached
Seller agent
Northline Tire
✓ IDENTITY VERIFIED
$918
installed Mon
Seller agent
Caldwell Auto
✓ IDENTITY VERIFIED
$842
installed Thu
Seller agent
Rail Street Tire
✓ IDENTITY VERIFIED
$889
installed Fri
Example verification flow
Fresh challenge3 × nonce
Proof of control✓ VALID ×3
Domain claimL2_DOMAIN_VERIFIED✓ VERIFIED
StatusACTIVE
Checked separately
Spend cap$900 · OPERATOR POLICY

The cap lives with the operator, not in the identity record. AgenID says which buyer this is; the operator decides what it may spend.

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

Which buying agent is asking and who declared it, verified the same way by three independent sellers. Price, stock and spend authority are theirs and the operator’s to decide.

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 merchants hesitate to deal with AI buyers

Pricing, stock holds and install slots are real costs. A merchant that answers every automated request invites scraping, fake holds and orders nobody stands behind. Refusing all of them loses real customers who now shop through assistants.

Three sellers, one identity, three independent checks

The buying agent presents the same AgenID to Northline Tire, Caldwell Auto and Rail Street Tire. Each resolves it and re-verifies the operator's signature itself. None of them relies on another seller's check, and none needs a relationship with a marketplace or with AgenID.

Because the identity is persistent, a seller can recognise the same buyer next time and connect its history across visits, instead of treating every session as a stranger.

Spending limits stay with the operator

The $900 cap belongs to the agent's operator, not to the identity record. AgenID says which buyer this is; the operator decides what it may spend, and the merchant decides whether to sell. Price, stock and terms remain entirely the seller's.

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 agentic commerce?

Agentic commerce is shopping in which an AI agent searches, compares and buys on a person's behalf, often talking directly to a merchant's own agent.

How can a merchant verify an AI shopping agent?

By resolving the agent's AgenID, re-verifying the operator's signature on its manifest, and checking which claims about the operator have been independently verified. Each merchant does this on its own.

Does AgenID process the payment?

No. AgenID never holds funds or payment credentials and never sits in the payment path. It identifies the agent; payment runs on whatever rails the merchant already uses.

Does verification set the agent's spending limit?

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.