The Day WeChat's AI Ordered for Users, 10 Million Merchants' Mini-Programs Expired — A Layered Rebuild Blueprint

Yaqin Hei·June 24, 2026·30 min read

Agentic AI WeChat Mini-Program Agent Architecture Enterprise AI

The Day WeChat's AI Ordered for Users, 10 Million Merchants' Mini-Programs Expired — A Layered Rebuild Blueprint

Third and hardest piece in the series WeChat's AI Entry: Rebuilding the Merchant Agent. The first two asked "how do you get found" (the traffic black box) and "how do you keep your customers" (the relationship fight); this one answers a single question — how, exactly, do you rebuild your mini-program. Context in one line: WeChat's AI agent is in beta, lives in the top-left corner, can be triggered inside chats, articles, Channels videos, and mini-programs, and can search, compare, order, and pay across ~10 million merchants. The capability is still under compliance review and the integration contract isn't frozen — so this post teaches you to design by MODE, not to bet on a specific API. Earlier in the series: AI Picked the First Store and the Other Four Vanished and Once the AI Is Your Storefront, Do You Still Know Your Customers. 中文版：微信 AI 替用户下单那天，1000 万商户的小程序集体过期了.

Opening: The team that copied its pages into the chat, then rebuilt from scratch three weeks later

Doing retail agent work over the years — 50-plus product domains, Fortune 500-scale clients — the most expensive mistake I've watched is this one. A team heard WeChat was opening up AI access, and overnight they took their existing mini-program's page flow and copied it into the chat window, one button at a time.

The product-list page became a "product-list card." The spec-selection page became a "spec card." The address page became an "address card." They thought that was what "integrating an Agent" meant.

It fell over the day it launched. The user said "get me a low-sugar latte," and the AI had no idea which card to call — because these cards were organized by page, not by what the user was trying to do. What the AI faced was a pile of "page replicas," not "tasks I can complete for you." Three weeks later the whole skill was torn down and rebuilt.

That's the first-principles problem of the rebuild, and it's what this post takes apart. What WeChat opened up here isn't a chat box bolted onto your mini-program — it's a forced upgrade of the mini-program from "a set of pages a human taps through" into "a set of service capabilities an AI can understand, call, and operate." Almost no line of architecture is shared between the two.

Look at what happened when the reviewer with beta access ran a live test: he asked the agent to book a movie ticket, and "it listed 5 mini-programs, picked the first one — Maoyan — drove it all the way to the theater-selection step, and handed the rest to me."

Read that sentence carefully: the AI picked the first one for the user, and the other 4 merchants ceased to exist in that transaction on the spot. And the one that got picked still has to guarantee that when the AI operates its mini-program, it won't stall halfway, won't place the wrong order, won't miscompute the price. How well you rebuild directly decides whether you're "the first one" or "the vanished four."

Here's the full layered rebuild map. Every section below dissects one layer.

The rebuild map: the old world is a stack of pages on the left, the new world is a layer of "AI-callable capabilities" on the right. Note the dashed line at the bottom — the relationship layer (membership / repeat purchase / data) must be pulled out on its own. Don't let the platform carry it off along with the payment loop.

1. Don't copy pages into the chat — reverse-engineer the SKILL from the user's goal

Let's put the conclusion on the table first: the starting point of the rebuild isn't your pages, it's a single sentence from the user.

The old mini-program's unit of organization is the "page." The new agent's unit is "one task the user can complete." In WeChat's dev mode this task bundle is called a SKILL — a business-capability package the AI can call. One SKILL maps to one task with a clear "done" definition: complete an order, successfully pull a queue number, add a to-do and show the list.

How do you carve out SKILLs? Backwards. First list how the user will open their mouth:

"Get me a low-sugar latte" → ordering SKILL
"What's good to eat near me" → fuzzy recommendation → still lands on an ordering / find-a-store SKILL
"Where's my order" → order-lookup SKILL
"Book me a teeth cleaning for Saturday" → appointment SKILL

Behind each sentence is a task with a definite endpoint, not a page. There's exactly one iron rule for carving SKILLs: if you can't describe what the moment of "done" looks like for this SKILL, it shouldn't be a SKILL. A "product-list SKILL" doesn't hold up, because the list itself isn't the user's endpoint; "complete payment and place the order" holds up, because it has a definite success state.

More SKILLs isn't better. In the official skill docs the reviewer dug up, triggering is scoped by scenario — local-life ordering, ride-hailing, movie tickets, lookups, top-ups, one class each — not shattered into dozens by page. Too fine and the AI can't pick; too coarse and one SKILL tries to do everything, with parameters and state all mushed together. Cutting at "one thing the user can independently complete" is the most stable granularity right now.

Here's a counterintuitive point worth stating: the rebuild isn't rewriting the mini-program — it's adding a layer of "capability declarations written for the AI to read" on top of your existing business backend. Your product, inventory, order, and payment services don't change a single line; what's new is the SKILL + interface declarations + card components layered above. Get that clear and half your team's panic evaporates.

2. Scout with auto mode, get results with dev mode — don't rewrite on day one

Conclusion first: 90% of mini-programs should first use auto mode to validate "can I even be discovered by the AI," then decide which high-value path is worth dev mode.

WeChat gives two integration modes, and many teams' first instinct is "obviously go straight to the most powerful dev mode" — that's the second-most-expensive mistake. The tradeoff between the two modes looks like this:

Scout with auto mode, get results with dev mode. There's only one dividing line for the call: does this path touch money, orders, or privacy — if it does, it's worth dev mode's strong constraints.

Auto mode: you authorize the platform to read your mini-program source at review time, it analyzes your page structure and interaction paths, and lets the AI operate your existing pages directly. The value is fast integration, near-zero dev — good for first answering a life-or-death question: "can my service be discovered, searched, and browsed by the AI." Content-type, lookup-type, light-service mini-programs may find auto mode is enough.

Dev mode: you package your business capability into a standardized SKILL, explicitly declaring interfaces, parameters, outputs, components, and business rules, so the AI calls it with more certainty. It needs dev, debugging, evaluation, and review, but buys strong constraints — fit for ordering, payment, appointments, queue numbers, after-sales, the multi-step, strongly-consistent transaction loops.

For the rollout rhythm I'd recommend four phases — don't skip:

Inventory and prioritize — list your mini-program's high-frequency services and sort them by "user value × risk × rework cost."
Auto-mode trial integration — open low-risk pages, watch one metric: can the AI correctly discover and operate your core path.
Dev-mode show unit — pick one closed-loop scenario (ordering / queue number / to-do) and build the SKILL end to end: interfaces, cards, half-screen page, payment. Just one.
Evaluate, canary, expand — accumulate an eval set and monitoring, then gradually roll out more scenarios.

Why insist on "scout first"? Because the contract isn't frozen. WeChat is in beta now — the API, review standards, entry naming, and rollout cadence may all change. All-in-ing your engineering budget on a dev-mode rewrite at this stage is betting on an interface that's still moving. Auto-mode scouting is cheap enough to buy as an option — small money to lock down the "found" slot now, then decide where's worth reinvesting once the contract stabilizes.

3. Never trust a single parameter the AI generates

This is the most important section in the whole post, and the one beginners are most likely to skip: any parameter the AI hands you — product ID, price, spec, quantity — the server must treat as "input from an untrusted client" and re-validate from scratch.

Why? Because a transaction isn't "tapping a button," it's a state machine: pick item → pick spec → generate order → add address → confirm payment → payment status callback. Every step has a precondition, and at every step the AI might fill in the wrong value or simply fabricate one.

Lock the AI's freedom into a state machine: hang a server-side validation gate on every transition arrow. The AI can only run on the track you drew — it can't run off it.

The most dangerous ways this goes wrong, and their fallback strategies, I've collected into one table — you can paste it straight into your team's design review:

Risk scenario	How it happens	Fallback strategy
AI fabricates product / order ID	There's no ID in the natural language, so to make the call go through the AI "guesses" one out of thin air	Only allow IDs returned by an upstream interface; if context is missing, ask back — never let it through
Price gets altered	The AI or a component passes price up as a parameter, and passes a wrong / stale one	Price is always recomputed server-side by product, spec, and promotion; the price passed up is used only for display comparison
Duplicate payment	The AI triggers payOrder twice for the same order	Order idempotency key + serialized payOrder + server state machine; reject a second attempt on an already-paid order
Privilege escalation	The AI uses user A's session to query user B's order	Backend verifies resource ownership via openid / unionid / your account system; never trust the identity the client passes
"Fake success" from the interface	The interface failed, but the AI narrates it as "I've placed your order for you"	The interface must return a structured isError + error code + recoverable action; the AI is forbidden from inventing success on its own

One sentence is enough to remember: the AI handles understanding intent and orchestration; the server guards the truth. Price, inventory, identity, order ownership, payment status, idempotency — these six are always server-authoritative. The moment that line loosens, the fraud rings line up the next day.

4. mcp.json is your contract with the AI

In dev mode the AI doesn't call your interfaces on vibes — it reads two files to decide how to call them:

SKILL.md — the business SOP. It tells the AI this scenario's flow, interface dependencies, forbidden actions, how to handle ambiguity, how to route intent.
mcp.json — the capability declaration. It defines each API's name, description, input/output Schema, which component it binds to, which page it's associated with.

These two files are the contract between you and the AI. Write the contract vaguely and the AI freelances; write it airtight and the AI walks obediently inside the frame. Here's a real confirmSku declaration (structure from WeChat's official sample project WeStoreCafe, details adapted to your business):

{
  "apis": [{
    "name": "confirmSku",
    "description": "Confirm spec and generate the order; must be called after selectDrink succeeds.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "drinkId": {
          "type": "number",
          "description": "From selectDrink's return value; fabrication forbidden"
        },
        "specs": {
          "type": "object",
          "description": "Spec values must use the enum value; natural language not accepted"
        }
      },
      "required": ["drinkId", "specs"]
    },
    "_meta": {
      "ui": { "componentPath": "components/order-confirm-card/index" }
    }
  }]
}

Look at those two description lines — "must come from selectDrink's return value, fabrication forbidden" and "spec values must use the enum value, natural language not accepted." That's not a comment, that's a constraint. There's exactly one rule of thumb for writing mcp.json: write everything "the AI shouldn't guess" into the description and Schema; write "the steps that must happen first" into SKILL.md's cross-interface iron rules. Every line you leave out of a description is one more guess the AI makes, and one more way to crash in production.

That "scout with 90% first" call from section 2 takes concrete shape here — what's genuinely expensive about dev mode isn't writing the interfaces, it's thinking through, writing down, and testing all these constraints.

5. Atomic APIs + atomic components: keep the AI on the track you allow

Once the contract is signed, it lands in code as two things:

Atomic APIs — the functions that actually execute the query, order, save, payment, status refresh. All the trusted logic lives here.
Atomic components — the cards that display an interface's result, and can go on to trigger a follow-up upstream message or interface call. A component only does "display + trigger" — it carries no trusted logic.

Interface registration looks roughly like this:

// skills/drink-skill/index.js (illustrative, not the final API details)
const skill = wx.modelContext.createSkill('skills/drink-skill')

skill.registerAPI('searchDrinks', searchDrinks)
skill.registerAPI('selectDrink',  selectDrink)
skill.registerAPI('confirmSku',   confirmSku)
skill.registerAPI('payOrder',     payOrder)

module.exports = skill

Inside each atomic API, four things must happen: validate parameters, return an error code, call the business service, and emit structured output. Miss one and the AI end loses a guardrail.

The key is "preconditions." When each interface is allowed to be called, and when it's strictly forbidden, must be hardcoded. This interface-responsibility table is the code projection of the state machine above —

Interface	Responsibility	Precondition	Display component	Key risk
getRecommendedDrinks	Recommend on fuzzy intent	User gave no specific product name	Recommendation card	Don't flood the chat stream with recommendations as plain text
searchDrinks	Search by keyword	User gave a product name / category	Search-results card	Keyword must come from the user's own words, fabrication forbidden
selectDrink	Show detail and specs	An upstream drinkId already exists	Detail card	Can't guess drinkId from natural language
confirmSku	Confirm spec, generate order	Already ran selectDrink	Order-confirm card	Spec enum, price, inventory all must be validated
payOrder	Initiate payment, return result	Order is confirmed	Payment-result card	User confirmation required before payment; status is server-authoritative

Note the "user confirmation required before payment" on the payOrder row. This is a red line WeChat drew, and it's the extension of the "read-only, don't act" beta principle into the transaction scenario — irreversible actions like payment, order submission, and editing personal info must never be done silently by the AI on the user's behalf; there must be a user-visible, explicit confirmation. Don't try to skip this step for the sake of "automation rate." If a vendor brags to you about "fully automated ordering, zero confirmation," that's not advanced — that's an incident.

The recommended directory structure, to give the team something concrete to land on:

miniprogram/
├── app.json              # declare agent.skills and the independent subpackage
├── pages/                # existing mini-program pages (untouched)
├── packageDetail/        # half-screen page / detail page / fallback page
└── skills/
    └── drink-skill/
        ├── SKILL.md      # business SOP, constraints, intent routing
        ├── mcp.json      # APIs, Schema, component binding
        ├── index.js      # register atomic APIs
        ├── apis/         # interface implementations (trusted logic)
        ├── components/   # card components (display + trigger only)
        ├── data/         # mock / constants / enums
        └── utils/        # auth, request, validation utilities

The pages/ line says "untouched" — one more time: this layer is added, not a teardown of the old mini-program.

6. Stitch the relationship layer back on: don't let the payment loop carry off your customers

The first five sections were all about "how to make the AI do the job right." This one is about something longer-term, and more easily overlooked — once the job's done, does the customer still recognize you.

That's the topic of the second piece, but it has one action that must land in the architecture, so it goes here. When the AI is the storefront, the user completes the order inside "WeChat's chat box," and your brand may be reduced to a single card in the whole experience. If you don't actively design for it, membership, repeat purchase, and user data will flow down the payment loop toward the platform, and you slowly degrade into a "supplier."

Qwen already set the precedent — its brand Agent let first-wave brands like Luckin, KFC, and Mixue keep their membership systems, personalized offers, and multi-turn dialogue on the brand's own side. WeChat is "read-only, don't act" for now, but the "generate a mini-tool from one sentence" opening the reviewer dug up — which reuses the mini-program's logic and architecture — is "obviously reserved for future distribution." Read-only is temporary; relationship ownership is permanent. Don't architect the relationship layer out now, and the day write permissions open, you're running naked.

Architecturally, how? At the atomic-API layer, do an identity stitch:

The stitch point is the atomic API: for every AI-triggered transaction, use openid / unionid to look up your own member ID, and write this behavior back into your own CRM. The platform takes the traffic; you keep the relationship.

// Inside the atomic API, do an identity stitch after a successful order (illustrative)
async function confirmSku(ctx, { drinkId, specs }) {
  const identity = await resolveMember(ctx.openid)   // openid → your own member ID
  const order = await createOrder({
    memberId: identity.memberId,                     // order hangs under your membership system
    drinkId, specs,
    price: await pricing.recompute(drinkId, specs),  // price recomputed server-side (see section 3)
  })
  await crm.track(identity.memberId, 'order_via_ai', order.id)  // repeat-purchase data flows back to you
  return toOrderCard(order)
}

Those two lines, resolveMember(ctx.openid) and crm.track(...), are the physical act of holding onto your customer relationship in the AI era. Without them, you finish this piece of business and the user belongs to WeChat, not to you.

7. The contract isn't frozen — design by mode, don't bet on an API

The last architectural principle is about the lifespan of this whole thing.

WeChat's AI is still under compliance review, and the public info says it plainly: during beta the API, review, eval standards, entry naming, and rollout cadence may all keep changing. Which means the code you hardcode today against some doc's wx.modelContext.createSkill may have a changed signature in the next version.

The response isn't "wait until it's stable" (that hands the first wave of traffic to someone else), it's adding a thin adapter layer between the volatile platform API and your stable business logic:

Your business logic (pricing, inventory, order, membership) — stable, and shouldn't know WeChat exists.
Capability declarations, interface registration, component binding — volatile, all funneled into the skills/ layer.
Separate them with your own defined interface contract. WeChat's API changes, you touch only the adapter layer, and the business backend doesn't change a line.

That's the engineering meaning of "design by mode, don't bet on an API." The mode is stable — understand intent → pick SKILL → fill params → server validation → component confirmation → status callback; this chain doesn't change no matter how WeChat renames things. The specific API is volatile — so cage it somewhere you can swap in one move.

One more thing: this abstraction isn't just defense against WeChat changing. Alipay, Douyin, Qwen — everyone is opening their own agent entry, each with a different contract. Get the capability-layer abstraction right and you're facing "multiple super-app entries," not "rewriting once per platform."

8. 10 things you can start this week

You don't need beta access, and you don't need the contract to freeze — your engineering team can do these 10 things this week —

List your existing mini-program's high-frequency services in a table, score and sort by "user value × risk × rework cost," and circle the top 3 paths worth dev mode.
Write one "user's own words" sentence for each candidate path — if you can't say how the user would open their mouth, leave it alone for now.
Write one "done definition" line for each candidate SKILL — can't state a success state means it's carved wrong; go back to step 1.
Turn on auto mode and pick 1 low-risk page for a trial integration, watching one metric only: can the AI correctly discover and complete your core path.
Pick 1 closed-loop scenario for a dev-mode show unit (ordering / queue number / to-do), don't overreach.
Draw the transaction path as a state machine, marking each transition arrow with its precondition and server-side validation items.
Write the first pass of mcp.json, asking yourself field by field "should the AI guess this" — write everything it shouldn't guess into the description and Schema.
Walk through the risk table in section 3, confirming that all five ways it crashes — price alteration, duplicate payment, privilege escalation, fabricated ID, fake success — have a server-side fallback.
Add an openid → member ID mapping + repeat-purchase flowback in the ordering atomic API, even if it's read-only-don't-act for now — architect the relationship layer out first.
Funnel platform API calls into the skills/ adapter layer, so no WeChat-proprietary call appears in the business backend.

Item 8 is the least conspicuous and the most lethal — it's the only wall between you and the fraud rings. Don't skip it.

9. 5 questions to ask your vendor

If you're talking with a vendor about "helping you integrate WeChat AI," ask these 5 straight in the next review. Anyone who can't answer or gets shifty — alarm bells:

"For the price the AI passes up, does your server recompute it?" If they answer "we trust what the AI passes" — price can be altered, and you're waiting to get skimmed.
"If the AI double-taps payment on the same order, how do you block it?" Can't produce an idempotency key + serialization — duplicate charges are coming.
"Is there explicit user confirmation before payment, or is it fully automatic?" Anyone bragging "fully automatic, zero confirmation" — violates the "read-only, don't act" red line, incidents guaranteed.
"WeChat changes an API signature in the next version — how much code do you have to touch?" If they answer "changes everywhere" — no adapter layer, and you're paralyzed the moment the platform twitches.
"When this order's done, does the membership and repeat-purchase data land in my CRM or stay on the platform?" If they answer "on WeChat's side" — you pay to integrate, and you're fattening someone else's herd.

Question 5 is really asking whether you still have your own customers three years from now.

10. Going deeper

The above is the engineering view — layering, state machine, contract, relationship stitch, adapter layer. This post deliberately left out the full SKILL.md writing conventions, the half-screen interaction details of atomic components, the cloud-development identity scheme, and how to construct the canary eval set — because those have to be written against WeChat Open Platform's latest docs, and the docs are still moving.

If you want to dig down yourself, three entry points:

WeChat Open Platform's "AI Capability" doc series — intro, integration, runtime mechanism, debugging, best practices, eval guide, design guide, FAQ. During beta, always defer to the latest version.
The official sample project wechat-miniprogram/ai-mode-demo — the WeStoreCafe ordering scenario, with skills/drink-skill, SKILL.md, mcp.json, atomic APIs and components. It's the most complete runnable reference right now.
Tencent CloudBase's integration articles — they add SKILL, atomic API, atomic component, and the cloud-development identity scheme (saving you the code2session / token / auth boilerplate).

The upper layer of this rebuild methodology — how to grade an Agent, how to design a Critic, how not to deploy-and-abandon after launch — is in my Agentic AI in Practice series. WeChat this time just pushed that methodology, for the first time, onto the entry point of 1.4 billion users.

After this piece

If you want to drop "the layered rebuild map + state-machine template + risk-fallback cheat sheet + the 10 things to do this week + the 5-question vendor card" straight into your next architecture review — instead of re-reading this every time — I put together a PDF kit for readers who made it this far. Send me the keyword "REBUILD KIT" and I'll send the pack:

WeChat AI mini-program layered rebuild map (printable, annotating each layer's responsibility + which layer is added on top)
Transaction state-machine template (pick-item → payment full chain + a server-side validation checklist for each step)
Risk-fallback cheat sheet (price alteration / duplicate payment / privilege escalation / fabricated ID / fake success, one counter each)
10-this-week checklist + 5-vendor-questions card (built for the review meeting — tick each red / yellow / green)