Building a guided shopping agent in Agentforce Commerce: the Shopper, Buyer, and Merchant agents, and the SCAPI plumbing under the storefront

The Agentforce Commerce demo is good: a shopper types “something for a rainy hike under $150,” the agent asks two clarifying questions, surfaces three real products, and adds one to the cart. Everyone in the room pictures their own storefront. Then the implementation starts, and the gap between the demo and the product turns out to be the same gap as every other agent build. It’s not the conversation, it’s the plumbing. The agent that recommends a jacket is a language model. The agent that reads this shopper’s live cart, resolves which size is in stock, and applies their contract price is an integration into the Commerce APIs, wearing a chat bubble.

Agentforce Commerce reached general availability in late June 2026 across three agents (Shopper, Buyer, and Merchant) and Salesforce called it its biggest Agentforce Commerce release yet. This post is the practitioner’s map: what those three agents are and which one you’ll deploy, the guided shopping agent you build from a template, and the SCAPI plus SLAS authorization layer that is the real prerequisite nobody puts on the slide. If you’ve read our take on agentic commerce from the merchant’s side, where the buyer is someone else’s agent hitting your store, this is the mirror image: the agent you run on your own storefront.

Three agents, and which one is your job

The word “agent” is doing a lot of work in the announcement, so separate the three, because they live in different parts of the business and only one of them is a build you configure.

• Shopper Agent is the customer-facing one. It carries a conversation from discovery through checkout and into post-sale service, speaking in your brand’s voice on your storefront and on channels like WhatsApp. This is the one most B2C teams mean when they say “we want a shopping agent.”
• Buyer Agent is the B2B counterpart, and it’s more interesting than it sounds. It meets a business buyer inside WhatsApp or SMS and completes an order without a portal login, handling contract pricing and even confirming a SKU from a photo of the part. For a distributor whose customers reorder the same items constantly, that’s a real workflow, not a novelty.
• Merchant Agent is the back-office one: catalog operations, promotions, and inventory-facing tasks for the merchandiser, not the shopper.

The Shopper and Buyer experiences also reach outward (Salesforce has shipped native integration into ChatGPT, with Google Search (including AI Mode) and the Gemini app following) so the same commerce agent can answer inside an assistant the customer already uses. That’s a distribution story worth understanding, but it doesn’t change the build: the agent still grounds on your catalog and your carts.

What you configure is a guided shopping agent, assembled from a Salesforce template, and that’s where the rest of this post lives.

The prerequisites are the project

Here’s the part that reorders your plan. Before an agent can do anything useful on a storefront, four things have to be true, and three of them are integration work:

1. Licenses for Agentforce Commerce and the underlying Commerce Cloud.
2. Einstein generative AI activations turned on in the org, the model access the agent reasons with.
3. Data 360, the unified data layer the agent grounds on. An agent that doesn’t know the shopper’s order history or the product’s real attributes is guessing, and guessing on commerce is how you promise a discount that doesn’t exist.
4. B2C Commerce SCAPI authorization with the Shopper Login and API Access Service (SLAS).

That fourth one is the quiet giant. SCAPI is the Salesforce Commerce API: the modern REST surface for carts, products, orders, and pricing on a B2C Commerce storefront. SLAS (Shopper Login and API Access Service) is how a shopper, logged in or anonymous, gets a scoped access token to call those APIs. When your guided shopping agent adds an item to this shopper’s cart, it is making an authenticated SCAPI call on that shopper’s SLAS token. If SLAS isn’t configured, the agent can talk about products all day and touch nothing.

A shopping agent’s intelligence is the easy 20%. The 80% is the authorization that lets it act as this specific shopper against a live cart. SCAPI for the operations, SLAS for the identity. Budget the project accordingly.

This is why “we’ll add an agent to the storefront next sprint” is usually wrong. If your SCAPI and SLAS setup is already solid because you’re on a modern headless or composable storefront, the agent is close. If you’re on an older storefront that never adopted SCAPI, the agent is downstream of a Commerce API modernization you haven’t scoped yet.

Turning it on, and what the template gives you

With the prerequisites in place, the enablement itself is short. In Setup, open Commerce Agentforce Settings from Quick Find and turn on Agentforce for Guided Shopping – B2C. Then, under Agentforce → Agents, make sure the Agentforce Agents feature is on. Now you can build.

You build the agent in Agentforce Builder from the Guided Shopping for B2C Storefronts template. Picking the template is what makes this a configuration job instead of a from-scratch one: it seeds the agent with a set of predefined topics and their supporting actions, the foundation of what the agent can do, plus the agent’s default settings and language. The topics you get out of the box map to the obvious storefront jobs:

• B2C Commerce Cart Management: adds simple products to the cart, resolves the correct variant of a master product (the size-and-color problem) before adding it, and shows a cart summary.
• Commerce Product Search Assistant: guides the shopper to products with suggested categories for a broad query, suggested products, and category suggestions when a search returns zero results.
• Commerce Order, looks up order status and line items from an order number or a recent-orders list, and supports quick reorder by cloning a past order.

Those three cover a large share of real storefront intent, and the point of starting from the template is that each topic already ships wired to a real Commerce action, the cart topic calls the actual SCAPI add-to-cart, not a mock. Your job is to shape it: adjust the topic instructions, add the topics the template doesn’t include (returns, store locator, loyalty), and, the part that decides quality, tighten the classification descriptions so the agent routes a “where’s my order” to the order topic and a “do you have this in medium” to cart management. That routing is the single most common failure mode, and it’s the same discipline we’ve written about for designing topics and the descriptions that classify them: the description is the routing logic.

Where a shopping agent is allowed to be wrong, and where it isn’t

Commerce sharpens the read/write question because a wrong answer here has a price tag. Sort the agent’s capabilities the same way you would for any agent, but with money in mind.

Reads are where you start, and the discipline is grounding. Product attributes, availability, the shopper’s order history, a cart summary, these must come from a live SCAPI call whose result the agent reports, never from the model’s memory of what your catalog probably contains. An agent that “remembers” a product spec from training and states it confidently has invented inventory. Ground every product and price claim on the live API, and the Atlas reasoning engine has real data to reason over instead of a plausible guess.

Writes divide by reversibility and money. Adding to a cart is reversible and safe. Let the agent do it end to end. Applying a promotion, honoring a price, or placing an order is a commitment, and commitments belong to deterministic Commerce logic, not to free text:

• A promo code the agent “applies” must be a real code validated by the promotions engine. An agent that generates a discount to be helpful has created a liability the store may have to honor, the commerce version of the agent inventing a fare.
• Pricing, especially B2B contract pricing, comes from the pricing service, full stop. The Buyer Agent’s whole value is that it applies the right negotiated price; that price is a SCAPI read, never a number the model produces.
• Payment never enters the model’s context. Card data belongs behind the Trust Layer’s PII/PCI masking and inside a PCI-scoped checkout flow; the agent can initiate checkout, it should never see the card.

The general rule is the one that keeps commerce agents out of trouble: the agent interprets and orchestrates; the commerce platform prices, promises, and charges. Put a guardrail on every action that moves money, and you get an agent that’s chatty and helpful on the far side of a wall from the operations that commit real dollars.

The cost model, honestly

Two economic facts should shape the rollout. First, an agentic conversation isn’t free. It consumes credits per action, and a shopping conversation is action-dense (search, then variant resolution, then cart, then order lookup can be four or five actions in one exchange). Before you point the agent at all traffic, do the math the way our Flex Credits pricing and optimization posts lay out, because a high-traffic storefront turns a per-action cost into a real line item fast.

Second, and this is the discipline that separates a launch from a science experiment, instrument the outcome before go-live. The metric that matters isn’t “conversations handled,” it’s assisted conversion and average order value against a holdout, plus containment on service questions. A shopping agent that chats beautifully and doesn’t move conversion is a cost center. Launch it to a slice of traffic, measure against control, and expand on evidence: the same measured rollout we bring to any retail and e-commerce engagement.

What to do

Don’t start by writing prompts. Start by confirming the prerequisites, because they’re the project: licenses, Einstein activations, Data 360 grounding, and, the one that sinks timelines, SCAPI authorization with SLAS. If your storefront already speaks SCAPI, build the guided shopping agent from the B2C template, keep the seeded cart, search, and order topics, and spend your effort on classification descriptions and the topics the template omits. Ground every product and price claim on a live API call, and put a deterministic gate in front of anything that applies a promotion, honors a price, or places an order, the agent orchestrates, the commerce platform commits. Then launch to a slice, measure conversion against a holdout, and scale on evidence. Do that and the rainy-hike demo becomes a storefront agent that sells. Skip the plumbing and it’s a confident chatbot that can’t touch a cart. Getting the SCAPI foundation and the governed actions right so a commerce agent acts safely on live data is exactly the Agentforce work we do before one goes live.

Understanding the basics

What is Agentforce Commerce?

Agentforce Commerce is Salesforce’s set of AI agents for Commerce Cloud, generally available since late June 2026 across three agents: the Shopper Agent (customer-facing B2C shopping from discovery through checkout and service), the Buyer Agent (B2B ordering over WhatsApp and SMS without a portal login, with contract pricing), and the Merchant Agent (back-office catalog, promotion, and inventory tasks). The customer-facing experiences also integrate natively into ChatGPT, with Google Search and the Gemini app following. What a team configures for its own storefront is a guided shopping agent, built in Agentforce Builder from a Salesforce template.

What do I need before I can build a guided shopping agent?

Four things, and three are integration work: the right licenses, Einstein generative AI activations enabled, Data 360 for the data the agent grounds on, and B2C Commerce SCAPI authorization with the Shopper Login and API Access Service (SLAS). SCAPI is the Commerce REST API the agent calls to read products and carts and place orders; SLAS is how a shopper gets a scoped token to make those calls as themselves. Without SLAS configured, the agent can discuss products but can’t act on a live cart. You enable the feature under Commerce Agentforce Settings in Setup, then build from the Guided Shopping for B2C Storefronts template.

How do I stop a shopping agent from inventing a discount or a price?

Ground every commercial claim on a live SCAPI call and gate every money-moving action behind deterministic commerce logic. Product availability, pricing, and promotions must be reads from the real engines, reported verbatim, never values the model generates. Applying a promo code, honoring a contract price, or placing an order is a commitment that belongs to the pricing and promotions services, with a guardrail on the action, not to the model’s free text. Payment data stays out of the model entirely, masked by the Einstein Trust Layer and handled in a PCI-scoped checkout flow. The agent interprets and orchestrates; the commerce platform prices, promises, and charges.

---

Building a shopping agent and discovering the real work is the SCAPI and SLAS layer underneath it? Talk to us. Getting the Commerce API foundation and the governed, safe actions right, so the agent grounds on live catalog and cart data and never oversteps, is exactly the architecture we do.