Agentforce Commerce: Intent-Driven Shopping

Salesforce acquired Cimulate, and most coverage treated it as a Commerce Cloud feature announcement. That framing misses the architectural significance. The agentforce commerce conversational AI direction this signals is a fundamental shift in how discovery, intent, and transaction get wired together across the Salesforce platform.

The keyword search model has been the default for 25 years. Cimulate’s acquisition is a direct bet that it won’t be the default for the next five.

Why Keyword Search Breaks at Enterprise Scale

The problem isn’t that keyword search is slow. The problem is that it externalizes the cognitive work onto the customer.

A shopper who types “blue running shoes” is doing the platform’s job for it. They’re translating an intent (“I want to run a 10K without knee pain”) into a query format the system can process. Every step of that translation is a place where intent gets lost, results get irrelevant, and conversion drops.

At scale, this compounds. Enterprise commerce orgs with 50,000+ SKUs, multiple product lines, and complex attribute taxonomies see this acutely. Faceted search helps. Merchandising rules help. But both are still fundamentally reactive to the query the customer typed, not the goal they arrived with.

Conversational discovery inverts this. The system does the translation work. The customer states a goal, a constraint, a context. The architecture resolves that into a product recommendation, a guided flow, or a clarifying question. The cognitive load shifts from customer to platform.

That shift has real conversion implications. In commerce orgs with high SKU complexity, the gap between “customer arrived with intent” and “customer found the right product” is where most abandonment lives.

What Cimulate Actually Adds to the Architecture

Cimulate built a conversational product discovery layer trained specifically on commerce data. Not a general-purpose LLM wrapper. A model that understands product catalogs, attribute relationships, and purchase intent signals at a level that generic AI doesn’t.

That capability is now shipping as part of the Spring ‘26 release under the Agentforce 360 umbrella. The Contextual Search feature, currently in open beta, replaces keyword matching with natural language and shopper intent signals. Critically, it operates across channels simultaneously: your commerce site, social surfaces, and third-party AI channels like ChatGPT via a one-click catalog feed integration.

The architectural implication is specific: this isn’t a chatbot sitting in front of a search bar. It’s a reasoning layer that operates on the product graph itself, now extended to external discovery surfaces you don’t control.

In practice, the relevant integration surface is broader than most architects expect. The connections that matter:

• Product catalog structure; attribute hierarchies, variant relationships, bundle configurations
• Inventory and availability; real-time stock signals that constrain recommendations, now surfaced through the Agentic Boost and Bury capability that automatically promotes trending or high-margin items and suppresses out-of-stock ones
• Customer profile data; purchase history, preference signals, segment membership from Data Cloud
• Pricing and promotions; entitlement logic that varies by customer segment or contract, now triggerable via Marketing and Commerce Connected Journeys for events like cart abandonment

Getting conversational discovery right requires all four to be queryable in near-real-time. That’s a Data Cloud architecture problem as much as a Commerce Cloud problem.

The Data Cloud Dependency Is Non-Negotiable

Most architects will try to wire conversational commerce directly to Commerce Cloud APIs and call it done. That works for simple catalogs. It breaks for anything complex.

The reason is context. A conversational agent that can only see the product catalog will give technically correct answers that are commercially wrong. It might recommend a product the customer already bought last month. It might suggest a bundle that’s out of stock in the customer’s region. It might miss that this customer is on a B2B contract with different pricing.

The architecture that survives here puts Data Cloud at the center. The Unified Individual profile, Calculated Insights for purchase behavior, and real-time Data Streams from Commerce Cloud all feed the context layer that the Agentforce agent reasons against.

Specifically, the pattern that works:

1. Data Cloud ingests Commerce Cloud order history, browse behavior, and cart events via Data Streams
2. Identity Resolution unifies these signals against the customer profile (critical for B2C orgs where guest checkout creates fragmented records)
3. Calculated Insights compute preference signals: category affinity, price sensitivity, brand loyalty scores
4. Data Graphs pre-compute the joins between customer profile, product preferences, and segment membership
5. The Agentforce agent queries this materialized context at inference time, not raw transactional data

The Data Graph step is where most implementations skip corners and pay for it later. Pre-computing joins is the difference between a 200ms response and a 2-second response. In a conversational interface, 2 seconds kills the experience.

For a deeper look at how Data Cloud’s identity layer handles the fragmented-record problem that’s endemic in commerce, see the Data Cloud identity resolution architecture breakdown.

Agentforce Agent Design for Commerce Contexts

The Spring ‘26 release ships two agent patterns that have distinct design requirements: Guided Shopping Agents for on-site assistance, and Two-Way Email agents that turn promotional sends into interactive purchase threads. The design logic differs between them, but both expose the same underlying constraint: commerce agents operate in high-volume, low-context environments.

A service agent might handle 500 conversations a day with rich case history. A Guided Shopping Agent might handle 50,000 sessions a day where the customer has provided two sentences of context and expects a useful answer in three seconds. Two-Way Email adds a different constraint: the agent must maintain coherent context across an asynchronous thread that might span hours.

That changes how you configure Topics, Actions, and Instructions.

Topics need to be scoped tightly. A single “product discovery” topic that tries to handle everything from initial browsing to post-purchase upsell will produce inconsistent behavior. Separate discovery, comparison, and purchase assistance into distinct topics with clear handoff logic. For Two-Way Email specifically, add a thread-context topic that reconstructs session state from prior email turns before the Atlas Reasoning Engine begins its reasoning loop.

Actions need to be fast. Every Action call adds latency. In a commerce context, the Atlas Reasoning Engine needs to complete its reasoning loop quickly enough that the experience feels conversational. This means pre-fetching context via Data Graphs rather than making live API calls to Commerce Cloud at inference time. The Guided Shopping Agent’s Conversion Analytics capability, which feeds session data back into Commerce Cloud Reports, should be treated as an asynchronous Action, not a synchronous one. Blocking on analytics writes during a live session is an avoidable latency source.

Instructions need to encode merchandising logic that would otherwise live in rules engines. Promotional priorities, brand restrictions, margin-sensitive recommendations, and the Agentic Boost and Bury rules all need to be expressed as behavioral constraints in the agent’s Instructions, not as post-processing filters. Filtering after the fact produces recommendations that feel arbitrary to the customer.

The Agentforce agent design patterns for enterprise article covers the broader Topic/Action/Instruction architecture. Commerce contexts add the constraint that latency tolerance is lower and session context is shallower than most enterprise agent deployments.

Integration Implications for Existing Commerce Architectures

Most enterprise commerce orgs aren’t starting from a clean slate. They have existing search infrastructure, often Solr or Elasticsearch-based, with years of merchandising rules, synonym libraries, and relevance tuning baked in.

The question architects will face: replace or augment?

Replacing existing search with a conversational layer is the right long-term direction. The Spring ‘26 Contextual Search feature makes that path more concrete than it was six months ago. But it’s still a 12-18 month program for any org with significant search customization. The merchandising logic embedded in existing search configurations doesn’t automatically translate to agent Instructions.

Augmenting is the practical near-term path. Run Contextual Search and Guided Shopping Agents as parallel channels alongside existing search. The ChatGPT catalog integration and Google Universal Commerce Protocol (native checkout on Google AI surfaces via Google Pay) are low-code activations that extend your discovery surface without touching existing search infrastructure. Use that parallel operation as a data collection phase to understand which intent patterns the conversational layer handles better.

The integration architecture for augmentation: conversational agent handles initial intent capture and disambiguation, hands off to existing search infrastructure for catalog retrieval when the intent is sufficiently specific, then re-engages for comparison and decision support. MuleSoft is the right integration layer where existing search infrastructure is external to Salesforce, because you need bidirectional data flow with transformation logic that Commerce Cloud’s native connectors won’t handle cleanly.

This buys 18-24 months of parallel operation while the conversational layer matures and merchandising logic migration happens incrementally. Holiday 2025 data from Salesforce shows 35% more site time and doubled AI-search traffic for orgs running conversational features, which gives you the business case to fund the migration while the legacy infrastructure stays live.

What Architects Should Do Now

The Agentforce 360 rollout is no longer a product direction signal. Features are shipping in Spring ‘26. The architectural decisions you make now determine whether you activate cleanly or spend 18 months untangling technical debt.

Three things to address immediately:

First, audit your Data Cloud implementation against the commerce context requirements above. If you don’t have Commerce Cloud order history flowing into Data Cloud via Data Streams, Identity Resolution configured to handle guest checkout fragmentation, and Calculated Insights computing purchase behavior signals, you’re not ready for conversational commerce regardless of what’s already in your org.

Second, document your existing search merchandising logic. Not the Solr configuration files. The business logic: what gets promoted, what gets suppressed, what rules govern recommendations by customer segment. This is the hardest migration artifact to reconstruct later, and most orgs have it living in the heads of two or three people who’ve been tuning the search engine for years. The Agentic Boost and Bury feature will need this logic expressed as Instructions, not inferred from configuration files.

Third, evaluate your Agentforce maturity against commerce-specific requirements. If you haven’t deployed an Agentforce agent in production yet, start with a lower-stakes use case first. The Agentforce implementation guide covers the foundational deployment patterns. Commerce is not the right first agent deployment for an org that hasn’t worked through the Topics/Actions/Instructions design cycle on a simpler problem.

The current decision on Data Cloud architecture determines whether conversational commerce is a 3-month activation or a 12-month rebuild.

Key Takeaways

• The Cimulate acquisition has materialized into shipping features in Spring ‘26: Contextual Search (open beta), Guided Shopping Agents, Two-Way Email, and ChatGPT catalog integration. This is no longer a roadmap item.
• Conversational commerce requires Data Cloud as the context layer. Commerce Cloud APIs alone are insufficient for personalized, real-time recommendations at enterprise scale.
• Data Graphs are the performance-critical component. Pre-computing joins between customer profile, purchase history, and product preferences is the difference between a viable conversational experience and an unusable one.
• The practical near-term architecture augments existing search infrastructure rather than replacing it. ChatGPT catalog feeds and Google Universal Commerce Protocol are low-code extensions that expand discovery surface without touching legacy search.
• Orgs that don’t have Data Cloud identity resolution configured for guest checkout fragmentation will face a foundational rebuild before conversational commerce can work correctly.
• The merchandising logic embedded in existing search configurations is the hardest migration artifact. Document it now, before the migration pressure arrives.