On-Demand Delivery Specialists for SFCC Composable Storefronts

The first article in this series told the story of how we rebuilt sees.com on Storefront Next with agents doing most of the typing. The second described what replaces the support retainer once the agents that built a site stay on to run it. This one is about the part of the story I think is least appreciated, and, for anyone running an IT organization inside a retailer, the most important.

Almost none of what we built is specific to storefront code.

What a skill actually is

Strip the commerce nouns out of our delivery infrastructure and look at what’s left. A skill, in our world, is a codified procedure with guardrails: what evidence to gather, what checks must pass, who approves, what gets escalated to a human. I walked through that loop in detail in the last article (the QA contract, the triage workflow, the human who signs every merge), so I won’t re-run it here. What matters for this piece is the shape underneath it.

The storefront was simply where we learned to run that pattern safely at production stakes. Six million sessions is a wonderful teacher. It forces you to build the things that make agents trustworthy rather than merely impressive: evidence-grounded outputs, mandatory verification, escalation paths, audit trails. Those disciplines are the hard part. The commerce content is just the first payload.

The same shape, everywhere you look

Now walk the pattern around the rest of the enterprise.

Legal approvals. A contract-review skill that checks an SOW against the master agreement, flags every delta, and routes the package for signature reads exactly like our QA contract with different nouns. Gather evidence: the two documents. Run the checks: clause by clause, against a rulebook the legal team owns. Prepare the decision: a redline and a summary of what changed. Let a human make it.

Procurement. An agent that assembles the vendor comparison, checks proposed terms against purchasing policy, chases the missing security questionnaire, and drafts the approval package is our triage workflow pointed at a different queue. HR onboarding, marketing operations, finance reconciliations, data enrichment, the same shape everywhere: gather evidence, run the checks, prepare the decision, let a human make it.

This is the real answer to the question CIOs keep asking: “We’re using AI, so why do the benefits only show up as a better day for staff instead of a better business for the enterprise?” Because AI arrived in most companies as personal tooling: a copilot here, a chat window there, individual people quietly getting faster. Personal tooling improves someone’s Tuesday. Operational infrastructure changes the P&L. The gap between those two things is not a product you can buy. It’s a set of skills (in both senses of the word), and somebody in the business has to build them.

Why buying a platform won't save you

Here is the uncomfortable part for anyone hoping to procure their way through this. Every vendor in your stack is currently rebranding as an AI platform, and much of what they're shipping is genuinely good. Buy it. Use it. But understand what it can't do: a platform cannot get interested in your problems.

The value we generated at See’s didn’t come from a platform feature. It came from noticing that parity checking was eating human weeks and building a pipeline for it. From noticing that demo reviews collected forty repetitive notes and turning those notes into measured gates. From noticing a cart being created at session start, invisibly, across six million sessions, and asking why. Every one of those is the same move: get interested in a problem, then reach first for an agentic, automated solution rather than a bigger backlog and a request for headcount.

That move is a habit, and habits live in teams, not in software. An enterprise that buys an agent platform without building the habit gets what most got from the last three platforms: shelfware with a dashboard.

Two kinds of IT department

Which brings me to the fork in the road. Over the next couple of years, I think retail IT departments will split into two recognizable species.

The first kind sucks air through its teeth. Everything is hard. Everything is a security review, a six-month estimate, a reason for the business to want less. This posture made a certain grim sense when IT capacity was genuinely scarce and every request was a threat to the roadmap. But it is lethal now, because the business can see, on their phones, in their own personal tooling, that the work has stopped being hard in the way IT keeps insisting it is. An IT team that positions itself as the department of no, at the exact moment the cost of yes is collapsing, is writing its own outsourcing memo.

The second kind I’d call IT entrepreneurs. They run toward problems, including problems that were never “IT problems”: the legal bottleneck, the procurement slog, the merchandising team’s promo setup misery. They prototype an agentic workflow in days, wrap it in the guardrails they learned running production systems, measure the savings, and take it to the CFO as money. Then they do it again. Each skill they ship makes the next one cheaper, because the infrastructure (the evidence patterns, the approval flows, the audit trails) is shared and improving.

For that second kind of team, this era is the best thing that has ever happened. IT stops being a cost center defending a backlog and becomes the place where the enterprise's operating leverage is manufactured. The CFO gets compounding efficiency they can actually book. And the CIO gets the only job security that matters now: being the executive who transformed the company, rather than the one who administered its tickets while somebody else did.

Why we’re really excited about Storefront Next

This is why I keep saying Storefront Next is not just another platform upgrade, however it may look on a slide.

Yes, it’s a faster, cleaner, more convention-driven storefront, and yes, it unlocks merchants: the people closest to revenue get a control surface they can actually use instead of a ticket queue they wait in. That alone justifies the move.

But the bigger prize is what the migration does to the IT team that runs it. A Storefront Next build done the way we did See’s is a working apprenticeship in agents-as-infrastructure: specs as the source of truth, agents writing code to the PR, automated QA, evidence-gated releases, humans concentrated on judgment. Come out the other side, and your team doesn’t just have a new storefront. It has the skills, the guardrails, and the confidence to point the same machinery at the next problem, and the one after that, all the way to the legal department.

The revolution starts in the storefront because the storefront is where the stakes are real and the payback is fast. It doesn’t stay there. The IT teams willing and experienced enough to take that chance won’t just survive the next few years; they’ll be the ones running the transformation everyone else is buying slideware about.

64labs is a Salesforce Commerce Cloud partner and Storefront Next launch partner. If you want your Storefront Next migration to leave your team transformed, not just your storefront, that’s the project we most like to run. Ask us. John will be at Dreamforce if you are going. Email John at jduncan@64labs.com.

‍

At the end of the last article I said the specs, tests, and agents that built See’s new storefront are now the same infrastructure that runs it, and that this was a story about what happens to “managed services” that deserved its own article.

This is that article.

The loop that runs the site

Here’s what post-launch support looks like on See’s today.

A delivery lead spots a problem. Or a merchandiser does. Or an automated check does. They paste it into Slack: a screen recording, an expected behavior, sometimes just a sentence. From there, an agent takes over. It triages the report against the Functional Specification Documents that are still the source of truth for the site, reproduces the behavior, and files the Jira ticket, correctly categorized, linked to the relevant spec, evidence attached. Then it writes the fix in the right repo and raises a draft PR.

The PR doesn’t arrive naked. It carries the actual test cases linked to that ticket, not a boilerplate checklist everyone ticks without reading, but the specific scenarios QA expects to pass, each one a gate before merge. When the code or the specs change, the Playwright page objects and regression suites regenerate to match. Before a release, an agent reads every ticket and PR in the version, maps the affected areas, and produces the regression plan a QA lead used to spend days assembling by hand.

And the fidelity gates from the build phase never left. Missing elements, broken assets, responsive widths, locale slips: measured checks wired into the pipeline, so a change can’t be “done” until it passes. Humans review exceptions. A named human reviews every merge. That’s the whole loop: automated QA, automated triage, ticket creation, code written right to the PR, with judgment concentrated exactly where it belongs.

Nothing in that paragraph is a roadmap. It’s running.

Why this kills the retainer

Every SI knows what a support retainer really is. Most enterprise retailers pay somewhere between $40K and $250K a month for “managed services,” and the work being done for that money is mostly staff augmentation. Tickets in, tickets out. A rotating cast of mid-level engineers keeping the lights on, and a senior architect on retainer for the weekly steering call. 64labs has always tried to stay out of this mosh pit.  We have always believed most clients could and should manage their own site. But while we hear retailers grumble about the cost of managed services, they have never seen a viable alternative beyond hiring a team for themselves and that carries its own risks. So the structure survived as a kind of IT Stockholm Syndrome. 

To be clear, this model was never about technical capability. It was about technical recruiting capability. Retailers can’t hire, manage, and retain the engineers required to run a commerce stack, so the SI fills the gap. You were never buying engineering. You were buying access to engineering. Managed services is a cleverly disguised arbitrage.

Watch the loops I described above run for a week and the math of that arbitrage collapses. The tasks that filled the staff-aug queue (bug triage, config changes, test maintenance, integration glue, analytics tagging, minor UI upgrades) are exactly the tasks agents now eat for breakfast. Scope that took eight to ten FTEs in 2024 is delivered by two or three people plus a properly orchestrated agent estate. And the smart retailer immediately asks the obvious question: if agents are doing the work, why am I paying a body-shop margin on bodies?

The billable-hours model doesn’t survive that question. Not five years from now. Now.

Managed agents: pooled, not embedded

So what replaces it? Our answer is a different unit of value entirely. Not managed services - managed agents.

Agents are not a thing you build once. Models improve, vendor stacks shift, platform APIs change. The agent you built in 2026 goes stale by 2027 unless someone maintains it, upgrades it, expands it. What a client buys in a managed-agents relationship is a guarantee: the estate of agents running their business is current, governed, and getting better, maintained by a small number of very good people who know their business and well-integrated into both client and partner technology teams.

Here’s the part that changes the economics. That estate doesn’t have to be rebuilt per client, and it doesn’t need a pod of 10 to operate. The skills our agents run on, the triage runbooks, the QA contracts, the spec-sync workflows, live in a central, shared infrastructure. Every agent session logs whether a skill worked as documented. Those logs cluster into retrospectives that open PRs against the skills themselves. A lesson learned on one client’s build ships to every client’s build. When the dust settles on launch, one person at 64labs can manage that shared infrastructure across the whole client base, making sure our best practices propagate to everyone, automatically.

Pooled infrastructure, centrally maintained, continuously self-improving. That’s why the cost reduction isn’t 20%. It’s a 50-80%. The headline fees will look small next to the old retainers. The capability behind them will be larger than anything the retainer ever bought. Your current partner is either adapting to a more demanding, lower-revenue world or going bankrupt. You should be eager to speed that outcome up one way or another.

Tough for the old boys. A leap for everyone else.

None of this is comfortable if your business depends on staff-aug volume. The firms whose commerce practices rest on post-launch managed services - and that’s most of them, giants and boutiques alike - are holding a book of business whose unit economics are about to look indefensible. The test any CIO should apply to a partner this year: are they trying to make themselves redundant, or indispensable? Tribal knowledge in their heads, agents on their infrastructure billed back to you: that’s the old model defending itself. Skills codified, agents shipped into your environment, knowledge transfer as an explicit obligation: that’s a partner you can do business with.

But for customers, this is not a story about loss. The amount of work an enterprise actually wants done is about to explode: the experimentation programs, personalization variants, taxonomy cleanups, and data passes nobody could ever justify at old prices. The cost per unit of work is collapsing, so the volume of commissioned work goes up, not down. The retailers who thrive will be the ones who either find the right managed-agents partner or are big enough to build the practice themselves: a small agent-operations team, a governed estate, and a partner measured on their team’s autonomous capability rather than monthly burn.

‍

64labs is a Salesforce Commerce Cloud partner and Storefront Next launch partner. If you’re paying a managed-services retainer and wondering what a managed-agents model would look like on your stack, ask us. We’ll show you the loop running on a real production site.

See's Candies is live on Storefront Next.

That makes it the first production storefront running on Salesforce's new composable framework, and the build behind it tells a more interesting story than the launch itself. 64labs started the migration before Salesforce had even finished the codebase, working alongside the platform team in real time while most partners were still waiting for GA.

The result: three production storefronts (Retail, Fundraising, and Volume Sales), over 1,800 pull requests, and a set of lessons about Storefront Next that don't exist anywhere in the documentation yet.

Three Sites

See's Candies isn't a single storefront. It runs three, each with its own checkout logic, promotional model, and operational workflow. Fundraising has a completely separate business rules engine. Volume Sales uses pricing structures that don't exist in standard B2C Commerce.

That complexity is what makes this build worth paying attention to. A single-storefront Storefront Next launch would prove the framework works. A three-storefront launch with this level of business logic proves it works at enterprise scale.

Dima Shevchuk, product owner on the project, said the multi-site architecture surfaced problems that a simpler build never would have. "Single MRT versus multiple MRT rendered some of the previously working redirects impossible," he explained. "When you have the same relative path for each site with different target URLs."

The Migration Path

Migrating from PWA Kit to Storefront Next isn't a full rewrite. The SFCC backend and API layer stay mostly the same. What changes is the frontend architecture: server-side rendering, React Server Components, a different routing model, different state management. For a team with composable SFCC experience, the learning curve is real but manageable. For a team without it, this is where projects tend to stall.

64labs had 12 PWA Kit builds in production before starting the See's migration. The code doesn't carry over one-to-one, but the architectural instincts do: where SCAPI behaves unpredictably under load, which patterns hold up long-term, and which ones become technical debt.

A significant portion of the 1,800+ pull requests went toward third-party integrations, the part of Storefront Next delivery that conference talks tend to skip over. DynamicYield for personalization, Bazaarvoice for reviews, Amplience for content management, Cybersource for payments, Experian for address validation, and OneTrust for consent. Every one of those had to be rebuilt for the new architecture.

Helen Martin, who oversaw delivery and integration strategy, said DynamicYield was manageable because the team had recently built it on PWA Kit. "We had a good line in the sand as to what we needed to build in SFN, so most of it was migratable," she said. "The challenge was the minor 20% of edge cases that only surface when you're using it in anger with a lot of UAT data coming through." The team built the integration with active consent from the start, so OneTrust was already handled before See's turned it on in production.

The Phased Rollout

See's didn't go live all at once. The team launched Fundraising first, then Volume Sales, then Retail.

Dima explained the reasoning: "FR and VS are low-traffic B2B sites, very simple, low risk. Retail is much more complex and more things can break. So we proved stability on FR and VS first."

Each storefront got its own go/no-go, its own regression pass, and its own production hardening cycle. The phased approach let the team validate the deployment pipeline, redirect strategy, and analytics parity on lower-risk sites before putting the highest-traffic storefront through a live cutover.

Where the Speed Came From

The most surprising insight from the build might be where the time savings actually came from.

When asked where the speed came from, Dima didn't point to the framework. His take was that Storefront Next itself mattered less than the AI harness and delivery workflows 64labs had built over the six months before the See's project kicked off. The tooling they walked in with on day one did more for velocity than the platform switch.

In other words, the framework is better, but the acceleration came from the operating model 64labs built around it: AI harnesses, task structures designed for LLMs, and delivery workflows that took roughly a year to develop. The framework provides the foundation. The workflow around it is what compresses the timeline.

What This Means Ahead of Dreamforce

Dreamforce 2026 kicks off September 15 in San Francisco, and Storefront Next will be one of the biggest talking points on the commerce side. Most SIs will be presenting their plans for the platform. 64labs will have already shipped it.

The See's build offers something that slides and roadmaps can't: proof that Storefront Next holds up when real enterprise complexity, real third-party integrations, and real revenue are on the line. Whether other partners can get there without the same head start is an open question, but the platform has cleared its first production test.

See's Candies is live. The framework works. And the most useful lessons from the build are the ones Salesforce couldn't have documented, because they only come from being first.

‍