Your next customer is a program, and it will haggle
What actually breaks when software does the shopping, and the architecture that keeps it honest.
AI-referred traffic to US retailers grew 393% year over year in the first quarter of 2026, and those visitors now convert about 42% better than everyone else, according to Adobe Analytics. A year earlier the same traffic converted worse. That flip is the whole story.
People stopped using assistants to browse and started using them to decide. Once the deciding moves, the buying follows.
Which leaves merchants in an odd spot. Your storefront was built for a human with eyes. Your next buyer reads JSON, never sees your hero image, and does not care that you spent four months on the product page.
The plumbing arrived faster than the plumbing usually does
Anthropic shipped MCP in late 2024 and agents got a standard way to reach tools. Stripe and OpenAI followed in September 2025 with the Agentic Commerce Protocol, which put a real checkout inside ChatGPT. Google published AP2 the same month, with signed mandates that record who authorized what. Mastercard announced Agent Pay and Visa extended cards to agent-initiated spend with Intelligent Commerce.
Four layers in eighteen months: tool access, authorization, credentials, checkout. Morgan Stanley models US agentic commerce at $190 billion by 2030 in its base case and $385 billion in the bull case. McKinsey talks in trillions globally. The forecasts disagree by an order of magnitude, which tells you nobody knows, only that the direction is not in dispute.
Every one of those protocols answers "can this agent pay". None of them answers "was that a fair deal".
A signed mandate proves the buyer authorized $1,800. It says nothing about whether $1,800 was the right number, whether the seller would have gone to $1,650, or whether the agent even asked.
Price is the least interesting part of a negotiation
Watch a purchasing manager work and price moves last. They trade warranty length against unit count. They accept a slower shipping tier to get a better rate. They ask for a longer return window because the buyer is nervous, not because the buyer is cheap.
We built the negotiation engine around that. Each side carries a utility function over price, delivery speed, warranty months and return window, with weights it actually holds. A seller with idle inventory weighs volume heavily. A buyer replacing a dead laptop weighs speed. The engine computes the zone where both utilities clear their floor, then works inside it.
When the zone is empty, the agents stop. No deal is a valid outcome and pretending otherwise is how you get agents that agree to bad terms because agreeing feels like success.
Rejection is where it gets interesting. A human declining a settlement is data, not a dead end. The agent takes the stated reason, re-weights, and comes back with a different shape of offer rather than the same offer with $40 shaved off. Shorter warranty, lower price. Same price, free next-day. The retry has to change the geometry or it is just nagging.
The mise en place problem
A line cook does not start chopping when the ticket comes in. Everything is portioned before service because during service there is no time to think. The prep decides how fast the pass moves.
Agent commerce has the same shape. When a buyer's agent asks "who has a 32GB laptop under $1,800 that ships in three days", you cannot go crawl six merchant sites and parse HTML. The catalog has to already be normalized, priced, and stated in terms an agent can compare. Prep is the product.
That is what the adapter layer does. A seller points us at a REST endpoint, a feed, or an MCP server, and we normalize into one shape with explicit units. Availability in days, not "usually ships fast". Warranty in months. Price in cents. The negotiation is quick because the prep was thorough.
The cooks who skip prep are not slower by a little. They are slower by an order of magnitude, and they make mistakes under pressure. Agents skipping normalization do the same thing: they hallucinate a spec because the field was ambiguous.
A model saying "done" is not evidence
This is the failure that cost us the most time. An adapter returns { ok: true }, the model reports the order placed, the user sees a confirmation, and no order exists. The tool succeeded at making an HTTP request. That is not the same as the world changing.
So completion got its own step. Every action names what should be true afterwards, and after execution we read the world back and compare. Order exists. Amount matches. If observation disagrees with the claim, the run is marked falsified and nothing downstream treats it as done.
You can watch this on the runtime page. One scenario runs an adapter that reports success and quietly does nothing. The gate catches it every time because it never asked the adapter whether it worked.
Authority lives in code, not in a prompt. A spending cap in a system prompt is a polite request.
Same principle for permission. The agent proposes; a deterministic function decides. No grant for that capability, denied. Effect not covered by the grant, denied. Amount over the ceiling, denied before any card is touched. Same input, same decision, every run, which means you can test it like any other pure function.
Numbers that make merchants nervous
Consumer trust for fully autonomous checkout sits around 14% in US surveys. That number is often read as "too early". I read it as a product requirement.
The consent pause is not a temporary safety measure we remove once models improve. Above a threshold the buyer sets, the run stops and shows the full settlement: price, terms, what changed since the opening offer, and why the agent accepted. Approving takes one click. Not being asked is what people object to.
On the merchant side the second meeting always goes the same way. Not "how good is your model". It is: what did your agent promise on my behalf, and can you prove the log was not edited afterwards.
Each negotiation turn is hashed together with the hash of the turn before it. Change one row and every later hash stops matching. Neither side has to trust our database, they recompute the chain themselves. It costs a few hundred bytes per turn.
Where verification stops being worth it
Read-back doubles round trips. Hashing adds bytes. If you verify everything you build something correct and unusable, which is its own kind of failure.
We verify anything that spends money, changes a price, or reaches a customer. We sample catalog reads and watch for drift instead of re-reading every one. We verify nothing that is a pure function, because there is no external world to observe and the test suite already covers it.
The rule is simple: verify where being wrong is expensive. Skip where being wrong is cheap and visible.
Debugging a system that decides on its own
A run is a list of canonical events with stable key ordering. That one decision made support tractable. A complaint becomes a replay, and the first bad row tells you which layer failed.
Bad proposal means the model reasoned poorly and the fix is prompt or scoring. Wrong decision means policy is too loose and the fix is a grant. Falsified means the adapter lied and the fix is integration. Three failure classes, three owners, no arguing about which team's problem it is.
Deterministic replay is what makes that work. Same proposal and same authority produce the same decision, so a bug reproduces on the first try instead of the fortieth.
What I am not sure about
Whether the big platforms leave room. OpenAI and Google both want checkout inside their own surface, and they have distribution we will never have. The bet is that the long tail of sellers who will never be a first-party integration is large, and that the audit trail is worth more to them than reach.
Whether agent-to-agent negotiation is even wanted at consumer scale. It clearly works for B2B procurement, where haggling is already normal and volumes justify it. For a $40 purchase the overhead may never pay for itself.
And the hash chain protects against edits, not against a compromised writer. Someone who controls both the events and the hashing can produce a clean-looking chain. Anchoring digests somewhere external fixes that. We have not done it.
What to take from this
If you are building anything where a model triggers real effects, separate the four things that usually get mashed together. What the model wants. What it is allowed to do. What actually happened. Whether that matches the claim.
Keep the middle two out of the prompt. Prompts are for reasoning. Authority and verification belong in code you can test.
Then log the whole thing in a way an outsider can check. You will need it sooner than you think, and it is much easier to add before you have a production incident than after.