AI agents in retail: follow the broken order

The order says shipped. The carrier has stopped updating. Your customer still expects one answer.

That gap is where retail work actually happens. Not in the storefront chat window, but in the messy space between a delivery promise, a stock count, a returns rule, and the person who has to make it right. A shopper doesn’t care which system holds the truth. They care whether the next step is correct, and whether they have to tell the story again to get it.

This is a hypothetical walkthrough, built to show how the pieces connect. No real customer, order, or outcome is described here. Follow one delayed order across promise, fulfillment, service, and policy, and the real question sharpens: not what an agent can say, but what it is allowed to do, from which source, with whom accountable.

TL;DR

• Retail agents need current order, stock, and policy information before recommending the next step, and each step needs an accountable owner.
• A clean handoff should preserve the customer’s question, the supporting evidence, the status of any action, and who owns what comes next.
• Commerce protocols describe how systems and agents interact. They do not prove a retailer’s operational readiness, and they do not imply support by any one platform.

What are AI agents in retail?

AI agents in retail are software systems that use business information and connected tools to assist with shopping, service, and operational tasks. Depending on their permissions, they can retrieve order details, recommend a next step, carry out a bounded action, or route an exception to the responsible person. Authority is configured, not assumed, and it varies by task.

Shopping assistance, order management, inventory checks, returns, and staff support all belong in the retail-agent conversation. The exception appears when those systems disagree. A catalog says stock is available, but the order has no reserved item. That disagreement changes what the agent can responsibly promise – and who must decide the next step.

The journey spans distinct scopes, not a maturity ladder.

Assisted service explains recorded evidence and hands off.

Connected operations coordinates ownership across teams.

Governed commerce permits a bounded action under the retailer’s chosen controls.

A retailer can stay at assisted service for one job and use a broader scope for another.

The promise survives longer than the stock count

Reconstruct the promise before you resolve the complaint. A shopper saw an offer, chose a SKU, accepted a delivery estimate, and completed checkout at a specific timestamp. Each of those is a separate record.

A catalog only shows availability; it never reserves the item. And an order confirmation is not a fulfillment confirmation. The delivery estimate was true against the information the system held at purchase time, which may no longer hold now.

This is where freshness stops being an abstraction. A retrieval can be technically current and still surface an old carrier event, because the carrier stopped scanning the parcel days ago.

The record is fresh. The world it describes is stale.

An agent that reads the last event as gospel will tell the customer something confident and wrong.

For the context layer that keeps these records connected and current enough to reason over, see our take on AI knowledge management. The point isn’t more data. It’s trustworthy, current, permission-aware context, so a next step rests on what is actually true rather than on the most recent row in a single table.

So the first honest scope here is assisted service. Explaining the recorded promise, with the age of each source visible, is often the right and sufficient action. Freshness tolerances are not universal. A retailer decides how old a carrier event can be before the agent treats it as unreliable, and which source wins when the catalog offer and the captured checkout terms disagree.

An order record is not a fulfillment confirmation

Treat the order record and the fulfillment state as two different questions with two different owners. The order record answers what the customer bought and was promised. The fulfillment state answers where the parcel is now and whether anyone can still influence it. Blurring them is how a customer hears “it shipped” while the box sits unscanned in a depot.

Where should AI agents in retail hand off the work?

Follow the break as it moves: tracking stalls, so service picks up the thread. The replacement the customer wants depends on stock that has no confirmed reservation against it. Then the customer asks the question that changes everything: if it arrives late, can they still return it? Now a fulfillment problem has become a policy decision, and the owner changes again.

A good handoff carries the story so the customer never repeats it. Transfer the identity checks already done, the prior messages, the evidence gathered, any pending writes, and the open questions. This is connected operations: coordinated ownership, not unrestricted execution. Missing evidence should change the route, not the promised date. If the agent can’t confirm a reservation, it says so and asks the inventory owner, rather than inventing availability to sound helpful.

Before choosing how to implement this work, define the sources, approvals, and owners the workflow requires. Our build-versus-buy decision framework can help with that choice once its live destination is confirmed. A delayed order is also a service-continuity problem, so plan the wider customer experience around the handoff.

From a delayed parcel to a stock mismatch

The replacement path exposes the mismatch. A location shows stock, but nothing is reserved against this order, and two systems report different counts. The agent doesn’t promise a replacement. It identifies the SKU and location, compares timestamps and reservation status, and requests confirmation from the inventory owner before anyone commits.

The policy decision changes the recovery

Return eligibility is not a shipping question. Distinguish a pre-delivery cancellation from a post-delivery return, because the rules and the anchor dates differ. Late arrival may or may not change eligibility depending on the effective policy version, item exclusions, and the recorded delivery date. The agent explains what the terms say, or proposes a review when the delivery anchor is missing. It doesn’t improvise a refund.

The handoff map

Here is the load-bearing part of the page. Each row is one job in the journey. Read it as a working map, not a rulebook. The action limits below are proposed retailer policy, illustrative examples rather than universal requirements, and every retailer should set its own.

In short: every next step needs a current source, a named owner, and an explicit boundary. Strip any one of those and the agent is guessing on the customer’s behalf.

Keep these actions separate: recommend, authorize, and complete. An agent can recommend a replacement, but authorization to reserve stock and completion of the write are distinct steps with their own controls. Consent doesn’t create stock. And before any retry, check whether the write already completed, then preserve the result in the customer thread so nobody duplicates it.

Agentic checkout meets the merchant’s operating reality

Agentic checkout sits on the purchase side of this same journey. It can help an agent and merchant exchange purchase information, but it cannot settle a later stock dispute on its own. The two protocol announcements below establish design scope, not proof that a retailer’s post-purchase systems can resolve our delayed order.

Stripe’s Agentic Commerce Protocol announcement, dated September 29, 2025, describes an open standard co-developed with OpenAI. The purchaser grants permission, confirms the purchase, and the merchant receives a checkout request it can accept or decline. The merchant retains control of its products and fulfillment. Stripe also describes compatibility with other payment providers. These are launch-time design claims, not a September 2026 merchant-adoption count.

Google’s Universal Commerce Protocol technical introduction, dated January 11, 2026, describes a standard spanning discovery, purchase, and order management. It discusses APIs, agent-to-agent communication, merchant controls, and evidence of customer consent.

Its sample uses a mock payment handler, so it’s a technical demonstration rather than proof of a completed merchant rollout. Neither protocol supplies a current stock count, a confirmed reservation, or the owner of a disputed return.

What do ACP and UCP actually establish?

They establish ways for agents, merchants, and payment systems to interact. They don’t establish universal adoption or support by every software provider. A retailer still needs to verify its own implementation, consent design, and fulfillment responsibilities. Our broken-order test remains unchanged: which record is current, which action is authorized, and who owns recovery if a purchase goes wrong?

Close the exception, not just the conversation

A support thread can end while the exception stays open. The customer gets a polite reply, the chat closes, and the parcel is still missing, the replacement still unreserved, the refund still undecided. Closing the conversation is not the same as closing the exception, and only one of those is the actual outcome.

So measure the exception, honestly and narrowly. Baseline repeat contacts on the same order, time to confirmed resolution, and incorrect commitments against a defined period. Define the denominator, the observation window, and the exclusions before you start. Don’t promise an improvement in advance. The measurement earns the trust; the forecast does not.

Reconciliation deserves its own discipline. If the stock reservation succeeds but the customer notification fails, the customer is worse off than before, and stopping the agent doesn’t reverse the reservation. Assign both the repair and the customer communication to a named owner. A half-completed action with no owner is how automation quietly erodes trust.

Give one bounded task an owner

For a bounded pilot, Computer, by DevRev is a candidate to evaluate for connected context and governed actions across supported systems. Computer would need to prove that the specific sources in this retail journey can be connected and kept current. The team could then use Agent Studio to define an approved handoff or action within its actual integration scope. None of that is established by this illustrative order.

Keep the scope honest. This walkthrough makes no claim of Computer support for retail checkout, point-of-sale, payments, inventory sync, ACP, or UCP. The test is narrower: can the chosen implementation show the source and age of each relevant fact, take only the approved next step, and preserve a clear owner when it can’t proceed?

Choose the exception your team already owns, then make its next step easier to trust. Name its accountable owner and one measurable outcome, and you have a starting point that survives contact with a real broken order.