What does agentic commerce infrastructure mean for delivery?

When an AI agent shops for someone, it doesn't scroll through a checkout page like a person does. It asks each retailer for delivery options as data, compares the answers and then decides where to send the order.

The industry has spent the past year agreeing on how that conversation works. The Agentic Commerce Protocol (ACP) from OpenAI and Stripe and Universal Commerce Protocol (UCP) from Google and Shopify define how an agent opens a checkout, picks options and pays. Both leave a slot for delivery. The retailer fills it, using whatever delivery setup it already runs.

That makes delivery the layer most retailers haven't prepared yet. Agentic commerce infrastructure for delivery is the setup that lets an AI agent request a retailer's delivery options and promised dates as structured data, built from the same logic the retailer shows human shoppers. This article explains what that setup looks like and where mid-market and enterprise teams can start.

Why does delivery break when an agent does the buying?

In many setups, the delivery information only exists once a page loads: a checkout plugin or widget collects options from carriers and applies the retailer's rules. Shoppers see the result that appears on screen as a clear list, while an agent that never renders the page gets far less to work with.

Delivery in Agentic Commerce: 2027-2030 covers why machine-readable delivery offer becomes a deciding factor once agents compare retailers. This explainer goes one level down, into the delivery setup itself.

What does API-first delivery mean?

API-first means the delivery logic lives behind an application programming interface (API), separate from any screen that displays it. The API holds the decisions: which options a shopper can get, what each one costs, which date can be promised, which pickup points are nearby and whether an address is valid.

The checkout page becomes one way of showing those answers. The documented, versioned description of what a system can ask the API and what it gets back is called the API contract, and it stays stable as the API grows.

Keeping these decisions in the API, apart from the checkout page, makes delivery readable for AI agents, not only people. Shoppers see the answers on the checkout page, but agents skip the page and ask the API for the same answers, so both get one version of the truth.

McKinsey and EuroCommerce make a similar point for commerce in general in Rewiring retail in Europe: becoming agent-ready means building well-documented APIs that agents can use securely.

API-first doesn't hand control to a vendor. In Ingrid's model, the retailer's own backend opens each delivery session and keeps ownership of the cart and the order. The shopper's browser only carries a reference to that session, so sensitive data stays in the retailer's systems.

If the API is the contract, who builds what shoppers see?

An API returns data, and a shopper can't choose a delivery option from raw data. Someone still has to turn it into a shopper-facing interface that works on every screen and in every market. Delivery has a longer checklist than many teams would expect:

• a list of delivery options that works while the options load, when none are available and/or when the shopper changes the address;
• pickup point search with a map, distances and opening hours;
• an address form for each country, with its own layout and validation rules;
• copy, dates and currency formats for every language the retailer sells in;
• accessibility for keyboard and screen-reader users, in light and dark mode.

Teams with strong frontend capacity often choose to build all of this themselves. For others, it competes with every other item on the roadmap, and it needs updating each time the API adds something new.

How can retailers connect to an API-first delivery setup?

Retailers can build an API-first delivery setup in-house or use a delivery system that provides the API. One of them is the Agentic DeliveryOS by Ingrid: it decides which delivery options each shopper sees and what's promised for each order, and it makes those decisions available through APIs. DeliveryOS offers two ways to connect, and both read from the same APIs. The difference is who builds and maintains what the shopper sees.

Experience Kit is the user interface (UI) path. It gives retailers a software development kit (SDK) and ready-made building blocks for steps such as delivery and address entry, which render natively inside the retailer's own pages. The retailer applies its own brand styling and language and can change both without rebuilding the experience, while Ingrid keeps the components in step with the APIs.

The headless path suits teams that want full control over the interface. They build their own frontend directly on Ingrid's product APIs, such as Promise for checkout and Engage for tracking.

In both cases, the delivery logic sits in one API contract, so the foundation an AI agent reads is the same. Many retailers still run delivery on an earlier generation of packaged widgets, where logic and display are tied together. For them, moving onto the API model is the first step, and the interface choice can come later.

What now for mid-market and enterprise retailers?

How far a retailer has to go depends less on its size than on where its delivery logic lives today. Two patterns come up often, and a planned e-commerce replatform presents an opportunity to act on either one, because the delivery setup is being rebuilt anyway.

Mid-market retailers

Many growing direct-to-consumer (D2C) brands run delivery through a delivery app or plugin installed on their e-commerce platform, with a few carriers connected. The delivery rules, options and prices are set inside that plugin or in the platform's shipping settings. One or two people own e-commerce, and an agency often makes the changes. The delivery promise exists only as a rendered checkout UI, so an agent sees little of it.

First moves worth considering:

1. Map where each part of the delivery offer is decided today. Promised dates are a good place to start. They often come from carrier service levels, which describe a carrier's typical transit time rather than this specific order, so an agent comparing retailers can't rely on them.
2. Prioritize the move onto an API model over a checkout redesign, since the API is what agents read.
3. Use ready-made interface components instead of building them, so a small team can open new markets without new development work.

Enterprise retailers

Larger omnichannel retailers often run composable or headless stacks, with in-house tech teams and operations across several markets and brands. Delivery logic is often behind APIs already, yet it tends to be spread across market-specific setups and older integrations. An AI agent asking two markets the same question can get two different answers.

First moves worth considering:

1. Run delivery decisions for every market through one API contract. Storefronts, apps and agents then get answers in the same format, built from one set of rules, whichever market they ask about.
2. Choose the interface path per storefront. A flagship storefront with its own frontend team may justify a fully custom, headless build, while smaller brands or newer markets can use Experience Kit components. Because both paths read from the same APIs and the same delivery rules, the retailer doesn't end up running two delivery setups.
3. Plan for AI agents as one more reader of that contract, next to storefronts and apps.

Both patterns share what Delivery in Agentic Commerce: 2027-2030 calls the static era: a checkout that shows every shopper the same options, with no memory of what they chose before. The report describes where retailers stand today and what separates the static era from agentic-ready delivery.

What comes next

Checkout protocols such as ACP cover the moment where an AI agent has picked a product, opens a checkout and the retailer returns its delivery options. The agent, however, also needs delivery information before that moment, as it compares retailers, and after it, when shoppers ask where a parcel is or how to send it back.

The Model Context Protocol (MCP) is an open standard that lets AI agents connect to business systems and request data from them directly. It's becoming a common way for agents to reach tools outside checkout, so delivery data is likely to be requested this way too, at more steps of the journey. A delivery setup built on one API contract is well placed for that shift, because each new protocol becomes one more way to read the same answers.

See where your delivery setup stands on the path to agentic-ready: Delivery in Agentic Commerce: 2027-2030 →