The Agent That Bought the Wrong Shoes: Why Purchase Intent Is the First Real AI Agent Contract
Published: 2026-10-15
The Scenario That Ended the Honeymoon
A customer asks an agent to buy white sneakers, size nine. The agent submits an order for a different brand. Same category, same size, same colour, wrong everything that mattered.
This is the example American Express gave TechCrunch when it announced its "Intent Intelligence Framework" on October 13, and it is worth sitting with, because it is not a story about a model being stupid. It is a story about a model being plausible. The agent did not hallucinate a product that does not exist. It did not invent a price. It did what language models are extremely good at doing: it produced a competent-looking answer to an underspecified question, and the answer was close enough to the original that no naive check would have caught it.
Amex's framing is that a card network can catch it, by comparing the transaction against the captured instructions before the purchase clears.
What the Framework Actually Does
Per TechCrunch's reporting, the mechanics run in a specific order:
- A Create Intent API captures the customer's purchase instructions alongside their constraints — merchant name, maximum budget, product preferences.
- The customer authenticates and signs off on the intent the agent captured.
- An Intent ID is created, plus a Proof of Intent Token carrying the customer's high-level constraints.
- That token is exchanged for a secure digital payment credential, which the agent uses at checkout in place of the customer's actual card number.
- Amex, or whichever party is positioned to check, can verify the transaction against the intent — and can decline it when the agent drifted.
Hannah Bozian, Amex's VP of Agentic Partnerships and Strategy, told TechCrunch that the distinguishing feature is timing: "Our approach differs from the implementations of others in that it pulls intent earlier into the transaction flow. And this is important because it helps mitigate some risk before the risk occurs."
That sentence is the whole architecture. Everything else is plumbing.
Why "Earlier" Is the Only Word That Matters
Most agent safety mechanisms are post-hoc. A model does something, a filter evaluates it, a log records it, a human gets paged. That is fine for text. It is structurally useless for money, because money moves in one direction and does not enjoy a review period.
Intent capture moves the checkpoint to before the agent has agency. The interesting consequence is not fraud prevention — Amex told TechCrunch it has not yet seen an increase in agentic-commerce disputes, and this is explicitly a proactive build. The interesting consequence is that it makes intent itself a recordable object.
This distinction is worth stating more sharply than the press coverage did. There are two entirely different security postures available to anyone deploying an agent against a real-world action.
The first is detection: let the agent act, then look at what it did and decide whether that was acceptable. This is the posture nearly every agent framework ships with today. It is cheap, it requires no changes to anyone else's systems, and it works beautifully right up until the action is irreversible. A detection-based system can tell you, with great precision, that your agent bought the wrong shoes. It cannot un-buy them.
The second is authorization: capture what was permitted before the agent acts, and refuse anything outside it. This is what Amex is describing. It is more expensive, it requires the cooperation of a party the agent does not control, and it is the only posture that survives contact with a transaction that cannot be reversed.
The payments industry arrived at this conclusion decades ago for human cardholders, which is why there is a difference between a credit card number and a card that has been frozen. The novel part is applying the same logic to a system that decides on its own what to buy. And that, genuinely, is new — not because intent is a new idea, but because there has never before been a customer who could make a purchase without knowing what it was buying.
The Uncomfortable Detail in the Amex Example
Go back to the shoes for a second, because Bozian's example is more revealing than it looks at first pass.
A customer asks for white sneakers, size nine. The agent orders a different brand. Amex blocks it. Good outcome. But notice what the framework had to know in order to block it: that brand was one of the constraints. The constraint existed because the customer mentioned it. If the customer had said "buy me white sneakers, size nine, I do not care about the brand," the agent's substitution would have been correct, and the block would have been the bug.
This means the framework's accuracy is bounded by how completely a human expresses themselves in a prompt. And humans do not express themselves completely. They assume context. They assume that a reasonable agent knows that the sneakers are for a wedding and not for the garden, and that this distinction is more important than the colour.
A system that enforces only captured intent will enforce a person's worst articulation of what they wanted rather than their actual want. That is not a flaw in Amex's design specifically; it is the fundamental ceiling on any intent-based control. The check can only be as good as the sentence that produced it.
There are two ways out. One is better prompting interfaces that force the human to specify constraints explicitly at the moment of delegation. The other is a feedback loop, where a blocked transaction teaches the system what the human actually cares about and updates the constraint set accordingly. The first is a UI problem and will get solved. The second is a learning problem and is much harder, because it means an agent's understanding of your preferences evolves without you explicitly saying so — which is exactly the behaviour the whole framework was built to constrain.
Once intent is an Intent ID, you can do things you could not do before. You can attach it to a dispute. You can ask which agent acted on which intent and when — Bozian noted this could help address fraud committed by an agent, which is a category the current dispute system is not shaped for. You can audit a transaction chain without needing the model's reasoning trace. That last part matters enormously for any company that has tried to explain an LLM's behaviour to an auditor.
An audit trail is not a nice-to-have. It is the difference between a system that can be insured and a system that cannot. Insurers do not underwrite processes they cannot reconstruct after the fact, and no reconstruction is possible if the only record of what happened is a language model's own account of its reasoning. A token issued by a third party, checked by a third party, and logged by both is the first artefact in this entire field that an actuary could use.
The Autonomy Spectrum Nobody Has Drawn
The most candid passage in the TechCrunch piece is not about security. It is about consent decay.
Many agents today ask for confirmation before purchasing. Bozian told TechCrunch that Amex foresees a future where agents act "much more autonomously in some cases" — her example was re-ordering household staples like paper towels, where the only real constraints are price and size, not merchant or brand. In that world, a human is not in the loop, because a human in the loop for toilet paper is a human wasting their one irreplaceable resource.
This is the part the industry keeps failing to discuss honestly. The choice is not between "human approves everything" and "agent runs free." It is a gradient, and the gradient should be set per-category by how much the specific instruction actually constrains the outcome. "Buy these exact shoes" is a tight constraint. "Rebuy household staples under fifty pounds" is a loose one. A framework that treats both identically is not a framework, it is a checkbox.
Amex's design at least gestures at the gradient by putting the constraints in the token rather than in the model's memory. That is the correct place. A constraint held in a system's weights is a suggestion. A constraint held in a token checked by a third party is an agreement.
Where This Connects to Everything Else
The consumer appetite is real and measurable. In Amex's Trendex report, cited by TechCrunch, 66% of surveyed US consumers said they are likely to use AI agents to research the best price for a product or service, and 61% said they are likely to use one for a product recommendation within the next 12 months.
But appetite is not the constraint. Trust is not even the constraint. The constraint is legibility — the ability of one system to verify what another system was told.
Every serious multi-agent problem reduces to this eventually. An agent that cannot prove what it was asked to do cannot be held responsible for doing it wrong, and an agent that cannot be held responsible is not autonomous, it is unsupervised. The difference between those two words is the difference between a product and an incident.
There is a version of the agentic future where every transaction carries its own provenance — the instruction, the constraints, the authorization, the agent identity, all bound together and checkable by a party that does not trust the agent. That is not a payments feature. That is the missing primitive. Payments just got there first because payments is where being wrong costs money in a currency that everyone already agrees on.
Consider what happens when the same pattern is lifted out of commerce. A coding agent asked to refactor a module, with the constraints captured and a token issued, and the resulting diff checked against the token before a merge. A research agent asked to summarise a competitor's pricing, with the scope authorized in advance, so that a later claim of "I was only following instructions" becomes checkable rather than rhetorical. A customer-support agent authorized to issue refunds up to a threshold and no further, where the threshold lives in a token rather than in a system prompt that the agent itself might be persuaded to reinterpret.
None of those are exotic. All of them are blocked today by the same missing piece: there is no standard way to hand an agent a scoped, verifiable grant of authority that outlives the conversation in which it was issued.
That is why the payments case matters more than its press cycle suggests. It is not a fintech story. It is the first time a large institution has said, in public and with an API behind it, that delegating to an agent requires a contract rather than a prompt.
What Is Still Missing
Three things, stated plainly.
Identity of the agent is not the identity of the human. A Proof of Intent Token proves a human authorized an intent. It does not prove which agent acted on it, or that the agent that acted was the agent that was authorized. The piece notes an Intent ID can help establish "which agent," which is the right instinct, but the agent-identity layer is not the same as the intent layer and should not be conflated with it.
Intent drift within a session. The framework captures intent at creation. An agent running a long task may have its objective reshaped mid-flight by retrieved content, a changed context, or a tool response. Pre-authorization does not detect a slow-motion deviation that stays inside the outer constraints.
The standardization question is the whole question. Amex says it wants the Intent Intelligence Framework to become an industry standard, and that it is in discussions with partners across the payments ecosystem. A framework adopted by one network is a feature. A framework adopted by all of them is infrastructure. The failure mode in between is a decade of incompatible intent schemas, which is exactly what happened with early digital wallets.
There is also a quieter risk in standardizing early. The intent schema that wins will determine what constraints are even expressible. If the standard carries merchant, budget, and category but not timing, or not counterparty identity, or not a delegation depth, then those constraints will be invisible in practice — not because anyone forbade them, but because there is nowhere to write them down. Standards are not neutral. They are an ontology, and the ontology decides what can be checked.
The Honest Summary
A card network built a mechanism to make a customer's instruction travel alongside the purchase it authorized. That is a small, specific, unglamorous piece of engineering. It is also, as far as I can tell, the first time anyone has treated a natural-language instruction to an AI agent as something that could be legally and technically binding at the moment of consequence rather than merely descriptive.
The shoes will still get bought wrong sometimes. But for the first time, there will be a record of what was asked for, and a party at the till with an interest in comparing the two.
That is not the end of the agent-safety problem. It is the beginning of it being a problem with a paper trail.
Sources
- TechCrunch — "Amex introduces a framework to prevent AI agents from making unauthorized purchases" by Sarah Perez, October 13, 2026. All facts and quotations attributed to American Express in this essay — the framework name, the API mechanics, the intent-drift example, the autonomy comments from Hannah Bozian, and the Amex Trendex consumer figures — come from this article.
Analysis note: The reporting above is TechCrunch's. The framing in "Why 'Earlier' Is the Only Word That Matters," the autonomy-gradient argument, and the three "What Is Still Missing" items are my own analysis, offered as opinion rather than established fact. I have not independently verified Amex's claims about dispute rates, nor tested the framework.