THE INDEPENDENT RECORD · AGENTIC AI AS A SERVICE AboutStandardsContact
GAASAGENTIC AI · AS A SERVICE
INDEPENDENT · SINCE 2026
UPDATED DAILY
NO HYPE · NO PAY-TO-PLAY
PER-TASK PRICING NOW STANDARD ● NEW BENCHMARK: 71% TASK COMPLETION ● ENTERPRISE PILOTS UP 4X ● RUNTIME FUNDING ACCELERATES ● "AGENTS ARE THE NEW SEATS" ● MARGINS UNDER PRESSURE ● THE INDEPENDENT RECORD ON GAAS
Verticals

E-commerce Agents: How Catalog and Customer Service Got Their First Real Autonomous Workers

E-commerce agents are vertical AI systems sold as a service that run two of the most labor-heavy parts of an online store: keeping the product catalog accurate and complete, and resolving customer questions end to end. Unlike chatbots, these agents take actions, they rewrite product copy, fix mismatched attributes, issue refunds, and update orders, and increasingly they bill per outcome (a published SKU, a resolved ticket) rather than per seat. The catch is that both jobs sit directly on top of revenue and brand trust, so reliability and guardrails matter more here than almost anywhere else in the agent economy. This piece breaks down what these agents actually do, how they're priced, where they break, and what separates a real deployment from a demo.

By J. Okafor · Apr 17, 2026 · 17 min read

Table of Contents

Why E-commerce Was Always Going to Be an Agent Beachhead

If you wanted to design the perfect proving ground for autonomous AI agents, you'd build something that looked a lot like an online store. The work is high-volume, repetitive, and structured. Outcomes are measurable to the cent. There's a system of record, the commerce platform, that holds clean state. And there's a constant, grinding shortage of people willing to write the four-hundredth product description or answer "where is my order" for the thousandth time this week.

That combination is why e-commerce agents are one of the more mature corners of the broader agentic AI-as-a-service landscape, the cluster of vertical agents now being sold by the task rather than by the license. Where a horizontal copilot helps a human work faster, a vertical e-commerce agent is hired to own a workflow. The merchant doesn't want a tool that drafts a product blurb. They want the SKU live, attributed correctly, and selling.

Two workflows dominate the early market because they share a rare property: they're both painful enough to pay for and bounded enough to automate safely. Catalog operations and customer service. They're the bread and butter of this beat, and they're where most of the real revenue in commerce agents is being booked in 2026.

The Two Jobs: Catalog and Customer Service

It's tempting to lump these together as "AI for stores," but they're genuinely different animals with different risk profiles, different buyers, and different failure modes.

Catalog Agents: The Unglamorous Goldmine

Catalog work is the part of e-commerce nobody puts in the pitch deck. It's also where a stunning amount of money quietly leaks out. A typical mid-market retailer carries tens of thousands of SKUs, each needing a title, a description, a category, a dozen structured attributes (color, size, material, GTIN), images, and increasingly a feed-ready version for Google Shopping, Amazon, and a marketplace or two. Multiply that by suppliers who send data in inconsistent spreadsheets, seasonal refreshes, and the constant churn of new products, and you have a problem that never ends.

A catalog agent does several distinct things, and it's worth separating them because vendors blur the lines:

The reason this is a goldmine is that bad catalog data has a direct, measurable cost. Products with incomplete attributes don't surface in on-site search or faceted navigation. Missing or wrong GTINs get listings suppressed on Google Shopping. Mismatched descriptions drive returns. A catalog agent that lifts attribute completeness from 60% to 95% isn't doing a cosmetic chore, it's unlocking demand that was structurally invisible. This connects directly to the broader question of merchandising and pricing automation, where the agent's catalog work becomes the substrate other systems act on.

Customer Service Agents: Beyond the Chatbot

Customer service is the more visible job, and the more dangerous one. The old generation of e-commerce chatbots deflected tickets by answering FAQs and pointing people at help articles. They didn't do anything. The new generation resolves.

A modern e-commerce support agent connects to the order management system, the carrier APIs, the returns platform, and the payment processor. So when a customer writes "my order's a week late and I want a refund," the agent can look up the order, check the tracking, recognize the carrier is genuinely delayed, apply the store's policy, issue the refund or reship, update the order status, and send the confirmation, without a human touching it. That's a resolution, not a deflection, and the distinction is the whole ballgame. (The resolution-rate metric and how it's gamed is a topic worth its own treatment within the support-agent corner of this cluster.)

The categories that automate well in commerce support are predictable: order status, returns and exchanges, refund eligibility, address changes before fulfillment, sizing and fit questions, and product-detail clarifications that lean heavily on the same catalog data the enrichment agent maintains. That last overlap is underappreciated, a support agent is only as good as the catalog it reads from, which is one reason the two jobs increasingly ship from the same vendor.

What doesn't automate cleanly: anything involving fraud judgment, high-value disputes, regulatory edge cases, or an upset customer who needs to feel heard by a person. Good deployments route those out fast rather than letting the agent flail.

How These Agents Actually Work Under the Hood

Strip away the marketing and most production e-commerce agents share an architecture. There's a reasoning model at the core, usually a frontier LLM accessed through a provider API, with capabilities and guardrails documented in resources like the Anthropic developer documentation on tool use and agent design. Around that sits the part that actually matters in practice: the tool layer.

Tools are the agent's hands. A refund tool. An order-lookup tool. A "update product attribute" tool. Each is a function with a defined schema, permissions, and ideally a dry-run mode. The agent decides which tool to call and with what arguments; the tool layer enforces whether that call is allowed. This separation is the difference between an agent that helpfully processes a $30 refund and one that hallucinates a $30,000 one. The model proposes; the tool layer disposes.

The second non-negotiable piece is grounding. The agent should not answer "is this in stock" from its training data, it should call the inventory tool and read live state. Retrieval over the merchant's own catalog, policies, and order data is what keeps the thing honest. An agent that reasons brilliantly over stale or invented facts is worse than no agent at all, because it's confidently wrong at scale.

Finally, there's the orchestration and escalation logic, the rules for when the agent acts autonomously, when it asks for human approval, and when it hands off entirely. Mature systems treat full autonomy as something earned per task type over time, not granted on day one. You let it handle order-status queries unsupervised long before you let it touch refunds above a threshold.

The Economics: Per-Seat Is Dying Here First

Here's where e-commerce agents are quietly rewriting the SaaS playbook. Traditional software charges per seat, you pay for the human using the tool. But an agent replaces the work, not the worker's mouse. Charging per seat for something that does the seat's job is a contradiction the market is now pricing out.

So commerce agents are leading the shift to outcome pricing. Support agents bill per resolved ticket, often a dollar or two for a resolution that would cost five to fifteen dollars fully loaded with a human. Catalog agents bill per enriched SKU or per published listing. The logic is clean: the buyer pays for the thing they actually wanted, and the vendor's incentives align with making the agent genuinely effective rather than merely licensed. As McKinsey's work on generative AI's economic potential has argued, the value capture in this wave concentrates where AI does measurable work, and commerce operations are about as measurable as it gets.

There's a subtlety, though, and it's where the per-outcome model gets contentious. What counts as a "resolution"? If the agent closes a ticket the customer reopens an hour later, did it resolve anything? Vendors and merchants are still negotiating these definitions, and the honest ones build in clawbacks for reopened tickets and rejected listings. The pricing model is only as good as the outcome definition underneath it, a theme that recurs across every vertical in the agent economy, not just retail.

Reliability and the Trust Problem

Both jobs sit on top of revenue, which makes reliability the entire game. A horizontal writing assistant that hallucinates wastes a few minutes. A catalog agent that hallucinates a product spec creates a returns wave and possibly a false-advertising problem. A support agent that misreads a policy and over-refunds bleeds margin in real time.

The merchants getting this right treat reliability as an operational discipline, not a model property. A few patterns show up repeatedly in good deployments:

The uncomfortable truth is that a 95%-accurate agent sounds great until you remember it's wrong one time in twenty, and at e-commerce volume that's thousands of errors a week. The deployments that work don't pretend the agent is perfect, they engineer the system so imperfection is caught, bounded, and cheap. Agent security and the question of who's liable when an autonomous action goes wrong are live issues across the whole cluster, and commerce is where they get tested first because the money moves immediately.

Build vs. Buy for a Mid-Market Merchant

A recurring question from operators: do you buy a commerce agent off the shelf or build one on top of a foundation model and your own tooling?

For most merchants under a few hundred million in revenue, buying wins, and it's not close. The hard part of a commerce agent isn't the model, anyone can call an API. The hard part is the thousand small integrations and edge cases: the way your returns policy interacts with marketplace rules, the carrier quirks, the supplier feed formats, the taxonomy you've accreted over a decade. A vertical vendor has already absorbed those lessons across dozens of merchants. Building means relearning all of it on your own dime.

Building starts to make sense only when your workflow is genuinely unusual, your volume is enormous, or the agent touches a proprietary process that is your competitive advantage. Even then, many large merchants land on a hybrid: buy the agent platform, but invest heavily in the integration and policy layer that makes it theirs. The build-vs-buy calculus for vertical agents is its own deep topic, and the short version for commerce is that the moat lives in the integrations, not the intelligence.

Where the Moat Really Is

For the vendors building these agents, the defensibility question is the one investors keep poking at. The model is rented from a provider; a competitor can rent the same one. So what's the moat?

It's the same answer that holds across vertical agents generally: proprietary workflow data and depth of integration. A commerce agent that has processed millions of real support conversations and catalog corrections accumulates something a fresh competitor can't easily replicate, a library of how this industry's edge cases actually resolve, which taxonomy mappings work, which refund patterns signal fraud. Pair that with deep, certified integrations into Shopify, the major marketplaces, and the order and returns systems, and you've built switching costs that have nothing to do with the underlying model.

The last mile, domain expertise encoded as workflow logic, escalation rules, and policy handling, is what separates a commerce agent that survives from a thin wrapper that gets commoditized the moment the next model drops. That last-mile expertise is the recurring theme of this entire beat, and e-commerce is one of the clearest places to see it pay off.

Insights Most People Overlook

The catalog agent is the higher-margin business, even though customer service gets the attention. Support automation is crowded and the resolution metric is contested. Catalog enrichment is unglamorous, harder to fake, and tied directly to discoverability revenue, a 5% lift in attribute completeness can move more money than a dozen deflected tickets, and far fewer vendors do it well. The smart money in commerce agents is increasingly on the boring catalog side.

Customer service agents quietly make catalog quality urgent. When a support agent answers product questions from the catalog, every gap and contradiction in your product data becomes a customer-facing error in real time. Merchants deploy a support agent and suddenly discover their catalog was full of lies they could previously ignore. The two jobs aren't separate purchases, buying one creates demand for the other.

"Resolution rate" is the most gameable metric in the category. An agent can hit 80% resolution by aggressively closing tickets that bounce right back, or by defining easy queries as "resolved" and routing everything hard to humans while still taking credit. Sophisticated buyers ignore the headline number and look at reopen rates, downstream refunds, and post-interaction CSAT. If a vendor won't show you those, the resolution rate is marketing.

Outcome pricing transfers model risk to the vendor, which is the real reason merchants love it. Everyone frames per-resolution billing as "you only pay for results." The deeper shift is that when the next frontier model makes the agent cheaper to run, the vendor, not the merchant, captures or shares that upside, and when the model misbehaves, the vendor eats the failed-outcome cost. Outcome pricing is a risk-allocation mechanism dressed up as a fairness story.

The agent that handles returns is sitting on the best fraud signal in the building, and almost nobody mines it. A support agent processing returns and refunds sees patterns no fraud team has time to review, serial returners, address mismatches, suspiciously timed disputes. Treating that agent purely as a cost-cutter ignores that it's also a real-time intelligence layer. The vendors who figure this out will sell the same agent twice.

FAQ

How is an e-commerce agent different from the chatbot my platform already includes? The built-in chatbot almost always deflects, it answers questions and surfaces help articles but can't take action. A true agent connects to your order, returns, and payment systems and resolves the issue end to end: it issues the refund, updates the order, changes the address. Deflection reduces ticket volume; resolution reduces the work itself.

Can a catalog agent handle products it has never seen, like a brand-new supplier feed? Yes, that's the point. Enrichment works by reasoning over the supplier's raw data and product images against your taxonomy, so a novel feed is a normal case, not an edge case. The quality depends on input richness, a feed with images and a few attributes produces far better listings than a bare title and price.

What stops a support agent from issuing refunds it shouldn't? The tool layer, not the model. Refund actions are gated by per-action permissions, value thresholds, and policy checks enforced outside the model's reasoning. Well-built systems also keep refunds in human-approval mode until the agent has proven itself on lower-risk tasks, and they cap the blast radius so any single error stays small.

Does outcome-based pricing actually save money versus per-seat tools? Usually, but the comparison that matters is per-outcome cost versus fully loaded human cost, not versus the old software license. A resolution at one to two dollars against a human resolution at five to fifteen is a clear win at volume. Watch the outcome definition, though, vague definitions of "resolved" or "enriched" are where the savings quietly evaporate.

How do I keep the agent from confidently giving wrong product information? Grounding and evaluation. The agent must read live catalog and inventory data through tools rather than answering from the model's memory, and you should run it continuously against labeled tests and sampled live traffic to catch drift. If a vendor can't explain how their agent stays grounded in your data, treat that as a red flag.

Should a smaller merchant build this in-house? Almost never. The model is the easy part; the value is in the integrations, edge-case handling, and accumulated workflow knowledge that a vertical vendor already has. Building makes sense only at large scale, with genuinely unusual workflows, or when the automated process is itself a competitive advantage you don't want to outsource.

Conclusion

E-commerce agents earned their early lead in the vertical-agent market the honest way: they took on two jobs, catalog operations and customer service, that are painful, high-volume, and measurable to the cent. Catalog agents enrich, normalize, match, and audit product data, quietly unlocking demand that bad data was hiding. Customer service agents move past deflection to genuine resolution, acting on real order and payment systems. Both lean on the same foundations, a reasoning model wrapped in a disciplined tool layer, grounded in live merchant data, with autonomy earned per task rather than granted up front.

The economics are leading the broader shift away from per-seat licensing toward per-outcome billing, which is really a way of moving model risk onto the vendor. And the durable advantage, for vendors and merchants alike, lives not in the rented intelligence but in the integrations, the proprietary workflow data, and the last-mile domain expertise that turns a clever model into a reliable worker. As the rest of the GaaS cluster, from support-agent resolution metrics to the vertical-agent moat to outcome-based pricing models, keeps maturing, commerce remains the place where these ideas get stress-tested against real money first. That's exactly why it's worth watching closely.

References

#per-resolution pricing

More in Verticals