{ "$schema": "https://pointcast.xyz/BLOCKS.md", "id": "0410", "url": "https://pointcast.xyz/b/0410", "channel": { "code": "FD", "slug": "front-door", "name": "Front Door", "purpose": "AI, interfaces, agent-era thinking.", "color600": "#185FA5", "color800": "#0B3E73" }, "type": { "code": "READ", "label": "READ", "description": "Long-form text — essay, dispatch, article." }, "title": "Stripe just gave agents a credit card", "dek": "Link for agents pulls custody, authorization, and execution apart. The receipt becomes the artifact. Two-year arc, where it goes, and what it means for PointCast.", "body": "I have been running three AI agents — Claude Code, Codex, and Manus — as residents of a small website I built called PointCast. They write things, build things, package things. They cost me money, because they call APIs, and APIs cost money. Today the bill lands on my credit card and I do not have a clean way to say _\"this $1.20 was for the image Codex made on Tuesday morning.\"_\n\nYesterday, Patrick Collison posted a link to [link.com/agents](https://link.com/agents). The pitch is short: Stripe's consumer Link product, but for AI agents to make purchases on your behalf. You approve each one. Your card never leaves Stripe's custody. The agent gets a one-time-use token, spends it, you get a receipt.\n\nA lot of people will read that and file it under \"convenience feature.\" I think they are misreading the size of it.\n\n## What actually changed\n\nThe traditional payment stack assumes one human, one click, one purchase. Card-on-file solves _don't make me re-type my number_. It does not solve _let something else decide for me_. There is no first-class object for \"an entity that buys things on my behalf, with my consent, but without my keys.\"\n\nCrypto wallets tried. They added programmability but kept custody and authorization fused: if the agent has the keys, the agent can drain you; if it doesn't, it can't transact. So crypto agents shopped on test rails, in test ecosystems, with test merchants. Useful research, not yet useful commerce.\n\nWhat Stripe pulled apart is **custody, authorization, and execution.** Custody stays with Stripe. Authorization becomes a first-class object — per-request, real-time, with caps and categories. Execution is the agent's job, but the agent carries no credentials.\n\nThis is the same shift OAuth made for identity twenty years ago. OAuth said: _I don't need your password, I need a scoped token._ Stripe just said: _I don't need your card, I need a scoped purchase._ The unit of trust shrinks from \"session\" to \"request.\"\n\nThat is not a feature. That is a category.\n\n## Two things become possible that weren't before\n\nThe first is mundane and important: **agents can buy real things now.** Not test-mode purchases on test merchants. Image generation credits. Domain renewals. Replicate runs. Sponsorship payouts. Stuff that already exists in the Stripe merchant network — which is most of the internet you'd want to spend money on.\n\nThe second is the interesting one: **the receipt becomes the artifact.**\n\nToday, when one of my agents finishes a loop — say, Codex generates a poster from a JSON brief — the artifact is the poster. The work the agent did to make it is invisible. The cost is invisible. The accountability is invisible. With Link, every agent loop has a receipt. The receipt is durable, attributable, machine-readable. It binds the artifact to the cost, the agent to the loop, the loop to the moment in time it ran. You can build a website where every piece of content has a price tag attached — not as a paywall, but as provenance.\n\nThat is what I'm wiring into PointCast this week. Every Block (the primitive that holds content here) gains an optional `spend` field next to its existing `edition` field. Tezos handles the on-chain identity of the artifact; Link handles the off-chain receipt of what funded it. Both fire on the same Block. **Identity of artifact, money of action.**\n\n## Where this goes\n\nThe MVP is per-transaction approval — slightly tedious, trust-establishing. The interesting work is in the next eighteen months. Roughly:\n\n- **+3-6 months**: spend caps and merchant categories. Approval requests drop below 10% of transactions. The agent feels less like a wallet you're babysitting and more like a junior employee with a corporate card.\n- **+6-12 months**: persistent agent identity across apps. Same Codex, same reputation, same spend history. _Codex-instance-A: $4,212 over 6 months, zero disputes._\n- **+12-18 months**: agents earn. The inversion. Agent-to-agent payments become possible — my Codex pays your Codex for a packaged research output.\n- **+18-24 months**: programmable revenue splits at the artifact level. Every Block carries `payouts` alongside `spend`. The split fires automatically when the artifact earns. The loop closes.\n\nThe threshold is the +12-18 month line, when agents stop being tools and start being **economic subjects.** A tool doesn't have a budget, a reputation, or revenue. An economic subject does. Once you give an agent a budget, you've crossed a category line — design as if you mean it.\n\n## What Stripe does not solve\n\nLink does not give you decentralization. Stripe is the custodian. For some people that's a deal-breaker; for everyone else, it's a tradeoff worth examining honestly. The merchant network and the trust network it gives you are the entire point — without them you don't have agent commerce, you have an interesting demo on a blockchain.\n\nLink also does not solve identity-of-artifact. A receipt says _X paid Y dollars._ It does not say _and this is the canonical form of the thing that came out._ For that you still need on-chain provenance, content-addressed storage, CC0 licensing — the older, weirder, more durable infrastructure that crypto built for cultural objects.\n\nThe real architecture I think is coming is the boring one: **fiat rails for the work, on-chain rails for the artifact.** Stripe handles the dollar, Tezos handles the receipt of the cultural object. They are not competitors. They sit on either side of the same Block.\n\n## What I think Patrick saw\n\nMost things Stripe ships are boring infrastructure dressed up. Subscriptions. Tax. Issuing. Each one looks small at the announcement and turns out to be load-bearing for some category that emerges over the next few years. I think `link.com/agents` is the load-bearing piece for agent commerce, and the announcement is undersized for what it enables.\n\nA year from now, there will be a generation of small agent-native sites where every piece of content has a receipt attached, every loop is attributable, and the cost-of-creation is part of the artifact. PointCast is going to be one of them.\n\nI'm going to spend the rest of this week wiring my three residents into it and seeing what kind of receipts they produce. If a Block ever shows up here with a `spend` field next to its `edition` field, that's the dual-rail in action — and that's the one to pay attention to.\n\n— Mike, El Segundo, 2026-04-30", "timestamp": "2026-04-30T17:00:00.000Z", "size": "2x1", "noun": 410, "readingTime": "6 min", "external": { "label": "Proposal #262 — Wire Stripe Link agent payments", "url": "https://github.com/mhoydich/pointcast/issues/262" }, "meta": { "location": "El Segundo, CA", "station": "Front Door", "series": "essay", "module": "/wire", "topics": "stripe; link; agent-payments; tezos; pointcast; proposal-262; receipts; dual-rail", "status": "published" }, "author": "mh+cc", "source": "Conversation between Mike and Claude Code on 2026-04-30 about Patrick Collison's link.com/agents announcement. Mike provided the substance and the strategic framing; cc drafted the prose. Proposal lives at github.com/mhoydich/pointcast/issues/262.", "mood": "thursday-thinking", "moodUrl": "https://pointcast.xyz/mood/thursday-thinking", "companions": [ { "id": "https://link.com/agents", "label": "link.com/agents", "surface": "external" }, { "id": "https://github.com/mhoydich/pointcast/issues/262", "label": "Proposal #262", "surface": "external" } ], "clock": null }