CIS 4394 Agentic AI · Fall 2026 · Dr. Xinyu Fu
CIS 4394 Agentic AI · Fall 2026 · Dr. Xinyu Fu
Search is reversible. Summarizing is reversible. Paying is not. This page is about the four things that change when the last step of the loop is a purchase — irreversibility, liability, identity, and the merchant's side of the problem — and about the young, competing standards trying to make agent-initiated payments checkable.
Your retry logic was built on an assumption that just broke: that doing the thing twice is harmless. It is not. A timeout on place_order() is genuinely ambiguous — did the order go through? Retrying blindly is how one purchase becomes two. The fix has a name (idempotency) and it lives on page 02.
When an agent buys the wrong thing, somebody eats the cost: the customer, the merchant, the agent's operator, or the payment provider. That allocation is decided by contracts and by what can be proven — which is why “what did the user actually authorize?” has to be a question the system can answer, not a question the lawyers argue about afterward.
Two different questions, often confused. Identity: is this really the customer's agent? Authorization: is this specific purchase inside what the customer allowed — this item, this amount, this window? A credential proves the first. Only an explicit record of the user's instruction proves the second.
From the store's side, a helpful agent and a scraping bot look similar: automated traffic, no human rhythm, no mouse movement. Years of fraud tooling was tuned to block exactly that pattern. Merchants now need a way to tell “a customer's agent, acting with permission” apart from abuse — and to keep the sale rather than refuse it.
This is the shape of nearly every agentic purchase. Click a node: each one tells you what goes wrong there and who ends up holding the cost.
The amber node is the last cheap place to be wrong. Everything above it can be redone for free; everything below it costs money to undo.
Work down the diagram. For each step, ask the two questions this page keeps repeating: what can go wrong here, and who pays when it does.
In September 2025 two overlapping proposals appeared for making agent-initiated payments work: AP2, announced by Google with a set of payments and technology partners, and ACP, published by Stripe and OpenAI. They are early, they are still changing, and they solve related but different problems. Treat what follows as a snapshot, not a settled answer.
Google's announcement frames AP2 as an open protocol for payments initiated by agents, built around mandates: signed, verifiable records of what the human actually authorized — the intent, the cart, and the payment — expressed as W3C Verifiable Credentials. The point is that a merchant or an issuer downstream can check the permission slip rather than take the agent's word for it, and that the record survives afterward as evidence of consent. It is positioned to sit alongside agent-to-agent and tool protocols rather than replace them (Google, 2025).
Stripe and OpenAI published ACP as an open standard for agent-initiated checkout: a documented way for an agent to hand a merchant a cart, have the merchant confirm price and availability, and complete payment — with a Shared Payment Token arrangement so the merchant continues to be the merchant of record and keeps its own relationship with the customer, rather than the agent platform taking it over. The specification is published openly (Apache-2.0 on the spec repository) so that merchants and agent builders can implement against the same shapes (OpenAI & Stripe, 2025).
Primary source — the Stripe announcement ↗ · agenticcommerce.dev ↗ · spec repo ↗
| AP2 (Google + partners, 2025) | ACP (Stripe + OpenAI, 2025) | |
|---|---|---|
| Centre of gravity | Payment authorization — proving a human permitted this spend. | The checkout transaction — a common way for an agent and a merchant to complete a sale. |
| How consent is carried | Mandates as verifiable credentials (intent → cart → payment), signed and checkable after the fact. | The buyer's confirmed cart plus a shared payment token scoped to that purchase. |
| Who most needs to care | Issuers, networks, wallets, and anyone who has to answer “was this authorized?” | Merchants and agent platforms wiring up a working buy button inside a conversation. |
| Openness | Published openly by Google with partner input; check the current specification before building. | Specification published on an open repository under Apache-2.0; check the repo for the current version. |
| Maturity (as of this course) | Both are early. Both were announced in 2025, both are still being revised, and they overlap in places and complement each other in others. Nothing here says one has won — and any page that tells you which one won is guessing. | |
“We told the agent not to overspend” is not a control. Each of these lives in code or configuration, outside anything the model can talk its way past — the Week 10 governance lesson, applied to money.
| Control | What it actually stops | Where it lives |
|---|---|---|
| Spending cap | The runaway: an agent that misreads a price, a quantity, or a loop and spends far past what anyone intended. Caps come in layers — per transaction, per day, per month. | The harness and the payment credential. Enforced before the tool runs, and again by whatever issues the funds. |
| Merchant allow-list | Purchases from places nobody vetted — including the storefront that a poisoned search result invented. If it is not on the list, the call fails. | Tool configuration. The agent cannot add to its own list. |
| Per-transaction mandate | Scope creep between approval and execution: an approval for one item at one price being reused for a different, larger purchase. | The authorization record that travels with the payment — the idea AP2 is trying to standardize. |
| Receipt | Silent action. Every completed purchase produces an artifact a human can read, tied to the approval that permitted it. | Your system of record, plus the customer's inbox. |
| Audit trail | Unanswerable questions later: what did the agent see, what else could it have chosen, why this vendor, who approved it. | Trace storage — the Week 2 evidence standard, retained for as long as a dispute could arrive. |
Do not choose between “fully autonomous” and “ask a human every time.” Sort actions into three rungs, and be explicit about the boundary between them.
Reading a catalog, checking inventory, pricing options, drafting the cart. Nothing here costs anything to undo, so gating it only teaches people to stop reading approvals. Log it; do not interrupt for it.
A repeat purchase of a previously approved item, from an allow-listed vendor, under a fixed per-transaction and monthly limit. The agent may act, but the limit is enforced in code, and hitting the cap raises an alert rather than silently failing.
New vendor, new item, amount above the cap, anything that touches a contract or a subscription. The agent proposes; a named human approves. This rung is small on purpose — a long approval queue is an approval queue nobody reads.