Before Your AI Coworker Buys Anything, Define What You Actually Authorized

A Card Number Is Not a Purchase Instruction

On October 13, American Express introduced an Intent Intelligence Framework that captures a customer's instructions before an AI-mediated transaction and carries evidence of those instructions toward checkout. The interesting part is not that an AI system can pay. It is that a payment should be checked against what a person actually meant to buy.

That distinction matters just as much for a five-person business ordering replacement parts as it does for a consumer buying shoes. A Teammate that can find suppliers, compare quotes and prepare an order is useful. A Teammate that can spend because somebody connected a card is operating without a defined purchasing mandate.

The announcement describes a Create Intent API that records constraints such as merchant, maximum budget and product preferences. After the customer authenticates and approves the captured intent, an intent identifier and proof-of-intent token can connect the transaction to those constraints; a tokenized payment credential is used instead of the underlying card number. American Express describes this as a framework and is discussing implementation with partners. It is not a reason to assume that every merchant or business card already enforces these controls.

The practical lesson is broader than any one payment network: authorization should travel with the job, not merely with the person or payment credential. If the requirements change on the way to checkout, the Teammate should stop and ask. This is intent engineering expressed as a purchase boundary rather than a polite instruction in a chat window.

Purchase Intent Is a Contract Between a Request and an Action

Most purchasing mistakes happen in the gap between a reasonable request and a plausible substitute. “Order the replacement filters” sounds clear until the preferred supplier is out of stock, a different size is in stock, shipping doubles the total, and the cheapest result comes from a marketplace seller with no warranty.

The requester did not necessarily authorize any of those choices. Nor does a generic monthly spending limit answer them. A $300 cap may stop a $400 order while allowing the wrong $180 part. Payment permission answers whether money can move; purchase intent answers whether this particular money should move for this particular outcome.

A usable purchase-intent record has six fields:

1. Purpose and exact need. Which operational problem is being solved, including specifications or an approved SKU? “Keep the kitchen running” is an objective, not an order specification.
2. Approved alternatives. Are equivalent brands or substitutions allowed? Who decides equivalence when compatibility or safety matters?
3. Supplier boundary. Which vendors, domains or contract accounts are approved, and is a marketplace reseller acceptable?
4. Total-cost ceiling. Include tax, freight, rush fees and recurring charges, not just the displayed unit price.
5. Authority and expiry. Who approved the request, when does that approval end, and does it permit one transaction or several?
6. Evidence and exception path. Which quote, inventory signal or customer request justified it? Where does the Teammate pause if a term no longer matches?

Think of this as a small purchase order written before a checkout attempt. The record does not need an elaborate enterprise procurement application. A structured form or ticket with a stable ID is enough to start, provided the downstream payment route can actually respect its constraints. If it cannot, keep the Teammate on research and order preparation while a human submits payment.

American Express's earlier ACE Developer Kit description separates identity, intent intelligence, payment credentials and cart context into different services. That separation is useful as a design model even if your business never integrates ACE. Verified identity tells you who is acting; cart context tells you what is being purchased; an intent record tells you whether those things match the approved job. None is interchangeable with the others.

What good looks like, and what bad looks like

Consider a small service company replacing an air-filtration unit for a customer job on Thursday. The operations lead approves one compatible filter model from an existing supplier, a delivered total up to $240, one shipment to the service depot, and an expiry at 3 p.m. Wednesday. The Teammate checks stock, prepares the cart and attaches the supplier quote to the request. If the model is unavailable or the delivered total rises, it sends the lead the changed terms and waits.

That is a good boundary: the Teammate handles search and clerical work while the human defines acceptable variance. The evidence remains attached to the transaction so the bookkeeper can later answer why the purchase happened.

The bad version gives the Teammate a card and says “get what we need before Thursday.” It finds a near-match from a new seller, chooses overnight shipping, and still stays under a card's daily limit. Every individual step may look sensible. Together they can produce an unusable part, a missed job and a dispute that is difficult to reconstruct. The problem was not insufficient intelligence; it was missing organizational intent at the transaction boundary.

Put the Boundary Before Checkout, Not After the Statement

The timing of the check changes the outcome. A post-purchase alert can tell you that an unapproved order occurred. It cannot make an incompatible part useful or undo a rush fee without a return process. The October 13 American Express proposal is notable because it moves authenticated intent earlier in the transaction flow rather than relying solely on a later fraud or dispute investigation.

A small-business purchasing flow should therefore have three explicit gates.

Gate one: prepare without spending

Let the Teammate read approved catalogs, current inventory, outstanding requests and supplier terms. It can produce a recommended item, compare alternatives and draft an order with the delivered total. Read access and draft creation are different permissions from card access or a final purchase API.

This is the safest starting point for an unfamiliar supplier or a new Teammate role. For a broader risk framework, see what changes when AI starts spending money: a constrained trial reveals whether the system gathers the right evidence before any write authority is granted.

Gate two: approve a bounded request

The approving human should see a decision packet, not a one-line “Can I buy this?” message. Show the item and specification, supplier identity, delivered total, delivery deadline, reason for purchase, alternatives considered, and any deviation from the original request. Record the answer against the same request ID.

Approval should be scoped to those terms. If the cart changes from a one-time purchase to a subscription, or shipping changes the total beyond the cap, the old approval should no longer authorize checkout. The case for human-in-the-loop decisions explains the decision side of that handoff; purchasing adds a final comparison between the approved packet and the actual cart.

Gate three: enforce the comparison externally

At checkout, compare the current cart, merchant and total with the approved intent. Ideally, a payment service, supplier account or separate purchasing gateway enforces those fields. The Teammate must not be able to edit its own authorization record and then declare the new cart compliant.

If the available integrations cannot enforce those limits, do not treat a prompt saying “stay under $240” as a substitute. Have the Teammate submit a draft and let a human complete checkout, or use a purchasing account with vendor and transaction controls that apply independently of the model. Trust architecture means arranging the system so an incorrect choice cannot simply become an authorized charge.

A final receipt should capture both the attempted purchase and the result: intent ID, approver, original constraints, actual cart, timestamp, supplier, total, and any declined attempt. Keep only the information necessary for the business's retention and privacy requirements. A payment token is not a reason to store a full card number in a chat transcript.

Build a Small-Business Purchase-Intent Workflow This Week

You do not need to automate all procurement to test this operating model. Pick one recurring, low-risk buying category with clear specifications, such as standard office supplies. Keep regulated items, customer-specific materials with compatibility risk and new suppliers in human checkout until the process has proved itself.

Step 1: Map the current handoff. Identify who requests a purchase, who confirms the specification, who approves spending, who has payment access and who reconciles the receipt. One person may hold several roles today. Write them down separately so authority does not disappear into an informal message thread.

Step 2: Define the approved envelope. For the pilot category, specify eligible items or SKUs, suppliers, total delivered cost, destination, maximum frequency and an expiry date. Decide whether partial fulfillment is allowed. A recurring approval is not the same as an unlimited standing order.

Step 3: Separate research from payment. Give the Teammate access to the information it needs to assemble options, but leave payment permissions disabled while you test its recommendations. Ask it to show the source of availability and price, including when those signals were last checked. A stale quote is an exception, not an excuse to guess.

Step 4: Name the approver and define escalation. A changed SKU, new supplier, price increase, subscription term or delivery-location change must trigger a fresh decision. If nobody responds by the purchase deadline, the Teammate should report the potential missed deadline; it should not interpret silence as permission.

Step 5: Reconcile a dry run. Compare the prepared cart with the approved request. Try a wrong product that stays under the price cap, a correct product with excessive freight, and a duplicate order. All three should be blocked or returned for human review before checkout. A test that only checks the total will miss the most common semantic errors.

Step 6: Add a narrow execution path. Only after the dry run passes should you enable a vendor-restricted purchasing route or a payment control that the Teammate cannot modify. Set an independent daily limit as a backstop, not as the definition of the task. Record declined attempts as well as successful orders.

Step 7: Review after a real cycle. Sample requests, approvals, receipts and exceptions with the person who actually owns procurement. Ask whether the Teammate saved time without shifting hidden verification work to a manager or bookkeeper. Tighten the permitted category before expanding it.

This is also a seam-design exercise. Search and comparison can be delegated. Specification changes and exceptions return to a human. Checkout follows only after the boundary has been satisfied. A capable Teammate can continue its work after a decision without losing the request history; it should never manufacture the decision it needs to proceed.

FAQ

Q: What are AI coworker purchase-intent controls?

A: They are rules and evidence tied to an individual purchasing request: what may be bought, from whom, at what total cost, by when, under whose authority, and what change requires a new decision. They are more specific than a general card limit or a broad permission to shop.

Q: Is an approval message enough to authorize an AI purchase?

A: Only if the message identifies the approved terms and the execution route can check the actual cart against them. A generic “looks good” attached to an earlier quote does not approve a changed supplier, delivery fee or recurring contract. Where enforcement is unavailable, keep final checkout with a human.

Q: Does the American Express framework already protect every AI-mediated business purchase?

A: No. American Express described a framework and partner discussions on October 13. Its ACE materials describe services and a future protection commitment with conditions. Check the actual availability, card eligibility and terms before relying on any network feature; use your own internal purchasing boundaries regardless.

Q: How is purchase intent different from a budget cap?

A: A cap limits the amount that can be spent. Intent also limits the item, merchant, purpose, delivery terms, timing and permitted substitutions. A wrong purchase can fit comfortably under a cap. Both controls matter, but neither can stand in for the other.

Q: Who is accountable if a Teammate orders the wrong item?

A: The business needs a named human owner for the purchasing process, an approval record and an independent way to stop or reverse an order. The Teammate's activity log helps reconstruct events but is not a substitute for assigning authority. Your contractual and payment-provider rights depend on the applicable terms.

Q: Can a small business start without a dedicated purchasing platform?

A: Yes. Use a structured request, an approver, a limited supplier account and human checkout while testing. Automate final payment only when the authorization and cart can be compared by a control the Teammate cannot rewrite.

If you're ready to put durable roles and clear decision boundaries around your team's work, Associates AI Teammates lets you configure AI coworkers on persistent agent servers while your staff stays in charge of the consequential calls. View pricing and choose the right place to start.