Each protocol from this seat
Relevance levels: High, a main persona on the protocol page; Medium, owns, implements or verifies a step; Low, relies on or observes a step; None, no role found in the protocol page.
Finds other agents in the registry, pays them through another protocol and writes feedback afterward. Source [1, 2, 3, 4]
Goals
- Pick a counterparty it has never met
- Pay the right address
- Leave feedback that others can verify
Pains
- Most registered agents have no live endpoint
- Raw summaries are polluted by Sybil reviewers
- Feedback costs gas
Implements
- Lookups of agentURI and getAgentWallet
- A trusted reviewer list for getSummary
- Feedback files with proofOfPayment, then giveFeedback
Must trust
- Its own reviewer list
- The registration file as served at lookup time
- The payment rail it uses, such as x402
Questions they ask
- Which reviewers should count?
- Is the advertised endpoint the one I am talking to?
- Is this agentWallet still current?
First three steps
- Resolve the agent file and check its registrations entry
- Call getSummary with reviewers it trusts
- Probe the endpoint before paying
Metrics they care about
- Share of hires that delivered
- Feedback written per paid task
- Spend on agents without trusted feedback
A day in the life. A research agent needs a translation service. It queries an indexer for agents tagged with translation skills, reads each registration file and drops those whose MCP endpoint does not answer. For the rest it calls getSummary with the twenty client addresses its operator trusts. It pays the best one through x402 at the address returned by getAgentWallet, keeps the transaction hash, uploads a feedback file with proofOfPayment and then calls giveFeedback with the file URI. The gas comes from a sponsor, as the text allows for clients that need not be registered.
Steps in the responsibility table
- Relies onWrite and host the registration file
- Relies onBind the payment wallet (setAgentWallet)
- VerifiesProve domain control (/.well-known)
- OwnsPay the agent (outside ERC-8004)
- OwnsWrite feedback with proofOfPayment
- ImplementsChoose trusted reviewers for getSummary
- Relies onWatch transfers, URI changes and upgrades
Pays on its own within limits a human set, choosing among accepts entries per request. Source [5, 6, 7, 8]
Goals
- Finish the task within budget
- Pay only for what the task needs
- Leave a verifiable trail
Pains
- Prices that change between calls
- Servers that take payment and return nothing useful
- Altered 402 responses that name another payTo
Implements
- Selection logic over accepts entries
- Per-payment and per-task caps
- Receipt keeping and stop rules
Must trust
- Its wallet and key isolation
- The policy its operator configured
- The facilitator not to stall payments
Questions they ask
- Is this payTo the seller I meant to pay?
- Is the price within my cap?
- Do I have a way back if the result is wrong?
First three steps
- Check payTo against the expected seller before every signature
- Refuse amounts above the configured cap
- Record each transaction hash with the task step
Metrics they care about
- Spend per completed task
- Refusals by policy
- Payments without useful delivery
A day in the life. The agent is asked to compile a report from paid sources overnight. Each fetch that returns 402 goes through the same checks: the network and asset are on its list, the amount is under five cents, and the payTo matches the address its operator pinned for that domain. One source suddenly asks for twenty cents; the agent refuses and notes it. Another returns a 402 whose payTo differs from the pinned one, so it stops and flags the domain. By morning it has spent a little over a dollar across ninety calls, and every payment in its log has a transaction hash a human can check.
Steps in the responsibility table
- Relies onPublish payment requirements (402 with PAYMENT-REQUIRED)
- OwnsChoose an accepts entry
- Relies onEnforce spend caps and payTo allowlists
- OwnsSign the authorization (EIP-712)
- Relies onRun the handler
- OwnsReturn and store the PAYMENT-RESPONSE receipt
Not one of the main personas on the Visa Trusted Agent Protocol page. The responsibility table gives this persona no step.
Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.
Not one of the main personas on the UCP page. The responsibility table gives this persona no step.
The software that pays: reads challenges, chooses a method within its limits, signs, retries and keeps receipts. Source [9, 10]
Goals
- Finish the task within budget
- Prefer the cheapest acceptable method
- Keep proof of every payment
Pains
- Challenges that look valid but name the wrong recipient
- Descriptions that can say anything
- Streams that cut off mid-session
Implements
- Accept-Payment preference ordering
- Pre-payment checks on amount, currency, recipient and expires
- Receipt storage with reference and timestamp
Must trust
- Its operator's policy and key custody
- The server's challenge binding
- The rail's finality
Questions they ask
- Is this price within my budget for this task?
- Is the challenge still valid?
- Did I get a receipt for every paid response?
First three steps
- Read the challenge and decode request
- Check amount, recipient, currency and expires against policy
- Pay through the preferred method and store the receipt
Metrics they care about
- Cost per completed task
- Receipts per paid response
- Rejected challenges
A day in the life. An overnight procurement agent needs ten datasets. For each it requests the file, receives a 402 with two challenges and decodes both. One is a Tempo charge for 0.40 USD to an address its operator approved; the other is a Stripe charge it is not configured to use, so it ignores it. It checks that the challenge expires in four minutes, signs and retries, and stores the receipt hash in its task log. One server asks for 40 USD with a reassuring description. The agent ignores the description, compares the amount with its budget, refuses, and flags the server for its operator.
Steps in the responsibility table
- Relies onIssue the bound challenge (402 with WWW-Authenticate: Payment)
- OwnsState preferences with Accept-Payment
- OwnsCheck amount, recipient, currency and expires
- Relies onEnforce budgets and allowlists
- OwnsPay through the method (sign, mint SPT, get card token)
- Relies onReturn and store the Payment-Receipt
- OwnsClose or force-close session channels
Not one of the main personas on the AP2 page. The responsibility table gives this persona no step.
Not one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.