Closing the Sale When the Buyer Is an Agent

When the Buyer Stops Being a Person

Your checkout page is built for eyes. The progress bar, the trust badge, the countdown timer. An agent calling your API does not render any of that. It filled a cart. Now it needs to close the sale, and your "Complete Your Order" button means nothing to it.

This is the problem sitting in front of anyone running commerce infrastructure right now. You built a funnel for human attention. The buyer increasingly is not human. Agents do not browse testimonials, feel urgency from a red banner, or abandon a cart because the phone rang. An agent submits a request and either gets back a confirmation or an error.

Two models are emerging for what "close" means when the buyer is an agent, and they are pulling in different directions.

Model One: The Agent Shops, a Person Pays

The first model keeps a person in the checkout path. The agent does the work of shopping: searching, comparing, filling the cart. But it does not place the order or charge the card. That step belongs to the person who owns the wallet.

Anthropic's commerce-agents repository, a reference blueprint for building shopping and merchant agents, lays out exactly this separation. In the blueprint, nothing places an order, charges a card, or changes a live listing. The checkout function renders the cart for the host to complete (commerce-agents README). The shopping agent's five flows cover searching, comparing, planning, answering order and policy questions, and remembering what a customer tells it. Closing is not one of them.

This model trades friction for trust. The person still sees the cart, still confirms payment, still has the chance to back out. The agent is a shopper that hands off at the register. If your buyers are agent-driven, this model means your checkout page stays relevant. You just need the cart state the agent fills to be something your checkout can consume.

The tradeoff is plain. If the agent can put items in the cart but cannot complete the purchase, you depend on a human to cross the line. For B2B catalog buying where a person approves anyway, that is fine. For consumer speed or convenience, it is a bottleneck.

Model Two: The Agent Pays

The second model removes the human from checkout. The agent has payment authority, or at least payment details, and closes the sale on its own.

A post on Hacker News titled "Send flowers from your AI agent and make your mum happy" shows what this looks like in practice. The author built an MCP server that lets agents send flowers without creating an account. One bouquet type, one price per country: $100 in the USA, £100 in the UK, €100 in Germany, with Switzerland and Italy also supported (Show HN post). The service, prezent.net, is designed so an agent can trigger a tangible delivery with a single call.

Notice what is missing. There is no account, no login, no checkout page. The purchase is one API call with a fixed price and a fixed product. The author says the service was built after working on a family AI assistant that "desperately needed to trigger something tangible" like a flower delivery (Show HN post).

The comments on the post are hostile. One commenter calls it soulless and says to "be a real person and send flowers to your mom yourself" (Show HN post). That reaction is worth sitting with. People will push back on agent-mediated purchases for personal gestures. The friction-zero design of the API is still the right architecture for transactional cases where an agent acting on someone's behalf wants to trigger a delivery, a gift, or a reorder. Here the product surface is the API surface.

What Closes the Sale for an Agent

When the buyer is an agent, closing is not persuasion. The agent is not weighing your value proposition against a competitor's. It is executing a tool contract. It has a checkout function or an MCP endpoint, and it either can call it or cannot.

This changes what you optimize. On Monday, the first move is to expose a checkout endpoint that accepts a cart and returns a payment confirmation or a payment link. If your API requires the agent to log in, browse a catalog through a web flow, and submit a multi-step checkout, you are asking software to pretend it is a person on a web page. It fails in ways you cannot reproduce in your testing environment.

The commerce-agents blueprint makes this concrete. The shopping agent is defined by its prompt, skills, tool contracts, and gates. Closing means the tool contract is met and the gates pass. The blueprint also shows the merchant side: every write the merchant agent makes is staged until a person approves it (commerce-agents README). So even on the sell side, the "sale" is a staged change sitting in a queue waiting for approval. The person does not approve the buyer's decision. The person approves the system's output.

Where This Breaks

The agent-pays model breaks in two places. First, the flat product surface. The flowers MCP offers one bouquet at one price. That works for a gift API. It does not work for a catalog with SKUs, variants, inventory levels, and shipping zones. If you expose a checkout endpoint for agents, you still need to expose the catalog, inventory, and pricing data that lets the agent fill the cart correctly. The commerce-agents shopping agent searches, compares, and plans before it fills the cart. That metadata surface has to exist for the agent to do its job.

Second, the relationship. No account means no customer record, no retention data, no upsell path. The flowers service deliberately removes signup friction to make the agent call simple. That is the right call for a single-purpose delivery trigger. It is the wrong call for your retail business, where the lifetime value of the customer matters more than the first transaction. You need to decide whether your agent checkout creates a customer record or fires off a one-shot order. That depends on what you are selling, not on what the agent can do.

The Decision in Front of You

If you sell to agents, you are designing two checkouts. One for humans, with the progress bar and the trust badges. One for agents, with a tool contract and a payment return. The human checkout is optimized for conversion. The agent checkout is optimized for completion. Different metrics. Different failure modes.

The human checkout fails when the customer loses attention. An agent checkout fails for different reasons: a tool contract that is ambiguous, or catalog data the agent read that was stale. You debug one with session replay. You debug the other with request logs.

If a person needs to approve the purchase, the commerce-agents pattern of staging the cart and handing off to a human checkout is your pattern. If the agent has authority to complete the purchase, the flowers MCP pattern of a flat, accountless, single-call API is yours. Most businesses will need both, because most agent-mediated purchases will sit somewhere between full autonomy and full human approval.