Picture an AI agent buying something for you and you'll probably picture a browser. The agent opens the store's website, types into the search box, clicks through product pages and fills in a checkout form built for someone with a mouse and a card. Underneath it, though, the agent is just software trying to make a request, and the merchant has had almost no say in how that request reaches it.
A new proposal called the Personal Agent Protocol (PAP) goes after exactly that. It surfaced in October 2026. The v0.1 spec hasn't been published; it's described as forthcoming. What has been announced is fairly narrow. An agent and a merchant open an authenticated session, and the merchant picks how the agent gets served: through the normal website, through a dedicated API, or by handing it to the merchant's own agent. Payments are left for later. They aren't part of the protocol today.
The interesting part is who decides
"Agents will buy things" isn't news. What we think will last, whatever the final spec looks like, is a shift in who holds the controls. Letting an agent in becomes something the merchant decides on purpose. The question stops being whether automated buyers can reach the store and becomes how: what identity the agent shows, which surface it lands on, and what it can do once it's there.
Merchants have wanted this for a while, protocol or not. Take a large retailer limiting how an outside shopping agent such as Muse interacts with its storefront. You could read that as a fight over who owns the customer. We'd read it more simply. The merchant wants a say in how automated buyers arrive, and a storefront built for humans gives it very few ways to have one.
We argued the structured-goods side of this in the agentic commerce stack for digital goods. PAP mostly gives the problem a name.
Publishing an API is the easy part
The quick takeaway from "merchant-controlled interface" is that every merchant should ship an API. You need one, sure. An endpoint on its own still doesn't give you much control, though. That comes from three separate decisions, stacked on top of each other:
- Identity. The merchant knows it's dealing with an agent, and often which one, rather than guessing from traffic patterns.
- Permissions. The merchant sets what that agent may see and do (browse, get a price, buy, take delivery) instead of exposing whatever a rendered page happens to leak.
- Routing. The merchant picks the surface. One agent goes to a typed API, another to a restricted web flow, a third to the merchant's own agent.
Where does "no registration" fit? It's a routing decision. Skipping signup removes an onboarding funnel built for humans, and that's all. The buyer isn't anonymous because of it, and fraud doesn't go away. The control is in how you shape the channel after that.
Why keys go first
Not every category is ready for this. Digital product keys are. A game activation code or a gift card has no shipping address, no warehouse and no physical variance, so the whole purchase comes down to four steps: look up the catalog, get a price, buy, receive the code. None of it needs a rendered page, which is a big part of why agents start here. The longer version of the argument is in agents won't buy pizza first.
Where cdk.bot fits
cdk.bot is our bet on that market. It's an agent-native API, also available over MCP, for buying digital keys with stablecoins: USDC, USDT or EURC on Base. An agent queries the catalog, gets a price, pays and receives the key, all programmatically. If you want to see every request, how an AI agent buys a Steam key with USDC walks through one purchase step by step.
We should be clear about what it isn't. cdk.bot is not a PAP implementation, and we won't market it as one. There's no v0.1 spec to implement yet. The overlap is in the instinct: an agent deals with a merchant over a surface the merchant controls, and it's identified as an agent while it does. PAP approaches that from the session side. We got there from the transaction side.
The differences are real. Our buyers are agencies and automated systems, not consumers with a personal assistant. We settle in crypto, and PAP doesn't touch payments, at least for now. And a tidy API doesn't exempt anyone from the ordinary realities of fraud and chargebacks.
What we're watching
We see PAP as a session and interface layer sitting above the transaction layer, where our rails live. So the two don't compete, and PAP doesn't replace x402, MCP or USDC either. Once v0.1 is out we'll be looking at two questions. Is the identity model specific enough that a merchant can actually enforce it? And will the protocol grow toward settlement, or stay payment-free by design?
None of that changes what builders can do this week. If your agent is driving a browser through a checkout that was always an API call underneath, stop putting effort into the puppetry and send it to merchants that treat agents as agents. For digital keys that interface is already live. The docs are at api.cdk.bot/docs, and the full game-buying agent post shows the whole loop end to end.
So, the title: agents don't shop the way people do. They call APIs, and how merchants answer those calls is where a lot of agent commerce will get decided.