Managed Agents, Not Managed Services

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.