When the AI Becomes the Storefront, You Decay Into a Supplier: The Relationship Moat for 10 Million Merchants

Second piece in the series WeChat's AI Entry: Rebuilding the Merchant Agent. The first asks how to get found — AI Picked the First Store and the Other Four Vanished. The third is the engineering blueprint for how to rebuild — The Day WeChat's AI Ordered for Users, 10 Million Merchants' Mini-Programs Expired. This one sits in the middle and asks the longer-horizon question everyone skips: once the AI is the storefront, do you still know your own customers. Context in one line: WeChat's AI can search, order, and pay for a user right inside a chat; at nearly the same moment Qwen opened a brand agent, with Luckin, KFC, and Mixue in the first batch. Two routes, one question — who owns the customer. 中文版:AI 当了门面,你就慢慢变成了供货商.
1. The moment the order closes, is the customer the AI's or yours
Start with the most ordinary scene there is. A user types "one low-sugar latte" into a WeChat chat box, the AI finds your store, places the order, fires WeChat Pay, payment clears, and a coffee gets made and handed over in your shop.
Business done. Except in that entire transaction, the user never opened your mini-program, never saw your brand page, never touched your membership system. What they faced was "WeChat's chat box." In the whole experience, all that's left of you might be the coffee itself.
Let's put the conclusion on the table first: once the AI becomes the storefront, "closing the sale" and "owning the customer" split into two separate things for the first time — and you can nail the first while losing the second.
In the old world those two were welded together. A user who wanted coffee had to download your app or open your mini-program, register, authorize, join the membership, grab a coupon, place the order. When the transaction finished, your entry point sat in their phone and their profile sat in your database. Next time they wanted a repeat, you could still find them.
In the new world that chain snaps. The moment the order closes is a fork —
One sale, two destinations: on the default path, user identity, repurchase, and data all settle on the platform side and you're left holding a single order; on the stitched-back path, you write this behavior into your own membership system. The fork isn't at payment — it's whether you designed this step at all.By default, when the AI completes the transaction for the user, their identity, behavior, and repurchase intent all settle in the place nearest the entry point — the platform side. What you get is an isolated order, not a customer you can reach again. This isn't a conspiracy; it's architectural gravity: data always sinks to the layer closest to the user.
2. "WeChat is where countless products' lives end" is a warning, not praise
There's a line that gets passed around a lot: "WeChat has 1.4 billion users. Its starting point is the endpoint of countless products' lives."
Plenty of people read that as a tribute to WeChat's ecosystem power. Having built membership and growth alongside merchants for years — across deployments serving 50+ product domains — I'd rather read it as a warning.
The sharpest case I've seen: a chain brand funneled nearly all of its new customers into one large platform's entry for three years. The GMV looked great. Then one day the platform retuned its recommendation weights, the brand wanted to push a win-back message to its old customers, and discovered it didn't hold a single direct channel to reach them — the phone numbers, the WeChat contacts, the repurchase records all lived on the platform side. It wasn't short of customers. It had never actually owned its customers. That's the truest picture of "supplier-ization."
Conclusion first: the stronger a super app gets, the easier it is for the merchants plugged into it to be ground down into "suppliers" — you handle supply and fulfillment, it holds the users and the relationship.
Watch how the slide actually slides:
- Step one: you integrate for those 1.4 billion users. Perfectly reasonable.
- Step two: users get used to talking to the AI in the chat box and stop opening your mini-program — your direct touchpoints thin out.
- Step three: the AI becomes the only interface between you and the user, and membership, coupons, repurchase reminders all run through its pipe.
- Step four: one day the platform changes the rules, props up its own first-party business, or swaps you for another "supplier" — and you don't have a single road left to notify your old customers directly.
This isn't scaremongering. It's the script that plays over and over in platform economics. You think you integrated a traffic entry; you may actually be outsourcing your customer relationship one sliver at a time. When a vendor brags "integrate the super app, cash in on 1.4 billion users," finish the sentence in your head: the traffic is rented, and the lease is in their hands.
So what — don't integrate, hand the 1.4 billion users away? Of course not. The answer is: take the traffic, keep the relationship. And there happens to be a live template for exactly that.
3. Qwen leaves brands a door: the brand agent
Almost simultaneously with WeChat's AI beta, Qwen opened a brand agent — Luckin, KFC, and Mixue were in the first batch.
It has one crucial difference from "the platform orders for you": a brand agent lets the brand keep its own set of things inside the super app's entry —
- Plug in its own membership system (you order in chat, but it still runs on your original member account, points, and tiers);
- Push its own personalized offers (based on the brand's own user profile, not the platform's);
- Own its own multi-turn dialogue (repurchase reminders, new-product pitches, campaign notices, all on the brand's own operating logic).
Read the meaning of that door: it proves "keep a direct user relationship inside a super app" isn't a fantasy — it's a capability the platform is willing to open, and one that top brands are already using. Luckin isn't naive. Its own membership base, running into the hundreds of millions, plus its "9.9 for two cups over three days" private-domain playbook, is the lifeline behind its growth. It integrated with Qwen — but it will not hand that relationship over. It wants the new entry's traffic; it defends the roots of its own membership.
Flip it around: a brand that hasn't thought this through and simply hands the whole transaction to the platform proxy integrates in a way that looks identical but ends up opposite — the traffic arrives, the customers leave. The difference lives in whether that unremarkable "relationship layer" got designed into the integration plan.
That's the comparison this piece most wants you to remember: the same sentence, "we integrated the AI entry," ends up as a brand agent for one company (relationship in your hands) and as pure proxy for another (relationship in the platform's hands). The gap isn't whether you integrated — it's whether the architecture left a seat for the relationship layer.
4. WeChat is "read-only, no writes" for now — but the reserved hook tells you the direction
Someone will say: WeChat isn't Qwen. WeChat's AI runs on a "read-only, no writes" principle right now — the AI reads, browses, and initiates, but doesn't perform write operations for you, and hasn't opened a deep relationship interface like the brand agent. So what's the rush on the relationship question?
Rush. Because "read-only, no writes" is temporary.
A reviewer with beta access dug up a detail: WeChat has a "one-sentence mini-tool generation" capability, and that mini-tool reuses the very logic and architecture of mini-programs — his read is that this hook "is clearly reserved for future distribution."
Put those two facts side by side: WeChat is restrained today (read-only, no writes), but architecturally it has already left a hook for "doing more for you tomorrow." Qwen has already walked the "brand keeps the relationship" path through to the end. WeChat has no reason to sit at read-only forever.
Don't mistake today's restraint for a permanent promise — read-only is today's state, not tomorrow's boundary. The "no writes" you see now is very likely an opening that just hasn't hit its moment. The day WeChat truly opens write permissions and a brand agent, the merchants who already built a relationship layer can plug straight in; the ones who didn't have to build from the naked state, from scratch. Start then and you're already a full length behind your rivals.
So this section's action is plain: while it's still read-only, no writes, before the scramble starts, do the "physical move" of building the relationship layer into your architecture now. The next section is how.
5. Stitch membership back to yourself: the real use of dev mode
In the third piece, on rebuilding, I keep hammering that dev mode's "atomic interface" is where you defend the truth of the transaction (price, inventory, payment all validated at that layer). This section adds its other, longer-horizon use — do an identity stitch inside the atomic interface.
The logic is simple. Every transaction the AI brings you eventually lands on your server to create an order. At that exact moment, use the openid you receive to look up your own member ID, and write this behavior back into your own membership system and CRM. Not a single hard line:
// In the order atomic interface, do an identity stitch after the sale closes (illustrative)
async function createOrderForAI(ctx, { drinkId, specs }) {
const member = await resolveMember(ctx.openid) // openid → your own member ID
const order = await createOrder({
memberId: member.id, // order hangs under your membership, not the platform's
drinkId, specs,
})
await crm.track(member.id, 'order_via_ai', order.id) // repurchase data flows back to your own CRM
return toOrderCard(order)
}
Those two lines — resolveMember(ctx.openid) and crm.track(...) — are the physical move by which you hold your customer relationship in the AI era. With them, the platform takes the traffic and you keep the relationship; without them, the sale finishes and the user belongs to WeChat, not to you.
This also answers "is auto mode enough" — for any path that touches the relationship, auto mode isn't enough. Auto mode lets the platform read your pages and operate for the user; nowhere in that flow do you get to insert an "identity stitch." To hang membership back on yourself, you go to dev mode and do it inside the atomic interface you wrote. That's the reason dev mode is worth the investment beyond just "getting the job done right."
6. The 3 boundaries to hold + the questions to ask the platform
Turn the judgments above into something you can tape to the wall. When you integrate the AI entry, not one of these 3 boundaries can slip —
The three to defend — member identity, repurchase data, user profile — all sit on your side; the platform only handles traffic and transactions. Hold these three, and no matter how the AI plays storefront, the customer's roots stay with you.- Member identity must resolve to your own account system. Every AI-triggered transaction should use
openid / unionidto look up your own member ID, and the order hangs under your member. Detection signal: if you can't answer "who is this order's user in my membership database," the boundary is already broken. - Repurchase data must flow back to your CRM. What the user bought, how often they buy, which specs they prefer — that behavior gets written back to your own database, not left only in the platform's transaction log. Detection signal: if your repurchase reminders can only be pushed through the platform's pipe, you no longer hold repurchase.
- The user profile must be built on your side. The basis for personalized recommendations and precise offers has to be your own profile, not tags rented from the platform. Detection signal: if pushing a coupon to old customers means "applying to the platform for an audience segment," profile sovereignty isn't in your hands.
Then take away 3 questions you can put to the platform / vendor next week —
- "When this sale closes, do membership and repurchase data enter my CRM, or stop on the platform side?" "On the platform side" → you're paying to integrate and fattening someone else's data asset.
- "For an AI-triggered transaction, can I get a stable user identifier to stitch to my own membership?" No clear answer → don't rush the launch; an integration where the relationship can't be stitched back is working for the platform.
- "When the platform opens write permissions / a brand agent, can my current architecture plug straight in?" "You'd have to rebuild" → break the relationship layer out into its own module now, don't build from zero on that day.
Question one is really asking whether you'll still have your own customers three years from now. The AI can be the storefront, but the customer's roots have to grow in your soil.
After this piece
If you want the "customer-ownership fork + two-route comparison + 3-boundary self-check + 3-question card" dropped straight into your next membership / strategy meeting — instead of re-reading this each time — I put together a PDF kit for readers who made it this far. Send me the keyword "MOAT KIT" and I'll send the pack:
- Customer-ownership fork (one page on where the customer goes the moment the sale closes)
- Two-route comparison (platform proxy vs brand agent, ownership at a glance)
- 3-boundary self-check (membership / repurchase / profile, tick whether each is held)
- 3-question card (for the membership / CRM meeting: answered / shifty / blank, three colors)
The next piece — the hardest in the series — is how to actually rebuild this thing: the full engineering blueprint of layered architecture, state machine, atomic interface, and relationship stitching.
(Channels are in the footer — X or email both work.)
Subscribe for updates
Get the latest AI engineering posts delivered to your inbox.


