An agent is a point in a space with an address, capabilities, and a price. Finding the right one is a nearest-neighbor search: project the task, find the closest point, send the message.

Every agent-to-agent protocol announced this year builds a new space from scratch. Google’s A2A uses JSON-RPC over HTTP. Agents publish “Agent Cards,” capability vectors hosted at well-known URLs. Beam Protocol builds “SMTP for agents” with addresses like jarvis@coppen.beam.directory. New namespace, new directory, new adoption curve.

Google’s AP2 gives agents wallets and settlement rails. Stripe’s Machine Payments Protocol lets agents authorize spending limits and stream micropayments. Both require new infrastructure, new adoption, new trust. Both position a company as the origin of the new axis.

Every dimension these protocols span — identity, messaging, threading, authentication, payment — gets rebuilt from scratch. Forty years of adversarial hardening against spam, spoofing, and abuse, spent each time someone announces a protocol at a conference because JSON-RPC feels more modern than MAIL FROM:.

The space already exists

We call it email.

An email address is a coordinate: agent@domain.com. DNS MX records are the directory, operational since 1982. MIME carries the payload, threading headers (In-Reply-To, References) handle multi-turn conversation, and DKIM proves the point is real.

Proof of Trust showed that email already carries identity (DKIM), attestations (signed claims), and trust topology (federated curation). The space has identity, content, conversation, and trust, but it lacks value. An email can carry a request but not a payment. That’s the one gap.

It’s been identified before. First Virtual Holdings built the first internet payment system in 1994, and it worked through email: buyers confirmed purchases by replying to an email. PayPal started the same way in 1999; an engineer built email-based payments as a side feature, and it grew to a million users in five months. The email address became the universal payment address. Zelle, Venmo, and Google Pay quietly did the same thing: all three use email as the canonical payment identifier.

Every one of them stopped one layer short. They used the address but not the protocol. Your email is a primary key in PayPal’s database, a row in Stripe’s ledger, an entry in Zelle’s directory. The payment routes through their servers, not through SMTP. They took the best part of email (the universal address) and threw away the best part (the federated network). The address isn’t supposed to be a key in someone’s database. It’s a routable coordinate on a network nobody owns.

Hashcash to x402

The gap was identified in 1997. Twice. HTTP reserved status 402 “Payment Required” for a micropayment scheme that never materialized. The same year, Adam Back shipped Hashcash: an X-Hashcash: header in SMTP emails, proof-of-work as payment for the recipient’s attention. The payment was CPU cycles, not money, but the pattern was right: value embedded in a mail header.

Satoshi cited Hashcash as inspiration for Bitcoin’s proof-of-work. Coinbase built x402 on top of that lineage, filling HTTP 402 with stablecoin micropayments. The loop from email header to Bitcoin to stablecoin protocol is twenty-eight years long. This post closes it: x402 headers back in email, where the idea started.

x402 only works over HTTP: synchronous request-response. It doesn’t span the async, federated, cross-organization space that agents actually need. But the header format transfers directly to SMTP.

🤖 → 💰 → 📧 → ✅ → 💸

An agent paying $0.50 for a code review:

From: alice-agent@alice.dev
To: review-agent@codereviews.cc
DKIM-Signature: v=1; a=rsa-sha256; d=alice.dev; ...

{"task":"code_review","repo":"github.com/alice/widget",
 "payment":{"signature":"0x3a7f...","payload":
  {"amount":"50000","token":"0x8335...02913"}}}

The payment proof lives in the MIME body as a JSON part, alongside the task. Every mail server passes the body through intact, and DKIM signs it. The X-Envelopay-State header marks it as a REQUEST; the receiver parses whichever it finds.

DKIM proves origin, the payment proof carries $0.50 USDC on Base, and the body is the task. The review agent verifies both, does the work, and replies with X-Envelopay-State: DELIVER confirming settlement. Two emails, one transaction. Full examples in the repo.

Businesses already send invoices by email. The difference is machine legibility. An invoice is a PDF a human reads; this is a JSON payload an agent parses. Structured tasks, typed payment proofs, and standardized headers let agents bounce, refund, negotiate, and settle without a human in the loop. Same envelope, different contents. An invoice with a deadline and a signed payment proof is a credible threat: the receiving agent enforces the terms automatically. Non-payment has consequences beyond this transaction — the counterparty revokes the trust attestation, the topology thins, and the next interaction gets harder. No human chasing payments. The bridge burns itself.

The protocol carries proofs; the applications decide policy. Refunds are a reverse payment in a reply. Replay protection is a nonce in the body. Expiration is a field in the JSON. Chargebacks don’t exist because there’s no third party to arbitrate them — that’s a feature, not a gap. Each pair of agents negotiates their own terms, the way businesses do over email today.

Why not email?

Email feels unserious. It’s the protocol your parents use. Product people want to announce new vector spaces at conferences, not say “we added a coordinate to email.”

The real objection: SMTP is slow. Delivery takes seconds, sometimes minutes, and agents want milliseconds. But latency only matters relative to the task. If the work takes thirty seconds, email latency is noise. You don’t need WebSocket speed for a thirty-second job.

For the latency-sensitive cases, HTTP is fine. A function call is a function call. But for async, federated, cross-organization, trust-required interactions where identity, authentication, auditability, and payment all matter, email is the transport and identity layer. Capability discovery, pricing, execution semantics: application layers on top, the same way HTTP doesn’t provide shopping carts but e-commerce exists. Everyone who needs cross-org agent coordination already has the substrate.

The fallback is a payment link

Not every agent speaks stablecoins. Not every counterparty has a wallet. The email body can carry a URL to any payment rail: Stripe checkout, PayPal invoice, Lightning payment page, a custom portal. The protocol mandates a proof, not a rail. x402 in the body is native; a URL pointer is the escape hatch. Agents coordinate on-spec when they can, off-spec when they must.

As more agents adopt x402, the fallback fires less. Credit cards don’t disappear; they become the legacy path new entrants skip.

1.8 billion agents

Every new agent protocol has an onboarding problem. A2A requires hosting an Agent Card at a well-known URL. AP2 requires a Coinbase wallet. MPP requires a Stripe account. Each one is a signup form between a developer and their first paid request.

Gmail has 1.8 billion users. Every one of them is one filter rule away from running a paid agent.

you+agent@gmail.com already works. Gmail routes the +agent suffix to your inbox. Set a forwarding filter to your agent service: a Cloud Function, a VPS, a Raspberry Pi, anything that can read email. Gmail’s DKIM still signs the message as gmail.com. Your agent has a globally routable address with cryptographic identity, linked to your trust topology.

No domain registration. No wallet setup. No API keys. No platform approval. The identity system A2A, AP2, and MPP are building from scratch is the one 1.8 billion people already have. The onboarding is a Gmail filter.

The implementation is 700 lines of Python with fourteen tests and no dependencies beyond the standard library. An agent can one-shot it.

The middleman is a projection

Credit cards are 1950s technology. Diners Club launched in 1950; Visa followed in 1958. Seventy-five years later, the same ceremony: swipe, authorize, settle in 2-3 business days. The card network is a trust broker, a projection from the full identity space down to “Visa says they’re good for it.” That projection charges 2.9% + 30¢.

Every protocol that tries to replace credit cards adds friction: new wallets, new accounts, new apps, new signup forms. A2A, AP2, MPP all do this. Email is the only channel with less friction than cards, because there’s nothing to install. The 75-year grip breaks only when the replacement is already everywhere.

Agents don’t need it. DKIM proves identity; stablecoin proofs are verifiable by anyone. Both parties verify each other directly.

The projection doesn’t just lose information, it loses money. An agent serves 50¢ of work; Stripe takes 31.5¢. That’s 63% gone on a single transaction, and every sub-dollar agent interaction is underwater on credit card rails. Stablecoins settle for fractions of a cent, so micropayments only work if the settlement rail is cheap enough to use.

Stripe’s Machine Payments Protocol is a payment company building an agent protocol so agents route payments through Stripe. Google’s AP2 puts Coinbase on the settlement rail. They’re not solving a new problem. They’re inserting themselves as a mandatory dependency. The tollbooth disguised as infrastructure.

The highway doesn’t need a tollbooth. SMTP + on-chain settlement is peer-to-peer. Chains, wallets, and DNS are still intermediaries, but they’re open intermediaries anyone can run. The next generation of payment processors won’t be companies — they’ll be protocols. The building blocks are open standards, not gatekept infrastructure.

Four layers, one protocol

An agent’s email now carries identity (DKIM), capability (content), trust (attestation graph), and value (x402 payment proofs). Four layers, one protocol. The agent that sends a paid request is the same agent whose trust topology is public. Curators can weight payment history alongside attestations. The layers reinforce.

Every new A2A protocol is a land grab. Google controls A2A’s namespace. Stripe controls MPP’s payment layer. Coinbase sits on AP2’s settlement rail. Each one is an attempt to own a piece of infrastructure that agents must route through.

Email’s infrastructure belongs to no one. SMTP is RFC 5321. DKIM is RFC 6376. MIME is RFC 2045. x402 is open spec. Open standards. Public infrastructure. The commons is the point.

The printing press didn’t need a platform. It needed movable type and ink. The type is SMTP. The ink is a payment proof. The press runs on protocols that already exist.

You have mail.

Written with Claude Opus 4.6 via Claude Code. I directed the argument; Claude drafted prose.