Claude shopping concierge in Salesforce Storefront Next

I had an idea.

It’s been a minute, so I thought and thought and, as we all know, that usually leads somewhere questionable.

Remember Office Space when the Bobs are interviewing Tom Smykowski and basically ask:

“Why can’t the customers just talk to the engineers themselves?”

And Tom completely loses his shit. IYKYK.

Anyway.

There is a LOT of AI blah blah on LinkedIn right now.

Agents. Agentic commerce. Shopping agents. Service agents. Merchandising agents. Chatbots with a new name.

Mostly marketing.

The short version

I built Juniper into Salesforce Storefront Next to test what happens when an AI can use the storefront instead of sitting beside it as another chat widget.
Claude is not replacing the commerce platform. It is reasoning across real catalog, pricing, inventory, customer, cart, order, and policy data, then acting through the storefront’s APIs.
The interesting question is no longer “How do we add AI to a website?” It is “What happens when AI becomes the primary interface?”

Meet Juniper

As part of the Storefront Next Après Studio project I showed earlier this year, I wanted to actually build something and see where the edges were.

At Studio Science, our recent partnership with Anthropic gave me another reason to get a little obsessed with Claude.

So I made Juniper.

Juniper is a shopping concierge. The role gets broader as the conversation moves.

Shopping assistant
Search
Product expert
Stylist
Salesperson
Customer service
Concierge
Researcher

She’ll even do 6 × 7.

We’re basically at AGI.

😬

She lives inside the storefront the customer is already using. The products she shows are shoppable. The bag she changes is the storefront’s bag. Someone can browse, ask a question, compare an option and carry on without treating the conversation as a separate shopping trip.

That’s what I mean by an immersive concierge. Help that stays with the shopping, rather than another place to start over.

Claude can use the storefront

The interesting part isn’t that Juniper can chat. Chatbots have existed since dinosaurs roamed shopping malls.

The interesting part is that Juniper can use the storefront.

Tell her:

“I’m going to Aspen for four days in January. I need something for skiing during the day, something comfortable for the lodge, and something I can wear out at night. Keep it under $1,200.”

And she can actually work the problem.

She can:

Understand what you’re trying to accomplish instead of forcing you to translate it into keywords
Search the actual commerce catalog
Reason across categories and products
Understand product attributes, content, and context
Compare products and explain the differences
Recommend an entire outfit or multiple-item solution
Remember what you’ve already told her
Answer questions about sizing, shipping, returns, and policies
Build and modify the cart
Move you toward checkout
Help with policy questions afterward, and order questions when the relevant order data is available

Juniper in action

This is the part I mean. The conversation doesn’t stop at an answer. Juniper can use context, move across products and content, change the actual bag, read that state back, and hand the customer into checkout.

These are all from the working prototype. The earlier screens below show the checkout handoff; the newer Stripe integration now brings checkout inside Juniper too. Scroll each row; open any frame for the full-size view.

Context and judgment

Juniper using an Open-Meteo forecast for Crested Butte to suggest clothing — When a forecast source is connected, Juniper can use it.

A second view of Juniper’s Crested Butte forecast response — A second capture of the live forecast response and recommendation.

Juniper answering follow-up questions about favorite ski towns — Follow-up questions keep the prior conversation in scope.

Juniper discussing Crested Butte and recommending a related Journal story — A subjective answer can still connect back to useful brand content.

Juniper comparing ski mountains across Oregon — Open-ended travel questions still get a specific point of view.

Juniper handling weather context, a Journal recommendation, and a math question in one thread — Different requests stay in one thread without resetting the customer.

Juniper declining to invent a live forecast and recommending relevant owned content instead — Without a forecast tool, Juniper says so and uses only what she knows.

Juniper explaining why arithmetic is available but live weather requires a connected source — Arithmetic is local; weather needs a source. The boundary is explicit.

The weather screens show different tool configurations. That is useful too. In one version Juniper has a forecast source; in another she doesn’t. The point is that she knows the difference instead of making something up.

Catalog, products, and content

Juniper answering how many coats are in the catalog and showing part of the range — She can answer questions about catalog breadth, then show the range.

Juniper recommending two jackets after reasoning about weather and a trip to Crested Butte — A weather-aware request moves into actual product recommendations.

Juniper assembling a sports bra and leggings outfit for stand-up paddleboarding — The same interface can assemble a use-case-driven outfit.

Juniper turning a request for cute socks into two shoppable product options — A vague preference becomes a concrete, shoppable comparison.

Juniper showing two sock products with prices and purchase options — Natural-language discovery becomes a real product set.

Juniper recommending two warm-weather Journal stories — Juniper searches editorial content, not just products.

Juniper recommending Journal stories for a slow Sunday — A vague mood becomes a small, relevant reading list.

Juniper surfacing visually strong stories from the Après Studio Journal — She can surface the strongest visual stories in the Journal.

Bag and checkout

Juniper resolving a jacket color and size before adding it to the shopper’s bag — Juniper resolves color and size, then changes the live bag.

Juniper confirming a green Summit Fleece Jacket was added to the bag — The bag update is reflected immediately in the storefront.

Juniper adding socks to the bag, confirming the new subtotal, and answering a follow-up joke request — A product choice becomes a cart action, then the conversation keeps going.

Juniper reading the shopper’s current bag and returning three products with the subtotal — The bag is commerce state, not conversational theater.

Juniper presenting a three-item checkout summary for 314 dollars — The checkout summary uses the same three-item bag state.

Juniper presenting a checkout handoff for three products totaling 314 dollars — Checkout stays with Salesforce; Juniper gets the customer there.

A second view of Juniper’s checkout handoff and three-item order state — A second checkout state confirms the same transaction path.

Underneath all of that, Salesforce B2C Commerce is still Salesforce.

Catalog. Pricing. Inventory. Customers. Cart. Orders. Checkout.

The commerce facts need to come from Salesforce. Juniper’s job is to reason across them and use the storefront’s APIs to actually do things. A confident answer is not a substitute for the current price or available size.

That distinction matters.

We have been thinking about AI in commerce backwards

We keep asking:

How do we add AI to a website?

Add a chatbot.

Add an AI search box.

Add recommendations.

Add a shopping assistant.

Add another little floating thing in the bottom-right corner that everyone closes.

But what happens when AI isn’t something you add to the interface?

What happens when AI becomes the interface?

Think about how absurd ecommerce actually is.

A shopper knows what they want. Then we make them learn our information architecture.

Departments → Categories → Subcategories → PLP → Filters → PDP → Back → PLP → Different PDP → Reviews → Size guide → Search → Cart.

The customer spends half their time translating human intent into the language of a website.

Why?

So this is the idea I’ve been playing with:

Claude-first sites

Not a website with Claude bolted onto it.

A storefront built with the assumption that a shopper should be able to tell the site what they are trying to accomplish… and the site figures out the rest.

Navigation still exists.

PDPs still exist.

Search still exists.

Beautiful design absolutely still exists.

But none of them have to be the primary way a human communicates intent to a commerce platform anymore.

That’s a fundamentally different interaction model.

Why this matters for brands

This could mean:

Less dead-end search
Less bouncing between fifteen PDPs
Better product discovery
Natural cross-sell instead of dumb “you may also like” carousels
Whole-outfit or whole-project selling
Customer service inside the same conversation that started the purchase

Most importantly, the intelligence lives inside the brand’s own storefront, where the brand keeps the customer relationship instead of surrendering discovery to Amazon, Google, OpenAI’s ChatGPT, Claude, or whatever comes next.

Those are outcomes to test with customers, not conversion gains established by a prototype. I’d want to know whether people find suitable products more easily, understand their choices and complete the purchase with fewer unresolved questions.

Juniper is the first version of this inside Après Studio. She is already making me question how much of the ecommerce UX we’ve spent the last 25 years perfecting is about to become optional.

I’ve taken the next step with native Stripe checkout in Storefront Next and Juniper. On the other side of the storefront, I’m exploring marketing and merchandising work in Slack. The shopper and the team running the store both need the conversation to connect to something real.

Is Studio Science going to single-handedly murder every search box, chatbot, recommendation engine, and “AI shopping assistant” on the internet?

Obviously.

Probably by Thursday.

But seriously…

I think Claude-first commerce is a thing.

And I think we’re looking at the beginning of a very different web.