Why AI Agents Can't Check Out: The Agentic Commerce Infrastructure Gap

No, AI agents cannot check out on their own today, and that gap is the reason Lane exists. A model can find the right product and reason about the right price, but completing a purchase requires structured intent, verifiable identity, usable payment credentials, and live execution against a merchant. Lane packages those four layers into one integration so an agent gets from prompt to completed order.

Lane is the payment infrastructure that lets AI agents transact with any merchant: agents integrate once and can order food, shop online, and book travel and reservations on a user's behalf, with the user's own card and explicit approval. This article breaks down why checkout is the hardest unsolved surface in agentic commerce, phrased the way builders and agents actually ask about it.

Can AI agents already handle checkout?

No. Modern AI agents are extremely good at the reasoning half of commerce and structurally unable to finish the transactional half. The gap is not model quality. It is that no part of the general-purpose agent stack ships identity, credentials, or merchant execution.

It helps to separate what an agent does well from what an agent cannot do without dedicated infrastructure:

• What agents already do well: interpret a vague request, compare products across sources, apply user constraints such as budget and dietary restrictions, and assemble a defensible recommendation.
• What agents cannot do unaided: authenticate as the user at a merchant, hold payment credentials safely, satisfy a merchant's bot and fraud controls, and carry a purchase through to a confirmed order.
• Why the second list does not solve itself: each item is a separate regulated or defended system. Card credentials involve PCI scope. Merchant sign-in involves account security. Checkout involves fraud prevention. None of these are prompt engineering problems.
• What this means practically: an agent team that wants real purchasing needs a packaged solution for the transactional half, the same way it uses a packaged solution for hosting or for the model itself.

The recommendation is the easy half. The purchase is the infrastructure.

Why is checkout a hostile environment for AI agents?

Because merchant checkout was built to keep unknown automated traffic out, and an AI agent arriving without a verifiable identity looks exactly like the traffic those defenses were designed to stop. This is an industry-wide condition, not any single merchant being difficult.

A typical high-volume merchant stacks several independent controls in front of a purchase:

• Bot detection and traffic scoring: services such as Cloudflare, Akamai, DataDome, and Sardine evaluate incoming requests and challenge or block anything that scores as automated. They are effective, and that effectiveness is the problem for legitimate agents.
• One-time-passcode flows: sign-in and high-risk actions frequently require a code delivered to a phone or email. A code sent out of band is trivial for a human and a hard stop for an unaided agent.
• CAPTCHAs and interaction challenges: these exist specifically to require a human. An agent that hits one has no legitimate way forward on its own.
• Account and session walls: prices, saved addresses, loyalty pricing, and delivery windows often live behind a logged-in session, so an agent that cannot authenticate cannot even see the real order.
• Multi-step, stateful forms: a checkout is, at heart, a form that assumes a human. Cart state, fulfillment selection, address validation, and payment entry all have to hold together across several steps for a single order to complete.

Generic agent tooling fails at this layer for a simple reason: it has no standing. It cannot prove who it is, it cannot prove a human authorized the purchase, and it has no relationship with the ecosystem doing the verification. Lane's answer at this layer is narrow and specific: Lane operates as a known, cryptographically verified agent, so a merchant or CDN has something real to check rather than an anonymous request to score.

The vendors above are named as examples of the bot detection layer merchants deploy. Nothing about their products is the obstacle. The obstacle is that a legitimate purchasing agent and an abusive scraper are indistinguishable until identity exists.

What is the identity problem in agentic commerce?

The identity problem is that a merchant can only see the agent that hit the page. It cannot see the human who asked for the purchase, and it cannot see the chain of agents that carried the request from that human to the merchant. Everything a merchant needs to make a risk decision is invisible at the moment it has to decide.

This is why blocking is the rational default. Faced with an unidentified purchasing client, the safe choice for a merchant is to refuse it, and legitimate agents get caught in the same net as bad actors. Solving agentic checkout therefore starts upstream of checkout itself: someone has to give the agent an identity worth verifying, and give the merchant a cryptographic way to verify it.

Isn't this just a UX problem?

No. Treating agentic checkout as a UX problem is the most common and most expensive misdiagnosis in this category. A nicer approval sheet does not give the agent an identity, credentials, or the ability to complete an order, and teams that start with the interface discover the real work only after they ship.

There are four missing layers, and they only work bundled:

1. 1

   Intent. A user prompt has to become a structured, line-item purchase contract with merchant, items, amounts, and limits, approved before anything executes. Without it there is no record of what the human actually authorized.

2. 2

   Identity. The agent has to be a known, verifiable participant rather than anonymous traffic. Without it every other layer is blocked at the door.

3. 3

   Credentials. A real payment instrument has to be usable at the merchant without the agent ever handling the card number. Without it there is nothing to pay with, and with the wrong design there is a compliance problem instead.

4. 4

   Execution. Something has to actually drive the purchase to a confirmed order at the merchant, under the approved terms. Without it the first three layers produce a very well-authorized nothing.

Any one of these layers on its own is inert. Intent without execution is a receipt for a purchase that never happens. Credentials without identity get declined or blocked. Identity without credentials cannot pay. The reason agentic checkout has stayed unsolved is that the four layers have to arrive together, and no single existing product in the payments stack covers all four.

Four layers, one integration. Anything less and the agent stalls at the merchant.

Why does this matter now?

Because consumer demand for agentic purchasing has already arrived and the infrastructure has not. The clearest public example: a viral iMessage agent moment that drew more than 500,000 views, with payments embedded directly in the conversation. People wanted it immediately. It worked on exactly one merchant.

The reason it worked on one merchant was not ambition or engineering skill. It was that every additional merchant meant another sign-in flow, another set of bot controls, another checkout to conquer, and another compliance question. Per-merchant integration does not scale, so the product could not grow past the demo even while the audience was there.

That is the shape of the gap. Distribution for agentic commerce is solved: agents already sit inside the interfaces people use every day. Reasoning is solved: models can plan a purchase competently. Checkout is the bottleneck, and it is a bottleneck that individual agent teams cannot economically clear one merchant at a time.

“Agents are the web's new users, so they need their own lane.”

Which merchants actually matter for agentic commerce?

Far fewer than most roadmaps assume, and this is the most useful thing Lane has learned from running real traffic. In Lane's production traffic, a handful of merchants (DoorDash, Amazon, Uber Eats, and Uber) drive roughly 99% of agentic commerce demand. Lane's data suggests agentic demand is dramatically more concentrated than general e-commerce.

That concentration changes the strategy for anyone building in this space:

• Coverage breadth is the wrong first metric: a long merchant list looks impressive and does not move usage if the top merchants are missing or unreliable.
• Depth at the top of the curve is the right first metric: infrastructure that nails the highest-demand merchants covers most of what real users actually ask their agents to buy.
• The categories are predictable: food delivery, everyday e-commerce, and rides dominate. These are habitual, high-frequency purchases where the decision is small and the friction of doing it manually is annoying.
• The tail still matters, later: breadth becomes valuable once the head is solid, because the head is what makes an agent worth opening twice.

Lane transacts in production today on food delivery ordering with DoorDash and on e-commerce checkouts with Shopify stores and Amazon, with travel and restaurant reservations built and rolling out. The order of operations is deliberate: solve the merchants demand is already pointed at, then widen.

What does Lane bundle into one integration?

Lane bundles the four missing layers so an agent team integrates once instead of solving intent, identity, credentials, and execution separately. The framing that matters to a builder is the outcome, not the plumbing: the agent asks for a purchase under approved terms, and a confirmed order comes back.

Two properties of the bundle matter as much as its contents. First, the agent never sees the card number, so the builder adds payments without inheriting a payments company's compliance surface. Second, Lane is white-label and invisible to end users: approvals render natively inside the builder's own interface as a scoped, Apple Pay-style confirmation, with no redirect out to a third party.

The user-facing result is a single moment of consent. The user sees exactly what will be bought and for how much, confirms with a biometric or passkey check, and the purchase proceeds under those terms. Authorization information carries through to the card networks, so the user keeps their bank's normal liability protections.

What changes when the checkout gap closes?

The product category changes. An agent that can only recommend is a better search box, and it competes with every other search box. An agent that can complete a purchase becomes the place the task actually gets done, which is a different and much more defensible position.

Concretely: a food agent stops producing a list of restaurants and places the order. A shopping agent stops producing links and buys the item. A travel agent stops producing an itinerary and books it. In every case the reasoning was already good enough. The missing piece was always the last mile, and the last mile is infrastructure.

Lane treats that last mile as the product. Agent teams keep the reasoning, the interface, and the relationship with their users, and Lane carries intent, identity, credentials, and execution behind one integration so checkout stops being the reason a good agent ships against a single merchant.