AI Purchase Framework: How Amex Checks Agent Intent

A payment approval is not the same as purchase intent

Payment authorization means a payment can proceed under the payment system's rules. It doesn't automatically prove that the agent followed the customer's specific request. For example, a customer might ask for white Nike sneakers in size 9, while an agent submits a purchase for a different brand. The payment can still be technically valid while being wrong in the context of the customer's instruction.

That distinction matters for trust and for operations. If AI shopping is supposed to save time, customers can't realistically be expected to inspect every detail like they're making the purchase themselves. But if agents get broad access to payment credentials without a way to carry the constraints along, customers end up disputing purchases after the fact - because the mismatch shows up only once the charge is already in motion.

Amex says it hasn't seen an increase in disputes tied to agentic commerce yet. The framework is being introduced proactively because the company expects this kind of shopping to grow. Building guardrails early is easier than trying to patch consistent authorization and evidence across systems after a bad pattern becomes widespread.

More autonomy means more need for clear boundaries

Not every agent-driven purchase needs the same level of oversight. One customer might want to approve each purchase individually. Another might let an agent reorder household essentials when supplies run low - still with limits on things like price, quantity, or product type.

So the system needs more than a simple yes/no approval. It needs to represent the conditions under which an agent is allowed to act. Those conditions could include a maximum budget, a named merchant, or a preferred product and size. The more autonomous the agent, the more important it is that those boundaries stay explicit and checkable.

1. Capture the customer's instructions

The process starts with a Create Intent API. It captures the customer's purchase request and the relevant constraints - like a merchant, a maximum budget, or product preferences, depending on what's in the request.

Different agents and services may collect this information in different ways. Amex says the framework should be flexible enough to support multiple agentic commerce models. That flexibility matters because consumers won't interact with shopping agents through a single standardized interface. Some will use conversational assistants, while others will rely on automated workflows connected to a retailer or another service.

The key requirement is consistent across interfaces: the system has to turn a natural-language request into constraints that can be checked. If a customer says, "Find a pair of white size 9 sneakers from Nike for less than $150," the system needs a machine-usable representation of brand, color, size, and budget - not a vague note that the customer "wanted sneakers."

2. Authenticate the customer and confirm the intent

After the request is captured, the customer authenticates and approves the intent recorded by the agent. This step is meant to connect the instructions to the customer, rather than treating the agent's interpretation as automatically authoritative.

There's a trade-off in how much confirmation users get. More approval can reduce ambiguity, but asking customers to approve every detail can erase the convenience that makes agentic shopping attractive in the first place. The right level likely depends on the purchase and on what permissions the customer has already set. One expensive purchase might justify a direct review. A recurring order within a narrow price range might not need the same interruption every time.

The framework's usefulness also depends on how clearly that approval is communicated. If customers can't see what constraints they're authorizing, authentication proves identity - not informed consent. Good confirmation should make the important limits legible without forcing people to parse a long technical record.

3. Create an Intent ID and Proof of Intent Token

When the customer approves the captured request, the system creates an Intent ID (a unique identifier) and a Proof of Intent Token that contains the customer's high-level constraints.

The token can then be used to obtain a secure digital payment credential for the agent to use at checkout. The agent uses that credential rather than the customer's actual card number. The goal, in principle, is to separate payment details from the broader authorization context while still tying the transaction back to the approved intent.

Amex says the Intent ID and token can also be used elsewhere in the transaction process, including fraud prevention and dispute resolution. The design point is that the record of what was authorized shouldn't disappear when checkout succeeds - it should still be relevant when a transaction is reviewed later.

4. Check the transaction against the approved request

Amex's approach is to bring intent into the transaction flow earlier, not just rely on controls after a payment has been submitted. If an agent tries to purchase something that conflicts with the approved constraints, the framework could help prevent the transaction from going through.

That doesn't mean every product detail can be checked in every system. The quality of any comparison depends on the data the agent, merchant, and payment systems pass along. But the core idea is to give those participants a common reference point: what the customer authorized, and what the agent is trying to buy.

Fewer avoidable disputes and clearer records

If an agent makes a mistake, a structured record of the customer's approved intent could make it easier to figure out where the mismatch occurred. Was the instruction captured wrong? Did the agent select the wrong product? Did the merchant provide inaccurate product information?

A shared identifier and token won't magically answer every dispute question. But they can give the dispute process something more useful than a bare transaction record.

This could matter to merchants and card issuers in practical ways: support tickets, cancellations, returns, and payment disputes often turn on what the customer expected and how the mismatch happened. Better evidence around authorization could help teams investigate more consistently. It may also help distinguish an agent's execution error from a customer's later change of mind.

The benefit is only as good as the implementation. A record is useful only if relevant parties can access it, interpret it correctly, and trust the underlying data. If a token exists but can't be connected to product details or the agent's actions, it won't do much in a real dispute.

Safer automation for repeat purchases

Some of the most useful applications may be everyday rather than flashy. For example, a customer could approve an agent to reorder paper towels or other household staples when supplies run low, with conditions like an acceptable price or product size.

Here's where intent-based controls can make automation more practical. Without reliable limits, businesses may not feel comfortable letting agents buy without a person present. With verifiable constraints, businesses can consider delegating more routine actions - while keeping controls around what can be bought and under what terms.

That doesn't make autonomous purchasing risk-free. Substitutions, price changes, and fuzzy product descriptions can still lead to mismatches. The value is that businesses can decide which decisions are safe to automate and which should be pushed back to the customer.

A possible shared layer for agentic commerce

Amex says it wants the framework to become an industry standard, but that outcome isn't automatic. Payments rely on multiple networks, issuers, merchants, platforms, and agent providers. A framework is most helpful when those participants can implement it consistently - not when it works only inside one company's systems.

Amex says it's already discussing ACE with partners across the payments ecosystem, including agentic tokens that contain Amex payment credentials and other parts of the developer toolkit. That's an implementation signal, not proof of broad adoption. For businesses evaluating agent commerce, the key question is whether payment and commerce partners can support compatible ways to transmit and verify intent.

Natural-language requests are often incomplete

Customers don't always specify every constraint that matters. Someone might say "buy the usual" or "find a good deal," which leaves major decisions to the agent. The agent still has to interpret what "usual" means, decide whether a substitute is acceptable, and determine whether shipping costs count against the budget.

A robust system has to handle ambiguity deliberately. It might ask a follow-up question, use previously approved preferences, or stop when the request can't be interpreted safely. If the system silently fills gaps with assumptions, the intent record could end up preserving a bad interpretation instead of preventing it.

Product data and agent behavior still matter

A control can only compare what it has. If product attributes are missing or inconsistent, the system may not be able to tell whether an item matches the customer's request. There's also the possibility of mismatch between what an agent shows and what it actually submits at checkout - like presenting one item to the customer and sending a different product identifier later.

That means the system needs reliable links between the original request, the product data, and the final order.

There are also operational questions around exceptions. Can a merchant offer a close substitute? What happens if an approved price changes before checkout? Does the purchase fail, or does the customer get another chance to confirm? The right behavior depends on the product category, timing, and what customers prefer. The important part is defining those rules explicitly rather than assuming the token alone solves everything.

Privacy, access, and interoperability need attention

An intent record can be sensitive. It may reveal preferences, budgets, brands, or household needs. Businesses deploying intent records should consider what data gets stored, who can access it, how long it's retained, and whether the token exposes more information than necessary.

Interoperability is another practical test. If one AI provider captures a customer's request but a merchant or payment service uses a different implementation, intent still has to be represented consistently enough to verify it. Without that, businesses may end up with fragmented systems and duplicate controls - extra cost without a dependable end-to-end safeguard.

Finally, customers need controls they actually understand for setting and revoking an agent's permissions. Authorization shouldn't turn into a permanent, invisible grant just because it was convenient to create. Businesses will need clear messaging around what the agent can do, when the permission expires, and how the customer can change it.

For teams evaluating the framework or similar approaches, these questions are a useful starting point:

• Can the system represent specific purchase constraints, not just general approval?
• Does the customer see what the agent understood before permission is granted?
• Can the transaction be checked against those constraints before completion?
• Can relevant parties use the record to investigate a mismatch?
• Are privacy, retention, revocation, and exception handling defined?
• Does the approach work across the partners involved in the actual purchase?