Agentic Commerce: What 17 Months Have Taught Us
Learn how AI agents could reshape shopping, payments and checkout—and what merchants must solve around consent, trust, data and failed transactions.
Agentic Commerce After the Hype: What Has Actually Changed?
AI agents that can shop, compare prices, and even pay on a customer's behalf have shifted from conference-stage speculation to real products and live payment experiments. That move matters - but it doesn't mean consumers are ready to hand over every buying decision, or that merchants can just plug in a protocol and expect more sales.
The real question isn't whether an agent can complete a transaction. It's whether it can do so safely, predictably, and in ways that actually benefit the customer, the merchant, and the payment parties involved. That takes more than a capable language model. Agents need reliable identity and product data, clear spending permissions, working payment infrastructure, and a way to handle all the messy things that happen in commerce.
This article revisits the core case for agentic commerce: which consumer problems agents might solve, what incentives could push adoption, and which parts of the emerging stack still need work. The takeaway is straightforward - agents can reduce shopping effort, but they won't remove the need for customer choice, trust, or a well-designed checkout.
What is agentic commerce, and how does an agent work?
Agentic commerce is shopping where software acts toward a customer's goal: finding suitable products, comparing options, applying preferences, and - within agreed limits - helping complete a purchase. It's different from a search engine that returns links or a recommendation system that suggests products. An agent is expected to carry the task further by taking action across services.
That difference is useful, but it's also where the hype can creep in. An agent isn't necessarily fully autonomous, and it doesn't have to make every decision without a person. In a lot of realistic shopping journeys, the "agent" does the research and repetitive admin, then asks the customer to approve the final purchase.
The operating loop: perceive, reason, act, learn
A commerce agent typically follows four steps:
- Perceive: Gather the user's goal, preferences, and relevant context. That can include a price limit, delivery location, past purchases, product availability, or a preferred payment method.
- Reason: Compare options against the goal. The system may use a language model, structured data, rules, and other models to weigh trade-offs - or ask a clarifying question.
- Act: Take an approved action through an interface or integration - for example, add an item to a basket, apply a discount, or submit a payment.
- Learn from feedback: Check what happened. Did the item arrive? Did the customer accept the choice? Did the payment fail? Feedback should improve future decisions without silently expanding the agent's authority.
This loop goes beyond shopping. Similar systems could manage household spending, coordinate small-business inventory, or flag cash-flow risks. Commerce is just a particularly visible use case, because it combines a clear consumer task with an immediate transaction - and that makes both the promise and the risk hard to ignore.
Autonomy needs boundaries
Agents can be reactive (responding to a prompt) or proactive (acting when a defined condition is met). A customer might ask for a one-time comparison, or set a rule to reorder a household essential when supplies run low. Those are different permissions in practice.
A safe system should separate permission to research, permission to prepare a transaction, and permission to spend. "Find the best replacement under $50" shouldn't automatically become "buy any replacement under $50 without asking." The user's goal, the scope of authority, and the point of confirmation should be explicit.
This is also where technical definitions turn into product design. A system can be very capable and still be a bad agent if it can't explain why it chose an item, can't respect a budget, or can't recover when an order is out of stock. In real commerce, those aren't edge cases. They're the daily reality.
Which shopping problems can agents solve?
The strongest argument for shopping agents isn't that they make buying feel futuristic. It's that they can reduce specific kinds of effort that already make online shopping frustrating: too many options, weak personalization, and friction at checkout.
Choice overload
Online stores can carry a larger catalog than a physical shop can show. That helps availability and price competition, but it also increases the work needed to find something suitable. Customers compare specs, read reviews, check delivery terms, and often repeat the same steps across multiple sites.
An agent can narrow a large catalog into a shortlist - if it has accurate product information and a clear understanding of what "best" means for that customer. "Best" might be lowest price, but it could also be durability, delivery speed, compatibility, or a specific brand. A good agent makes those criteria visible, rather than treating "best" as one universal ranking.
For merchants, a better-matched shortlist can help people decide. But fewer options don't automatically mean more sales. If the agent misunderstands a preference or omits an item for commercial reasons, it can damage trust more quickly than an ordinary search result. Merchants and agent providers need ranking logic and product data that customers can rely on.
Personalisation that reflects context
Many recommendation systems lean on narrow signals: a previous purchase, a product view, or a broad demographic category. That can lead to suggestions that are technically related but timed poorly or simply irrelevant to what the customer needs right now.
An agent could combine stated preferences with recent activity and context - like a budget, an upcoming trip, or something the customer already owns. For instance, it might find a replacement that fits a known device, rather than recommending a popular accessory that doesn't work. The value comes from context, not from hoovering up every possible data point.
And that matters. Shopping history, location, and financial information are sensitive. Personalization should use data the customer has knowingly allowed the agent to use, for a purpose they can understand and change. If the experience feels intrusive, people won't give the trust needed for delegated purchasing.
Decision fatigue at checkout
Even after choosing a product, a customer may still have to enter an address, find a discount code, pick a payment method, and review delivery details. Each step adds effort, and a confusing "last mile" can undo an otherwise smooth purchase.
An agent could fill in known information, apply eligible discounts, and suggest a payment method based on the customer's preferences. The customer's decision can shrink to something simpler: approve the completed order or cancel it. That reduces friction - but it shouldn't hide what's being bought, the total cost, any recurring terms, or the payment method being used.
The practical goal is less repetitive work, not less informed consent. A clear summary and an approval step may be more valuable than trying to remove every interaction. If the agent can't explain the total and the reason for its choice, a one-click checkout may be fast - but it's not necessarily good.
Why might merchants and payment companies invest?
Agentic commerce has a plausible business case because the benefits could be shared by multiple parties. Customers may spend less time searching and checking out. Merchants may reach customers who are more likely to find the right product. Payment providers and agent platforms may earn revenue from enabling transactions and supplying infrastructure.
This resembles the commercial logic behind buy now, pay later (BNPL) - sometimes described as a "Klarna effect." Merchants can see conversion and basket-size gains, customers get a different checkout experience, and providers earn a share of the activity. The point is aligned incentives, not a guarantee that agents will deliver identical outcomes. Agentic commerce still needs to prove it creates incremental value instead of simply moving transactions between channels.
Why payment providers have a potential advantage
A useful commerce agent needs more than product discovery. It has to know who is authorized to buy, handle payment credentials safely, and complete transactions across merchant systems. Payment processors already run parts of that infrastructure, and they often bring experience with stored credentials, tokenisation, fraud controls, and merchant integrations.
Identity and data providers can also matter. They can connect financial information that customers have permitted and verify account details, while commerce platforms provide catalog, inventory, and order data. The source material points to developments such as agent-focused payment tooling, the Agentic Commerce Protocol, and Stripe Link Balance as examples of market experimentation. Those are signs of activity - not proof that one standard or company will dominate.
Execution across multiple capabilities likely determines who wins:
- Identity: Can the system reliably identify the customer and represent their preferences and permissions?
- Structured, current data: Are prices, availability, shipping terms, and product attributes accurate enough to support decisions?
- Payment infrastructure: Can the agent transact securely, with appropriate authentication and clear control over credentials?
- Merchant coverage: Can it work across enough retailers to be useful - even when things don't go smoothly?
- Trust and accountability: Can the customer understand what happened and fix a mistake or dispute?
A payment company may have a head start in transaction infrastructure, but it doesn't automatically own the customer relationship or the best shopping experience. Likewise, an AI platform may have a strong assistant, but still lack reliable catalog access and payment permissions. Partnerships are likely, and the economics will matter - someone pays for discovery, integration, support, and transaction processing.
The merchant case depends on incremental value
Merchants shouldn't assume an agent will increase conversion just because it shortens checkout. It could redirect a loyal customer to a competitor, negotiate away margin, or introduce an intermediary fee. It could also generate more returns if the agent optimizes for price without understanding fit or quality.
So the core commercial question isn't "Can an agent buy from us?" It's "Does this channel deliver valuable customers and completed orders at a sustainable cost?" Track conversion alongside average order value, returns, support contacts, fraud, repeat purchase, and total acquisition or integration costs. That's how you tell whether you've created real improvement - or just rearranged demand with a new interface.
What should the agentic commerce stack include?
Agentic commerce isn't just a model plus a payment API. It's a chain of systems that needs to preserve the customer's intent from discovery through fulfilment and support. If any layer fails, the customer can end up with the wrong order and no clear party responsible for fixing it.
The layers behind a working transaction
A practical stack needs at least these components:
- Customer-facing agent: Understands the request, communicates options, and records the customer's permissions.
- Product and merchant data: Provides structured information about products, price, availability, delivery, returns, and relevant restrictions.
- Decision and policy layer: Applies preferences, spending limits, and eligibility rules; asks for clarification when information is missing.
- Identity and consent: Connects the request to the right person and records what the agent is allowed to do, for how long, and within what limits.
- Payment and authentication: Uses secure credentials or tokens, applies the correct payment method, and escalates for approval when required.
- Order, fulfilment and support systems: Confirms the transaction, tracks delivery, and handles changes, cancellations, returns, and disputes.
- Monitoring and feedback: Logs decisions and outcomes so the system can be audited, improved, and corrected.
The customer remains part of this stack - not as a nuisance to automate away, but as the person whose money and preferences are at stake. Depending on the purchase and the permissions granted, final approval could be a click, a biometric confirmation, or a pre-authorised rule. The key is that the customer understands the boundary and can revoke it.
Design for unhappy paths, not only a successful payment
Most commerce demos show the clean path: the agent finds an item, pays, and confirms the order. Real production systems have to handle expired discounts, changing prices, unavailable inventory, duplicate orders, declined payments, partial fulfilment, delivery delays, returns, and suspected fraud.
Those failures create operational questions. Who tells the customer the price changed? Can the agent substitute an item, or must it ask? If a payment succeeds but the order doesn't get created, which system reconciles it? If the customer disputes an agent-authorised purchase, can the merchant and payment provider reconstruct what the agent was told and what the customer approved?
Before granting agents more access, merchants should check that they can provide current product and policy data, identify agent-originated orders, confirm consent, and recover failed transactions. They should also test whether support teams have enough context to help - without exposing unnecessary personal information.
A practical readiness checklist
For a first implementation, keep it narrow and make results measurable:
- Pick a repeatable customer task with clear success criteria, like reordering a known product or comparing a defined category.
- Decide which actions the agent can take and which require customer approval.
- Set explicit spend, merchant, category, and time limits where relevant.
- Ensure product, price, shipping, and returns data is accessible and current.
- Define what happens when an item is unavailable, a price changes, or payment fails.
- Record the customer's instructions and the agent's actions so support teams can inspect them.
- Compare conversion and task completion with returns, fraud, support burden, and margin.
This approach is less dramatic than full autonomy, but it gives teams real evidence about where the agent helps - and where it just creates new work. It also limits the cost of learning while standards, consumer expectations, and payment models keep evolving.
Key takeaways
- Agentic commerce is about software carrying out a customer's shopping goal, not just recommending products.
- The clearest consumer use cases reduce choice overload, improve contextual relevance, and cut repetitive checkout work.
- A working business model needs value for the customer and merchant, not only for the agent or payment provider.
- Identity, consent, accurate commerce data, secure payments, and customer support all belong in the stack.
- Start with bounded permissions and one specific task. Measure the full outcome, including returns and support costs - not just checkout conversion.
- Agents can automate steps without taking away the customer's final say.
Conclusion: automate the work, preserve the choice
Agentic commerce has a real opening where it removes specific repeated effort - comparing a large catalog, applying a customer's preferences, or handling routine checkout steps. But convenience alone isn't enough. Agents need to respect clear permissions, use reliable data, handle failures, and give customers a meaningful way to review and correct decisions.
For merchants and payment providers, the next step isn't to automate every purchase. It's to test one bounded use case, measure the full economics, and build the operational paths that a polished demo tends to skip. Automate what customers don't value - keep choice and accountability with the customer.