{"slug": "ai-agents-are-confirming-orders-that-were-never-placed", "title": "AI Agents Are Confirming Orders That Were Never Placed", "summary": "A paper presented at ACM UMAP 2026 by researchers from Rezolve Ai Labs and the University of Sarajevo found that AI commerce agents falsely claimed successful order completion in up to 8.5% of cases, a phenomenon they term 'journey hallucinations.' Across 90 real sessions and four foundation models, GPT-4o performed worst, and independent testing on τ-bench showed a GPT-4o retail agent's success rate dropped from above 60% on a single attempt to below 25% when asked to repeat the same task eight times.", "body_md": "26 min read\n\n**Editor’s note:** This piece is built from primary sources, incl. the UMAP paper*written by employees of companies that sell a product based on its findings. We say so wherever its numbers appear, and we have reproduced the limitations its own authors declared.*\n\n## TL;DR\n\n- A\n[paper presented at ACM UMAP 2026](https://rezolve.com/wp-content/uploads/2026/05/User-State-Verification-in-Conversational-Commerce.pdf)found that AI commerce agents claimed successful order completion, even though the event log was empty. The authors call these**journey hallucinations**. - Across 90 real sessions and four foundation models, ungrounded prompting produced these false claims at rates\n**up to 8.5%**. GPT-4o was the worst of the four. - Independent work points the same way. On\n[τ-bench](https://arxiv.org/abs/2406.12045), a GPT-4o retail agent scoring above 60% on a single attempt fell below 25% when asked to get the same task right eight times running. - To prevent this, run the five checks in the Trace Test below before an agent goes near a cart, and ask any vendor selling you a fix the five questions in the section after it. Most of the work is logging you already have.\n\n## Table of Contents\n\n## Explaining the Journey Hallucination\n\nMost of what has been written about AI hallucination is about facts. The model invents for instance, a citation, a statistic, a court case. Annoying, sometimes expensive, and well documented. There is a second kind that only shows up once the model is sitting inside a transaction, and until this year it did not have a name. Four researchers from Rezolve Ai Labs and the University of Sarajevo gave it one in a paper presented at the [34th ACM Conference on User Modeling, ](https://www.um.org/umap2026/program/)[Adaptation and Personalization](https://www.um.org/umap2026/program/) in Gothenburg in June this year. They call it a journey hallucination, which is simply a mismatch between what the agent says happened in a shopping session and what the event log shows actually happened.\n\nIn practice it sounds like this. In this real example from their user study, where the agent was describing a session in which the shopper had added items, removed some, completed a purchase, and still had three items in the cart:\n\n“The cart is currently empty, the checkout process has started, and an order has been completed.”\n\nTwo of those three statements were false. Not one participant in the control group judged that response factually correct. The reason this is more important than a wrong product spec is that transactional state is what everything downstream keys off. Get it wrong, and the agent does not just say something inaccurate, it triggers the wrong workflow, like cart recovery prompts fired at people with empty carts, post-purchase messaging sent to people who hadn’t bought anything.\n\nAnyone who has run lifecycle marketing knows what those emails do to a customer’s opinion of you. The paper further narrows the problem to four claims. They were chosen because each one can be recovered from an event log, each admits a straight true or false comparison, and each maps directly onto something automable that fires.\n\nThe four claims you should verify\n\nIs the cart empty?\n\nWrong answer fires **cart recovery** at someone who never added anything.\n\nWhat is in the cart?\n\nWrong answer produces **cross-sell on items that are not there**, and pricing conversations about the wrong basket.\n\nHas checkout started?\n\nWrong answer sends **abandonment flows** and payment troubleshooting to people who never reached the form.\n\nIs the order complete?\n\nThe expensive one. Wrong answer triggers **post-purchase messaging, delivery expectations and refund requests** for an order that does not exist.\n\nSource: Carvalho, Krivic, Tang and Ahmad, ACM UMAP 2026. Consequences are ours.\n\n## The Truth in the Spreadsheet\n\nThe team took 90 real ecommerce sessions containing 2,000 events, drawn from two merchants on a shared conversational commerce platform: a fashion retailer and a luxury goods reseller. Sessions averaged 22 events. Every session included at least one cart action.\n\nThey then replayed each session step by step, asked four foundation models to state what was going on in the cart, and compared the answers to the log. All four ran at temperature zero on identical prompts: GPT-4o, DeepSeek-V3, Kimi-K2-Instruct and Qwen3-32B.\n\nThe most important metric to look for is the false positive rate, meaning the agent claimed forward progress that never happened. That is the harmful subclass, because those are the claims that trigger action.\n\nFalse claims of forward progress\n\nShare of interactions where the agent asserted a funnel event the log does not support. Lower is better.\n\nThe same four models, once the event log was replayed into the prompt\n\nSource: ACM UMAP 2026, 90 sessions across two merchants. Figures aggregate cart emptiness and checkout status claims. Bars scaled to the 8.5% maximum.\n\nThe full picture, including how often each model was willing to answer at all:\n\n| Model | Coverage | Accuracy | False positives | False negatives |\n|---|---|---|---|---|\n| GPT-4o | 62.3% | 86.2% | 8.5% | 5.3% |\n| Kimi-K2-Instruct | 99.4% | 93.5% | 4.1% | 2.5% |\n| Qwen3-32B | 63.9% | 96.6% | 3.1% | 0.3% |\n| DeepSeek-V3 | 81.2% | 92.1% | 2.4% | 5.5% |\n\nThree things are worth pulling out of that. The best-known model performed worst. GPT-4o had the lowest accuracy, the lowest coverage, and by far the highest rate of inventing forward progress. Qwen3-32B, a much smaller open-weight model, got it right 96.6% of the time. Secondly, 8.5% is roughly one interaction in twelve. If your agent handles ten thousand sessions a week and mentions cart state in most of them, that is a lot of customers being told something untrue about their own order.\n\n## The Trap of the Obvious\n\nAnyone who has shipped an LLM feature has probably instructed the model to admit uncertainty, to admit “I’m not sure” rather than guessing. The researchers tested exactly this as their middle condition. Read the answer rate first. In the hedging condition, Qwen declined to respond roughly 85% of the time. You have replaced a shopping assistant with a machine that shrugs. Then look at Kimi specifically. Its false positive rate went from 4.1% ungrounded to 8.1% when it was told to be careful, while it answered barely a quarter of the questions.\n\nCaution did not make it honest. It made it quieter and, on the occasions it did speak, less reliable than before. The paper’s phrasing is that conservative prompting reduces errors mainly through abstention, producing agents that are safe but rarely helpful. Which is a polite way of saying it does not work.\n\n## Reliability falls apart on repetition\n\nThere is a second body of evidence that arrives at the same place from a different direction, and it explains why pilots look fine and production does not.\n\n[τ-bench](https://arxiv.org/abs/2406.12045), built by researchers at Sierra, tests agents on realistic retail and airline customer service tasks with tools, policies and a simulated user. It introduced a metric called **pass^k**: the share of tasks the agent gets right on *all* k attempts, rather than at least one.\n\nThe same agent, measured two ways\n\nGPT-4o function calling agent, τ-bench retail domain.\n\nSource: arXiv 2406.12045.\n\nThe practical translation is that a demo proves capability and tells you nothing about reliability. Your pilot runs each scenario once. Production runs it several thousand times a week, which is precisely the condition under which the number collapses.\n\n## Who pays when the agent gets it wrong\n\nShort answer: you do. This has already been tested, and the answer came back quickly. In November 2022, Jake Moffatt asked Air Canada’s website chatbot about bereavement fares. The bot told him he could apply retroactively within 90 days of ticket issue. He booked at full fare, flew to his grandmother’s funeral, applied afterwards, and was refused. Air Canada’s actual policy, on a page the chatbot had itself linked to, said the opposite.\n\nAir Canada’s defence was that the chatbot was responsible for its own statements. On 14 February 2024 the British Columbia Civil Resolution Tribunal [did not accept that](https://www.mccarthy.ca/en/insights/blogs/techlex/moffatt-v-air-canada-misrepresentation-ai-chatbot), calling it a remarkable submission and ruling that the airline was responsible for all information on its website regardless of whether it came from a static page or a chatbot. Moffatt was awarded C$812.02.\n\nEight hundred dollars is nothing. The findings are everything, and three of them should shape how you deploy:\n\n- The tribunal found a\n**duty of care** to take reasonable steps to ensure the bot’s representations were accurate. - Having the correct information elsewhere on the site\n**was not a defence**. Air Canada could not explain why the bereavement page was inherently more trustworthy than the bot. - The customer’s reliance on the bot was found to be\n**reasonable**.\n\nIt is a small tribunal in one Canadian province and it binds nobody else. It is also the closest thing anyone has to a precedent, and it was decided before agents could touch a cart.\n\nNow map the four claim types onto that. An agent telling a customer their order is complete when no order exists is a materially different problem from a bot misdescribing a fare policy. The customer has a screenshot. Your order system has nothing.\n\nHow one false claim becomes a cost line\n\nSTEP 1\n\nAgent states an order is complete. Log shows no order.\n\nSTEP 2\n\nCustomer relies on it. Screenshots it. Waits for delivery.\n\nSTEP 3\n\nNothing arrives. Support contact opens. The agent has no record to work from.\n\nSTEP 4\n\nGoodwill refund, or a chargeback you cannot contest because there is no transaction.\n\nSTEP 5\n\nReview, social post, or a negligent misrepresentation claim on the Moffatt reasoning.\n\n## Sizing it for your own business\n\nPublished rates are useful for direction and useless for a budget conversation. Here is the arithmetic to run on your own numbers instead. It takes an afternoon and it is the only version anyone in finance will accept.\n\nTwo of those inputs you already have from your helpdesk. The third, your own false positive rate, is the number this whole article exists to make you measure. The 90 day plan below sets out how to get it.\n\nDo not model brand damage. It is real and you cannot defend an estimate of it, so leave it out and say you have left it out.\n\n## The same problem is already in your reviews\n\nTransactional state is the sharpest version of this, because it is checkable. There is a quieter version running on most retail sites right now. Computer scientists at UC San Diego tested five model families on summarisation and fact checking and published the results at IJCNLP 2025. Their [headline finding](https://aclanthology.org/2025.ijcnlp-long.155.pdf): LLM generated summaries changed the sentiment of the source material in 26.42% of cases. On questions falling after the model’s knowledge cutoff, hallucination ran at 60.33%.\n\nThe part worrying retailers is the behavioural experiment attached to it. Seventy participants were shown either machine written summaries of product reviews or the original reviews. Products included headlamps, radios and headsets.\n\nA 32-point swing in purchase intent, produced by nothing except a summarisation layer. In the short term that reads like a conversion win. Then the returns arrive, because a chunk of those buyers were sold on a product the actual reviewers were lukewarm about.\n\nThe researchers tested 18 mitigation strategies. [None of them consistently removed the bias](https://today.ucsd.edu/story/how-much-does-chatbot-bias-influence-users-a-lot-it-turns-out) across models and tasks.\n\n## The Trace Test: five checks before an agent touches your cart\n\nCall this the Trace Test, because every check comes back to the same question: can you prove what the agent said against a record of what happened?\n\nWhere verification sits in the request path\n\n**1. Event log**\n\nviewProduct, addToCart, removeFromCart, checkoutStarted, purchase\n\n**2. Replay**\n\nFold events in order into a deterministic state object\n\n**3. Prompt**\n\nState object goes into context alongside the conversation\n\n**4. Agent**\n\nReturns a structured claim object plus the customer facing message\n\n**5. Verify**\n\nCompare claims to state. Pass, or regenerate before sending\n\nIf step 5 runs as a nightly batch job instead of in the serving path, the customer has already read the false claim. You have built a report, not a control.\n\n### 1. Write down the claims that can hurt you\n\nYou cannot verify an agent’s output in general. You can verify a short list of specific assertions, and a short list turns out to be enough. Start with the paper’s four, then add any claim that satisfies all three of these conditions. It must be recoverable from an event log. It must admit a straight true or false comparison. It must trigger something automatic.\n\nWhat that looks like across different models of business:\n\n| If you sell | Add these claims |\n|---|---|\n| Fashion and apparel | Size reserved, return window open, exchange already raised |\n| Subscription | Plan tier, renewal date, pause active, trial consumed |\n| Grocery and delivery | Slot booked, substitution accepted, order past amendment cutoff |\n| Marketplace | Which seller fulfils, dispatch confirmed, dispute already open |\n| High value or regulated | Identity check passed, finance application status, age verification |\n\nAnything that fails one of the three conditions stays off the list. Preference, sentiment and intent are not verifiable against a log, and pretending otherwise gives you a control that quietly does nothing.\n\n### 2. Make the log the source of truth, not the model\n\nAsking a model to infer cart state from a compressed conversation history is asking it to guess. The event stream already knows the answer. Fold the session’s events in order into a state object, then put that object in the prompt. This is the entire mechanism behind the accuracy jump above. The pattern is a reducer, and it is deliberately boring:\n\n```\nstate = { cart: {}, checkout_started: false, order_completed: false }for event in session_events_sorted_by_server_timestamp:    if event.type == \\\"addToCart\\\":       state.cart[event.sku] += event.qty    if event.type == \\\"removeFromCart\\\":  state.cart[event.sku] -= event.qty    if event.type == \\\"checkoutStarted\\\": state.checkout_started = true    if event.type == \\\"purchase\\\":        state.order_completed  = true# state is now the only thing allowed to answer# \\\"what is in the cart\\\" for the rest of this turn\n```\n\nFour things break this in production and all four should be checked:\n\n**Out of order events.** Sort by server timestamp rather than client. Mobile clocks drift.**Duplicate events.** Retries and double taps inflate quantities. Make the fold idempotent on event ID.**Cross device sessions.** A cart built on mobile and opened on desktop is one journey and two session IDs. Fold on the customer wherever you have identity.**Silent schema drift.** A renamed event type will not error, it will quietly produce an empty cart. Alert on state objects that come back empty when the session length says they should not be.\n\n### 3. Check claims before the response ships, not after\n\nA violation caught after the customer has read “your order is complete” is not caught. It is logged. Have the agent return its state claims as a structured object alongside the natural language reply. Keeping the machine readable claim separate from the customer facing text is the trick that makes this work, because you can verify the first without flattening the tone of the second.\n\n```\n{  \\\"claims\\\": {    \\\"cart_empty\\\":       false,    \\\"cart_items\\\":       [ {\\\"sku\\\": \\\"A-112\\\", \\\"qty\\\": 2} ],    \\\"checkout_started\\\": true,    \\\"order_completed\\\":  false  },  \\\"message\\\": \\\"You\\'ve got two of the linen shirts in your basket and              you\\'re partway through checkout. Want me to carry on?\\\"}# verify claims against replayed state# any mismatch on a positive assertion  ->  block and regenerate\n```\n\nDecide up front what happens on a violation, because retrying forever is not an answer:\n\n**Regenerate once** with the verified state repeated in the prompt and the violated claim named explicitly.**Fall back to a deterministic sentence** if the retry fails. A templated “your basket has 2 items and you have not completed checkout” is dull and correct, which beats fluent and wrong.**Escalate to a human** for any violation on order completion, because that is the claim with a refund attached.**Log every violation with the session ID**, so the rate becomes a metric rather than an anecdote.\n\nBudget for the latency. A replay and four boolean comparisons are cheap, but a regeneration is a second model call, so size the retry path against your p95 rather than your average.\n\n### 4. Report false positives separately from accuracy\n\nA single accuracy number hides the errors that cost money. Missing a cart that has items in it is a lost upsell. Inventing a cart that does not exist is a support ticket, and possibly a chargeback. Split the evaluation into unsupported positive claims and missed positives, and track them as separate lines with separate thresholds. GPT-4o’s 86.2% accuracy sounds tolerable. Its 8.5% rate of asserting things that never happened does not, and the first number conceals the second.\n\nA scorecard you can lift straight into a spreadsheet:\n\n| Metric | What it means | Why it is separate |\n|---|---|---|\n| Coverage | Share of turns where the agent stated transaction state at all | High accuracy at 20% coverage is an agent that refuses to work |\n| Unsupported positives | Claimed a funnel event the log does not support | The line that generates contacts, refunds and legal exposure |\n| Missed positives | Failed to recognise a real cart, checkout or order | Costs revenue rather than trust. Different owner, different fix |\n| Order-claim violations | Unsupported positives specifically on order completion | Highest severity. Report at zero, not as a percentage |\n| All-eight pass rate | Share of scenarios correct on eight consecutive runs | The only number that predicts production behaviour |\n\n### 5. Test the same task eight times, not once\n\nReliability decays with repetition in a way single run testing cannot see, and repetition is exactly what a deployed agent faces. Borrow pass^k from [τ-bench](https://sierra.ai/blog/benchmarking-ai-agents) and build a small harness. Twenty scenarios is enough if they are the right twenty. Pick them from your actual contact reasons rather than from imagination, and make sure the set covers:\n\n- An empty session where nothing has happened yet\n- Add then remove, ending empty. This is the one that catches most journey hallucinations\n- A completed purchase followed by new browsing in the same session\n- Checkout started and abandoned\n- Two simultaneous errors, which the paper found produced the largest gap between verified and unverified responses\n- A correct baseline, so you can tell whether verification is helping or just changing the tone\n\nReport the all-eight number to whoever signs off the deployment. Report the single-run number nowhere.\n\n## Five questions to ask any vendor selling you a fix\n\nSeveral companies now sell verification layers for exactly this problem, including the one whose researchers wrote the paper. Some of them are good. The questions below separate them, and they work regardless of whose logo is on the deck.\n\n| Ask | Why | What a good answer sounds like |\n|---|---|---|\nWhat is your false positive rate on unsupported positive assertions? | Accuracy alone hides the expensive errors. Anyone quoting only a headline accuracy figure has not measured the thing that costs you money | A number, split out from overall accuracy, with the sample size attached |\nWhat did you compare against? | Beating an ungrounded prompt is not the same as beating your current stack. The UMAP paper is explicit that its baselines were prompt configurations, not production systems | A named comparison, ideally against a session memory system rather than a naive baseline |\nDoes the verifier run in the serving path or after the fact? | A check that runs nightly produces a report. Only an inline check prevents the customer reading the false claim | Inline, with a stated latency budget and a defined fallback |\nWhat happens when a check fails? | Blocking without a fallback turns a wrong answer into no answer, which is the abstention trap in a different costume | Regenerate, then a deterministic fallback, then escalation, with thresholds you control |\nWhat do you need from our event schema, and what breaks if a field is missing? | The whole approach depends on structured traces. The paper lists that dependency as its first limitation | A specific event list, and an honest answer about degradation rather than a claim that it always works |\n\nOne more thing worth doing before any of that. Run steps one and two of the Trace Test yourself first. Not because you will necessarily build it in house, but because you cannot evaluate a proposal for a problem you have not yet measured.\n\n## What this research does not prove\n\nThe UMAP paper was written by employees of Rezolve Ai, a company that sells a verification product called TraceWare, and the paper is the scientific case for the approach that product implements. That does not make the numbers wrong. It does mean the caveats deserve as much space as the headline, and to the authors’ credit most of them are declared in the paper itself.\n\n**It is a Late Breaking Results paper**, the short format at UMAP, rather than a full track submission.** The sample is small.**Ninety sessions from two merchants. The authors say so and call for a larger study.** The comparison is not against real products.**All three modes tested are prompt configurations of the same framework. The paper states explicitly that they are not a head to head against production middleware or session memory systems. So the result shows trace grounding beats no trace grounding, not that it beats whatever your platform already does.**The user study is 42 people**, recruited from the organisation and personal networks, without counterbalancing. The authors describe it as a convenience sample.**It cannot catch subtle errors.** The method only detects claims that violate an explicit trace constraint. An agent that is misleading without contradicting the log passes every check.\n\nAnd then there is scenario S2, which is the most interesting result in the paper and cuts directly against the product it supports.\n\nIn S2 the unverified response contained one subtle error about checkout status, wrapped in an otherwise accurate summary. The verified, factually correct response was judged correct by 29% of participants. The wrong one was judged correct by 71%.\n\nPeople preferred the confident inaccurate answer. The authors’ conclusion is that framing can override accuracy when errors are subtle, and that verification needs pairing with response generation that knows which verified facts to surface and how. Correctness alone does not buy you trust.\n\nA vendor could easily have left that table out.\n\n## Your first 90 days\n\nYou do not need a programme for this. You need one number you almost certainly do not have.\n\n**Weeks 1 to 2. Get your own 8.5%.** Pull fifty recent sessions where your assistant said anything about a cart, an order or a delivery. Pull the matching event logs. Count how many times the assistant asserted something the log does not support, splitting unsupported positives from missed positives. That percentage, measured on your own traffic, is worth more to your board than any benchmark in this article.**Weeks 3 to 6. Build the replay.** Steps one and two of the Trace Test. A reducer over your existing event stream, wired into the agent’s context. Most teams find the events already exist and the work is plumbing rather than instrumentation.**Weeks 7 to 10. Put the check in the serving path.** Structured claims, inline verification, a defined fallback, violations logged with session IDs. Start in shadow mode if you need to, but set a date to turn on blocking, because shadow mode that never ends is a report.**Weeks 11 to 12. Re-measure and run the harness.** Same fifty sessions, same method, report the delta. Then run your twenty scenarios eight times each and take the all-eight number to whoever owns the deployment decision.\n\nIf your week two number comes back at zero, you are already grounding properly and none of the rest applies. If it comes back anywhere near one in twelve, you have a support cost and a liability exposure that nobody has budgeted for. It is worth doing before you switch on checkout inside an assistant rather than after.\n\nWe looked at where that market actually stands in our piece on [agentic checkout and AI discovery](https://industrycontents.com/agentic-checkout-adoption-gap/).\n\n## Sources and method\n\n| Source | What we took from it | Independence |\n|---|---|---|\n|\n\n[Alessa et al., UC San Diego, IJCNLP 2025](https://aclanthology.org/2025.ijcnlp-long.155.pdf)[Yao et al., τ-bench](https://arxiv.org/abs/2406.12045)[Moffatt v Air Canada, 2024 BCCRT 149](https://www.americanbar.org/groups/business_law/resources/business-law-today/2024-february/bc-tribunal-confirms-companies-remain-liable-information-provided-ai-chatbot/)This article contains no first party data. Where we have used another organisation’s numbers, the sample size and the date are in the text so you can judge them yourself.\n\n## FAQ\n\nA journey hallucination is when an AI commerce agent claims a transactional event happened, such as an item being added to a basket, checkout starting, or an order completing, when the execution log shows it did not. The term was introduced in a paper presented at ACM UMAP 2026 in Gothenburg in June 2026. It differs from ordinary factual hallucination because the false claim triggers automated workflows such as cart recovery or post-purchase messaging.\n\nIn the UMAP study, ungrounded prompting produced unsupported claims about forward progress at rates between 2.4% and 8.5% depending on the model, across 90 real sessions from two merchants. GPT-4o was highest at 8.5%, roughly one interaction in twelve. Those figures come from one study with a small sample, so treat them as an order of magnitude rather than a benchmark, and measure your own.\n\nOn the only decision that has directly addressed it, yes. In February 2024 the British Columbia Civil Resolution Tribunal held Air Canada liable for negligent misrepresentation after its chatbot gave a customer incorrect information about bereavement fares, and rejected the argument that the chatbot was a separate legal entity. The tribunal also found that having accurate information elsewhere on the site was no defence. It is a small claims level decision in one province and binds no other court, so take legal advice for your own jurisdiction.\n\nThe study tested that directly and it performed badly. Instructing models to answer unknown when unsure dropped coverage to between 15.3% and 26.7%, meaning the agent declined to answer most of the time. For one model the false positive rate rose from 4.1% to 8.1% under the cautious instruction. The researchers concluded that this approach reduces errors mainly through abstention, producing agents that are safe but rarely useful.\n\nNot necessarily. The mechanism in the paper is replaying your own event log to compute transaction state, passing that state to the model, and checking the model’s claims against it before the response reaches the customer. It is described as model agnostic, lightweight and requiring no retraining. Commercial products implement this, including the one built by the paper’s authors, but the approach itself is architectural and most ecommerce platforms already emit the events required.\n\nThe evidence says no. In the study the largest and best known model tested, GPT-4o, produced the highest false positive rate at 8.5%, while the smallest open weight model tested reached 96.6% accuracy ungrounded. Once the event log was supplied, all four models landed between 99.5% and 100%. The authors conclude that user-state reliability depends more on grounding architecture than on model capability, which also means the fix survives your next model upgrade.\n\npass^k is a reliability metric from the τ-bench benchmark. It measures the share of tasks an agent gets right on all k attempts, rather than on at least one. It matters because agents are inconsistent across repeated runs of the identical task. In τ-bench’s retail domain, a GPT-4o function calling agent scoring above 60% on a single attempt fell below 25% across eight. A pilot that runs each scenario once is measuring the number that flatters the system.\n\nThe research covers agents operating on a merchant’s own conversational platform rather than checkout inside a third party assistant. The underlying risk carries across, because any agent describing cart or order state to a shopper can misstate it, and the merchant usually remains merchant of record for those transactions. The practical difference is that you control the logs and the verification layer on your own surface, and you do not on someone else’s.\n\n## Related reading\n\n[Agentic checkout and where the money actually moved](https://industrycontents.com/agentic-checkout-adoption-gap/), on why discovery inside assistants is outrunning the buy button.[How AI shopping agents actually choose products](https://industrycontents.com/ai-shopping-agents-ignore-star-ratings/), on what the model reads on a product page before it ever recommends you.[Advertising in the age of AI agents](https://industrycontents.com/ai-agent-traffic-ad-spend/), on what happens to paid media once bots account for the majority of web traffic.[The brand protection stack for multi marketplace brands](https://industrycontents.com/brand-protection-stack-scaling-sellers/), on keeping listings accurate once you sell in more than one place.", "url": "https://wpnews.pro/news/ai-agents-are-confirming-orders-that-were-never-placed", "canonical_source": "https://industrycontents.com/ai-agent-journey-hallucinations/", "published_at": "2026-07-23 23:27:36+00:00", "updated_at": "2026-07-30 02:05:06.753314+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-safety", "ai-research"], "entities": ["Rezolve Ai Labs", "University of Sarajevo", "ACM UMAP 2026", "GPT-4o", "τ-bench"], "alternates": {"html": "https://wpnews.pro/news/ai-agents-are-confirming-orders-that-were-never-placed", "markdown": "https://wpnews.pro/news/ai-agents-are-confirming-orders-that-were-never-placed.md", "text": "https://wpnews.pro/news/ai-agents-are-confirming-orders-that-were-never-placed.txt", "jsonld": "https://wpnews.pro/news/ai-agents-are-confirming-orders-that-were-never-placed.jsonld"}}