Salesforce dropped Agentforce Commerce on June 24, 2026, and the scope is wider than most architects anticipated. Three distinct agents, a search acquisition baked into the platform, two new channel integrations, and a headless-first inventory model; all landing simultaneously. The agentforce commerce deployment checklist below is what you need before your first sprint planning session.
This is not a feature overview. It is a sequenced set of architectural decisions with real dependency chains.
What Actually Shipped and What It Means Architecturally
Three agents, each with a distinct data surface and trust boundary:
Shopper Agent is live today for B2C. It operates on the storefront, handles product discovery, cart management, and order status. The Atlas Reasoning Engine drives its reasoning loop, which means it inherits the same Topics/Actions/Instructions model as every other Agentforce deployment. The critical architectural implication: Shopper Agent needs read access to product catalog DMOs in Data Cloud, real-time inventory state, and order management APIs. If your Commerce Cloud catalog is not yet streaming into Data Cloud via Data Streams, that is your first blocker.
Buyer Agent targets B2B procurement workflows over WhatsApp and SMS. This is the channel integration that will catch architects off guard. WhatsApp and SMS are async, stateful channels with no native session concept. The agent must reconstruct context across turns using Data Cloud’s Unified Individual profile; which means Identity Resolution rulesets need to correctly unify B2B buyer contacts across CRM, Commerce, and messaging channel identifiers before this agent can function reliably. Misconfigured fuzzy-match thresholds in Identity Resolution will produce split profiles, and a Buyer Agent operating on a split profile will quote the wrong contract pricing.
Merchant Agent handles B2B catalog management: product updates, pricing rules, inventory thresholds. This one runs in a back-office context with write permissions to catalog objects. The trust boundary here is fundamentally different from the customer-facing agents. Merchant Agent actions need explicit permission set architecture and, critically, audit logging via Platform Events if your org operates under any procurement compliance requirement.
Agentic Commerce Search, built on the Cimulate acquisition, replaces the prior keyword-based search layer with a semantic, intent-aware model. Architecturally, it sits between the storefront request and the product catalog DMO. The integration point is the Data Graph; Cimulate’s semantic index needs to be materialized against the same Data Graph that Shopper Agent queries, or you will have search results and agent recommendations diverging on the same session.
The Dependency Chain Before You Configure Anything
The most common mistake in multi-agent commerce deployments is treating each agent as an independent configuration task. They share infrastructure, and the infrastructure has to be sequenced.
Start with Data Cloud. Specifically:
-
Data Streams from Commerce Cloud (catalog, orders, inventory) must be active and validated before any agent configuration begins. Stale or incomplete DMOs will produce hallucinated product recommendations that no amount of prompt tuning will fix.
-
Identity Resolution rulesets must cover all buyer touchpoints; email, phone, CRM contact ID, and any external loyalty or ERP identifiers. For B2B orgs with complex account hierarchies, the Unified Individual model needs to be extended to handle account-level purchasing authority, not just individual identity.
-
Data Graphs need to be materialized for the product catalog join pattern that both Shopper Agent and Agentic Commerce Search will query. A Data Graph that is not pre-computed forces real-time joins at query time, which breaks the latency budget for conversational commerce interactions. Target materialization refresh cycles of 15 minutes or less for inventory-sensitive catalogs.
-
Calculated Insights for buyer-level metrics (purchase frequency, contract tier, credit status) need to be available on the Unified Individual profile before Buyer Agent can personalize B2B recommendations or enforce pricing rules.
Only after those four layers are stable should you begin agent Topics and Actions configuration.
The salesforce-data-cloud-implementation-guide article maps the Data Cloud dependency model in detail; the sequencing there applies directly to this commerce architecture.
Channel Configuration: OpenAI and the Headless Model
The OpenAI/ChatGPT channel integration is architecturally significant beyond the obvious “your agent is now accessible via ChatGPT” headline. It means Shopper Agent can be invoked from outside the Salesforce-controlled storefront surface. That changes your trust model.
When a shopper interacts via ChatGPT, the session does not originate from your authenticated storefront. You cannot assume the user is logged in. Shopper Agent must handle both authenticated and anonymous contexts, with graceful degradation: anonymous users get catalog browsing and generic recommendations; authenticated users get personalized recommendations, saved cart state, and order history. The Topics configuration needs explicit branching logic for this, not a single unified topic set that assumes authentication.
For the headless backend flexibility Salesforce is positioning here, the practical architecture is: Shopper Agent as the reasoning layer, Commerce Cloud APIs as the action layer, and your headless frontend (React, Next.js, or whatever your stack is) consuming agent outputs via the Agentforce API surface. The agent does not render UI. It returns structured data that your frontend renders. If your team is conflating “headless agent” with “the agent builds the page,” that misconception will cost you weeks.
The Google channel integration is announced as forthcoming. Do not architect for it yet. Build the OpenAI channel integration cleanly, and the Google integration will be an additive channel configuration, not a structural change; assuming Salesforce maintains channel parity, which their current architecture suggests they will.
Unified Inventory Orchestration Across POS and Storefront
Unified inventory is the hardest part of this deployment for any org operating physical retail alongside digital commerce. The promise is a single inventory truth across POS terminals, storefront, and agent-driven transactions. The reality requires explicit orchestration design.
The inventory state that Shopper Agent queries must be the same state that POS terminals decrement against. In practice, this means your inventory Data Stream needs to consume from a single authoritative source; typically an ERP or OMS; not from Commerce Cloud’s internal inventory tables, which lag behind physical POS transactions by minutes in most implementations.
For orgs with 3,000+ retail touchpoints, the typical pattern is: ERP as inventory master, Platform Events for real-time decrement propagation, Data Cloud as the read layer for agent queries. Shopper Agent reads from Data Cloud (fast, scalable), POS writes to ERP (authoritative), Platform Events bridge the two with sub-minute latency. Attempting to make Commerce Cloud’s native inventory the master record at this scale produces oversell events during peak traffic.
Merchant Agent’s inventory threshold management adds another layer. When Merchant Agent updates a reorder threshold, that write needs to propagate back to ERP, not just update a Commerce Cloud field. External Services configuration for the ERP write-back is not optional; it is the difference between Merchant Agent being a useful tool and being a dangerous one that creates phantom inventory commitments.
The Permission and Audit Architecture You Cannot Skip
Three agents with different trust levels operating on the same platform require explicit permission architecture. This is where most rushed deployments create compliance risk.
Shopper Agent: read-only on catalog and inventory DMOs, read/write on cart and session objects, no access to pricing rule objects. Implement via a dedicated Agentforce permission set, not by extending existing Commerce user profiles.
Buyer Agent: read on contract pricing objects, read on account hierarchy, write on quote draft objects only. The write scope must be scoped to draft state; no agent should be able to commit a B2B order without a human confirmation step in the flow. Build that confirmation gate as a Flow action within the Buyer Agent’s action set, not as an afterthought.
Merchant Agent: write on catalog and pricing objects, but every write action must emit a Platform Event to your audit log. If your org is subject to SOX, GDPR, or procurement compliance requirements, Merchant Agent without audit logging is an audit finding waiting to happen. Configure Platform Event subscribers before you enable Merchant Agent in production.
The salesforce-governance-framework-for-enterprise article covers the permission set architecture patterns that apply here; the agent-specific layering is an extension of those same principles.
For teams moving quickly on this launch, the /services/agentforce-architecture service page outlines the architectural review process for exactly this kind of multi-agent, multi-channel deployment.
Key Takeaways
- Shopper Agent is live today but blocked by Data Cloud readiness; validate Data Streams, Identity Resolution, and Data Graph materialization before any agent configuration begins.
- Split B2B buyer profiles in Identity Resolution will cause Buyer Agent to quote incorrect contract pricing; fix the fuzzy-match thresholds first, not after go-live.
- Agentic Commerce Search (Cimulate) must be materialized against the same Data Graph as Shopper Agent, or search results and agent recommendations will diverge within the same session.
- Unified inventory at POS scale requires ERP as the authoritative source with Platform Events bridging to Data Cloud; Commerce Cloud’s native inventory tables cannot serve as the master record at volume.
- Merchant Agent without Platform Event audit logging is a compliance liability; configure the audit subscriber before enabling write permissions in production.
