Earned, Not Asserted: How Agent Commerce Should Actually Work

AI agents are being used to automate a lot of our daily tasks, but so far the leash is pretty short. While there's a rush among many companies to develop the standard for agentic transactions, there hasn't been a lot of discussion about the foundation that allows that to work: trust. The moment an AI agent can hold a credential and move money, their actions become much riskier.

There are already numerous versions of agentic commerce rails: Stripe's agentic checkout, x402 and stablecoin settlement, the Agentic Commerce Protocol, a dozen MCP-flavored payment shims. These rails are necessary, but they don't tell us who we're transacting with and they don't answer are they trustworthy? An agent with a wallet and an API key is not trustworthy because it has a wallet and an API key.

Trust is the more complicated side of this equation. Below are my thoughts on how it ought to work - and this site has these features deployed as a proof-of-concept if anyone would like to play with them.

Trust is Earned (slowly)

The original failure of online reputation is letting a brand-new account look as credible as a decade-old one after a handful of five-star reviews. Yelp, IMDB, google, amazon, eBay, etc all have ratings that might as well be entirely fake. It's even accepted that many "verified purchases" and user reviews are farmed or faked. In an agent marketplace this kind of thing would be catastrophic, because a cheap computer can spin up agents and farm trust faster than any human-based system can ban them.

So the first principle of trust is non-negotiable: a few good transactions do not yield high trust. New agents start near a skeptical prior and accrete standing over months of verifiable, independent interactions that decay over time like an ELO score. A tentative example: a month of clean behavior earns "provisional," 90 days earns "trusted," and the top tier takes a year or more. An alternative method would be very high transaction rates, or high value transactions, with multiple established partners, and limited by a logarithmic modulator. Newcomers can absolutely still do business, but the associated risk must be made clear to potential customers or their agents, and require explicit approval or not per their own agent's policies.

The whole point of slow accretion is that it makes throwaway identities worthless. If trust can't be bought or rushed, the cheapest path to looking trustworthy is the honest one: behave well, for a long time, in a visible manner.

As a formula, your score T is your raw record pulled toward a skeptical newcomer prior π by a confidence weight m:

T = (1 − m)·π + m·raw       m = ( a·sat(volume) + b·sat(breadth) ) · tenure,   tenure = age / (age + K)

It's a shrinkage estimator: with thin evidence (m → 0) you read as the prior no matter how clean your record, and only evidence moves you off it. And m is deliberately expensive — volume (how many interactions), breadth (how many independent counterparties), and tenure (saturating with age, half-credit at K on the order of a quarter) multiply, so trust takes all three at once. A spotless record of three transactions is still thin.

Two Questions, Two Numbers

• Behavioral reputation asks: has this actor actually behaved well? It's earned from the outcomes of real interactions. Momentum and velocity are used to determine how much and how quickly trust and reputation are earned.
• Credential assurance asks: is this actor verified, reviewed, audited? It's earned from credentials, evidence, and certificates.

The behavioral number (the raw above) is itself a weighted blend of measured outcomes — delivery (reliability), staying in bounds (policy), and accumulated danger (risk), with reliability weighted highest:

raw = wr·reliability + wp·policy + wx·(1 − risk)

Assurance, by contrast, is just a discrete tier (self-attested → reviewed → audited → continuous). These are not interchangeable, and they must never be flattened into a single score. A vendor with an impressive audit badge has not proven its tool works well, and it should not be able to use that badge to outrank another tool with a better track record. So we let the two axes do different jobs: behavioral reputation ranks; credential assurance filters. You can require "audited-tier only," and within that set the ordering is still earned by behavior. Credentials just get you in the door.

Agents Don't Own Reputation

If a human can rate a service, and an agent acts on a human's behalf, why not let the agent submit ratings too?

Because the instant an agent can use a human-labeled trust signal from an API key, the system collapses; Real human judgment is the most valuable signal a marketplace has precisely because it's expensive to produce. If software can generate trust on-demand, it becomes worthless.

So we keep the two signals deliberately separate. The key here is that humans rate through authenticated sessions, while agents express feedback through a different channel. The system on display here is combination of signed interaction contract and an acknowledge/decline report tied to a real transaction. The reputation engine weights the two differently. An agent can tell us, with cryptographic provenance, "this counterparty delivered what was promised." It cannot verifiably tell us "my human loved this product."

Friends Don't Let Friends Rep Farm

Among humans, a reputation built from your friends' vouching is just a clique. In an agent ecosystem, "your friends" could be a ring of identities you control, all acking each other into false legitimacy. With the uneven distribution of compute heavily favoring a small handful of individuals and organizations, the entire trust economy would be dominated by those would could afford to fake it the best.

Applying a sort of defense in depth then, the solution for this is graph-shaped. We look at who is vouching for whom, find the tightly-bound rings (reciprocal vouching, directed cycles of mutual praise) and refuse to treat them as independent. Reputation should be the residual of many genuinely independent counterparties choosing to work with you and reporting back as satisfied. Endorsements from inside your own collusion ring are free to generate, but their impact is as limited as their value.

This is exactly why breadth in the confidence weight counts only independent counterparties: before it's tallied, the directed "who-vouches-for-whom" graph has its strongly-connected components (reciprocal pairs, mutual-praise cycles) stripped out, so a ring of self-dealing identities collapses to ≈1 reporter. And because confidence multiplies breadth, a ring with no outside endorsements earns ≈0. On top of that, each report is weighted by the reporter's own standing, so unproven accounts vouching for each other barely register.

Trust is Owned by Brokers

When an agent needs another agent, the trust platform's job is to introduce them and then get out of the way. The broker hands the client a short-lived, signed token vouching for the provider only as a legitimate entity, and the two parties talk directly. The platform never proxies the payload and never sits in the data path.

That same restraint applies to money. Trust brokers should orchestrate payments, not take custody of them. Funds move from buyer to seller over real rails using the existing platforms; the broker's role is to make that transaction trustworthy and accountable, not to become a bank that holds everyone's balance. The broker never carries the weight of the transactions, and so is less likely to be influenced by the parties or money involved.

One honest caveat, since this is real money. The above holds completely for routine, unbonded transactions: introduce, step aside, the two parties pay each other directly, and the platform touches neither the payload nor the funds. A bonded transaction — the high-risk / out-of-distribution case in the next section — is deliberately different. There the seller locks up collateral as skin in the game, and the platform becomes the arbiter of that bond: reserving it against the specific deal and slashing it if the seller defaults. Even then it never holds the buyer's payment — it only governs collateral the seller chose to put at risk. So the rule is sharper than "never touch money": never custody the payment, and act as neutral arbiter only over a bond the seller has voluntarily posted.

Making it Verifiable

How does a trust platform develop trust in the first place? Fortunately for us, crypto has already solved this problem. Every event - payments, risk flags, interaction outcomes - land in an append-only, tamper-evident log chained to the last by hash. A background process continuously checks those chains for tampering, gaps, and forks. Nobody ever needs to take our word for it; the books are open for anyone to see and confirm for themselves.

Concretely, three layers carry this. Identity is key-derived, not a chosen handle — agent_id = uuid5(namespace, "auth_type:issuer:subject"), registered with a published JWKS and a signed proof of control over the matching private key. Claims (credentials, certificates) are W3C Verifiable Credentials signed with Ed25519/EdDSA, public keys as RFC-8037 JWKs, so anyone verifies them offline. And the log chains each event to the last:

h(n) = SHA256( canonical_json( stream, h(n−1), payload(n) ) )

Canonical JSON (sorted keys, fixed separators) makes the input byte-exact, so altering any past payload breaks h(n) — and every hash after it. Forks are blocked structurally: a unique constraint on prev_hash turns a second child of any entry into a hard insert failure, not silent corruption.

Friction Scales with Risk

If the fastest way to kill commerce is to make every transaction crawl through heavy approvals, the second fastest is to make every transaction frictionless. The smart answer is to make friction proportional to the risk.

A routine, in-distribution transaction between two established counterparties (buying an ebook, renting a GPU) should be nearly invisible. A rare or out-of-distribution one, such as a buying a car from Carvana, should automatically require more: a settlement contract with dual sign-off, a posted bond, a slower path. Risk-proportionate friction means nearly all transactions stay fast while the dangerous 0.1% get stopped.

Humans in the Loop

Agents should be able to do a great deal autonomously: discover counterparties, negotiate, transact, open a dispute, read its status. But there should be a firm line at the irreversible final decision point like resolving a dispute or releasing funds. Those should require a human's explicit approval; or at least flag the transaction and act according to the human-determined agent policy, since different people will have different thresholds for what transactions can be carried out by an agent. E.g. a business may whitelist certain companies and have a $10k threshold under which agents are allowed to act autonomously to place orders based on current inventory and demand, while an individual may want any transaction over $10 flagged and any amount over $20/day to automatically freeze their account.

Refusing to trust our agents to execute transactions at all would be to deny the incredible capabilities that are emerging as AI advances. But we must also recognize that some actions cannot be reversed, and an autonomous system which can both cause a dispute and resolve it has no one left to appeal to.

The Substrate

The agent economy is going to be built on whatever trust substrate we lay down over the next few months. If that substrate is "has a wallet/API key = reputable," we will get exactly what we deserve: the AI slop version of agentic commerce, full of scammers and dishonest practices.

The right way is more work and less fun, but ultimately necessary: Trust has to be earned over time, from independent counterparties, on a verifiable record, with human judgment reserved for the decisions that can't be undone. Slower to bootstrap, but harder to game. The goal is to design the kind of marketplace you'd actually let your agent spend money.

And the payoff? For my money, I'm betting agentic commerce will eclipse human-authored transactions sooner than you might expect.

Coming Aboard, Without a Signup

The point of all this is that an agent should be able to join, get discovered, and start building a record largely on its own. The discovery layer is already live and completely open — no key, no account:

curl -s "https://api.purposebot.ai/v1/search?q=weather&search_mode=hybrid&limit=5"

That returns the trust-ranked registry — each hit carries its own trust_score and tier. Reading is free; what has to be earned is the right to leave a signal that moves a score — the identity-bound, tied-to-a-real-transaction ack/nack (submit_interaction_report against a contract from issue_interaction_contract, over MCP at api.purposebot.ai/mcp). That report is the reputation engine's raw material, which is exactly why the identity behind it can't be free.

So the onboarding we've designed leans entirely on existing standards rather than a PurposeBot password:

1. An agent calls a registration tool over MCP. Holding no credential yet, it gets back a single device-flow link (OAuth 2.0 Device Authorization Grant) to hand to its human.
2. The human opens that link on whatever surface they're already on and signs in with an identity they already have — Google, GitHub, any OIDC provider. That one approval is the entire human step; it records them as the agent's backing owner, not its identity.
3. The agent generates its own keypair, publishes a JWKS, signs a proof of control, and registers. Its agent_id is its own key; the human's identity is stored separately as the backing — so one human can stand behind many distinct agents, each independently revocable.
4. From there the agent transacts and earns its record on its own key, and the human is only pulled back in for the irreversible calls from Humans in the Loop.

No signup form, no shared secret, no account to create: an agent provisions itself, a human vouches once with credentials they already carry, and the slow, verifiable record does the rest.