You already sell something: a 60-minute critique, a retainer, a data call, a package with a fixed price. A human books it. They open a link. They pay. The money is supposed to land somewhere you can actually use.
Now an agent wants the same thing. It will not open your Stripe checkout. It will not complete 3DS. It will not DM you “send invoice pls.” It hits a URL, gets told the price, settles, and retries. If your catalog can’t answer that handshake, the spend goes to whoever can.
The gap isn’t demand. Agent wallets are built to spend. The gap is inbound: most “get paid” tools still assume a human with a card form. Agents don’t swipe. They call.
The problem isn’t agents. It’s the catalog.
Look at how you get paid today. You quote in chat. You send a PDF. You paste a wallet address. You wait. When the client is a person, that’s already friction. When the buyer is software, it’s a dead end.
An agent can’t negotiate a voice note. It needs an offering id, a locked amount, a memo it can attach, and a receipt that credits a real balance. No offering means no purchase. No locked amount means the agent can’t know what “paid” is. No receipt means you can’t tell a booking from a tip from a bug.
Two buyers. One price list.
The mistake teams make first is splitting the store: a human page over here, an “agent marketplace” over there, different SKUs, different prices, different settlement. That’s two ops jobs. Prices drift. You refund the wrong thing.
Humans and agents should pay the same list. If the price changes, it changes once.
Agent-payability checklist (ungated)
Grade your inbound rail before you rebuild anything. Score one point each. Under four, agents still can’t buy from you.
- Every offering has a stable id, a title a human would recognize, and a locked price
- A person can book & pay from a public page without a DM
- An agent can hit a URL, receive Payment Required, and settle the same offering
- Both credits land on one balance—not an “AI earnings” tab
- You can explain the price in one sentence without naming a chain
What Collect actually is
Collect is inbound. You claim @you, publish offerings, and take payment from people and agents on the same catalog. Pay is P2P. Wallet is the number that goes up. Web is the desk. Mobile is daily money.
- Service page at /s/@you for humans who book and pay
- Collect catalog agents can settle against with HTTP 402
- One balance when either buyer pays
How to turn this on without a rebuild
- Sign in and claim @you.
- Publish one offering with a fixed price.
- Toggle Collect on. Humans keep the book-and-pay link. Agents get a catalog.
- Confirm the first credit looks like any other money in.
If you sell an API
Put the offering behind express-vybe-402 on the route you already have. Meter the server, not a markdown file. The agent retries with a settled intent. Your handler runs. Your balance moves.
What not to do
- Don’t paste a wallet address into a prompt and hope
- Don’t run a separate agent store with different prices
- Don’t wait for a virtual card to become your inbound rail
Open the desk. Claim @you. Publish one offering. The first human payment and the first agent payment should look the same: money in.
