What Happens When an Item Your AI Agent Ordered Is Out of Stock?
June 16, 2026 ยท Victor Young
An item going out of stock is the most ordinary failure in commerce, and it is also the failure that most clearly separates agent setups that work from agent setups that look like they work. When a human hits a stock-out, they sigh and pick something else. When an agent hits one, what happens next depends entirely on whether the failure arrives as structured data the agent can act on, or as a rendered error page it cannot.
The short answer for purchases on an execution layer: the agent finds out immediately through a typed error or a seller decline, your money never settles because payment is held in escrow until delivery, and the agent can re-source alternatives and propose them to you for approval. Nothing is silently substituted, and nothing needs a refund chase. The longer answer is worth walking through, because stock-outs can happen at four different moments, and each one plays out differently.
Moment 1: Out of Stock at Search Time
The cheapest stock-out is the one that never becomes an order. In structured listings, inventory is a typed field alongside price and shipping, so an agent searching Firestarter filters out unavailable options before they are ever proposed. A listing with zero inventory simply does not make the comparison set.
Contrast this with an agent reading web pages, where "In Stock" is a string on a page that may have been cached an hour ago. Browser agents routinely propose items that were available when the page rendered and gone by the time the order submits. Structured inventory does not eliminate that race entirely, but it shrinks it from hours to moments.
Moment 2: Out of Stock Between Proposal and Approval
You approve purchases asynchronously. The agent proposed a charger at 2 PM; you approved from your phone at 4 PM. What if the last unit sold at 3?
On Firestarter the order is confirmed with the seller as part of execution, after your approval. If inventory ran out in the gap, the execution fails with a typed error rather than completing against a phantom listing, and because payment is authorized but not captured until delivery confirmation, the failed execution releases its authorization. No charge lands, and no refund process starts, because no money was ever captured. The failure and its reason are recorded in the audit trail, so there is no ambiguity later about what happened.
This is the quiet advantage of escrowed settlement: a stock-out after approval is an annoyance rather than a financial event. The escrow model was designed around exactly this kind of partial failure.
Moment 3: The Seller Declines or Counter-Offers
Sellers on a two-sided network run agents too. When an order reaches a seller whose stock just ran out, the seller side can decline the order or, more usefully, respond with an equivalent: "Item A is out of stock; Item B is equivalent and in stock at the same price." This agent-to-agent exchange happens in structured messages, not email threads.
Here is the rule that keeps counter-offers safe: a substitute is a new proposal, not a continuation of the old approval. Your approval authorized one specific item at one specific total. An equivalent item, even a genuinely equivalent one, is a different purchase, so it comes back to you as a fresh approval request showing exactly what changed. Your agent never silently accepts a substitution on your behalf. Approval-first execution means nothing executes without a yes, and that includes the second attempt.
If you have ever received a grocery delivery where the shopper swapped your specific brand for "something similar," you know why this rule exists. Substitution judgment is exactly the kind of judgment agents are worst at, so the architecture routes it back to the human every time.
Moment 4: Re-Sourcing After a Failure
After a stock-out kills an option, the agent's job is to re-source: run the search again, excluding the failed listing, and propose the next best option. Because the failure arrived as a typed error with a recovery path rather than a dead browser session, the agent can do this programmatically and immediately. The new option arrives as a new approval request with its own all-in total, ranked by whatever dimension matters: cheapest total for routine restocks, arrival certainty for deadline buys.
Deadline purchases get an extra layer. For an order that must arrive by a hard cutoff, Firestarter tracks the order against the deadline with delivery-at-risk alerts and automatic fallback sourcing, so a stock-out or carrier slip triggers re-sourcing while there is still time to act. The emergency sourcing scenario walks through that flow step by step.
One cost note: cancelled and failed executions do not consume additional tokens, and search is free, so re-sourcing after a stock-out costs nothing beyond the normal approval of the replacement purchase. The economics are on the pricing page.
Why the Silent Version Is So Much Worse
Everything above assumes failures arrive as data. The alternative is what happens to browser-automation agents: the agent submits a checkout form, sees a confirmation page, reports success, and moves on. If the order later dies on the seller side, payment declined, item went out of stock, order cancelled, nobody is watching. The confirmation page was true for ten seconds and never checked again, a failure mode covered in depth in how agents prove purchases happened.
The stock-out itself is identical in both worlds. The difference is whether your system finds out. Typed errors, escrowed payment, and delivery-confirmed settlement turn "the item was out of stock" from a surprise on your credit card statement into a structured event your agent already handled.
The Bottom Line
Out-of-stock is not an edge case; it is a permanent feature of buying things. The question to ask of any agent setup is not "can it avoid stock-outs" but "what happens when one hits": does the agent learn about it immediately or never, does the money come back automatically or after a dispute, and does the substitute get your approval or get silently bought? On an execution layer the answers are immediately, automatically, and always. The docs cover typed error handling and re-sourcing flows end to end.
FAQ
Will my agent buy a substitute without asking me?
No. A substitute item is a new purchase proposal, and approval-first execution means every proposal needs an explicit yes before money moves. Even when a seller counter-offers a genuinely equivalent item at the same price, your agent presents it to you as a fresh approval request showing exactly what changed.
Do I get charged when an order fails for stock?
No. Payment is authorized at execution but captured only on delivery confirmation, so a stock-out failure releases the authorization rather than triggering a refund. No charge settles, and there is no dispute process to run, because the money never moved.
What if the purchase has a hard deadline?
Deadline executions are tracked against the cutoff with delivery-at-risk alerts and automatic fallback sourcing. If stock runs out or a carrier slips, the agent re-sources while there is still time to hit the deadline, and the replacement option comes to you for approval like any other purchase.
How do sellers handle backorders on the network?
The seller side can decline the order outright or respond with a structured counter-offer naming an equivalent item, its price, and availability. Either way the response is machine-readable, so your agent can act on it immediately: accept the counter-offer into a new approval request for you, or re-source from other sellers. Sellers who keep inventory fields current get fewer failed orders and more completed sales; that incentive is covered in the seller guide.