I Gave Qwen a Store to Run — Then Took Away Its Ability to Pick a Number

Olamide Ashiru — Tue, 07 Jul 2026 06:31:17 +0000

An autonomous commerce agent where the merchant just approves. Built for the Global AI Hackathon with Qwen Cloud — *Track 4: Autopilot Agent.**

I ran one discount decision through Qwen across seven scenarios — different costs, different margins, different price ceilings, genuinely different economics in each.

It said 10%. Every single time.

Not wrong in a dramatic way — 10% is a fine, safe-sounding number. That's exactly the problem. A confidently generic answer, applied to seven situations that each needed a different one, is the kind of thing that quietly bleeds a real merchant while looking completely reasonable on screen.

I only know it said 10% every time because the version of the agent with brakes drove those same seven scenarios to a spread — 2.89%, 40%, 11.11%, 10%, 10%, 15%, and one action with no discount to clamp at all — a range from 2.89% to 40%, because the economics genuinely differed. Same model, same facts, run once through a live harness. The only difference was whether it was allowed to pick the number.

That gap — between what the model proposes and what it's allowed to do — is the whole thing I built. Elevate is an AI that designs a storefront from a logo, stocks and prices it from a folder of photos, and then runs it from live shopper behavior, with the merchant as the human-in-the-loop. But the lesson underneath it is smaller and more reusable than "AI runs a store":

Let the model decide what to do. Never let it invent the number. Put your guardrail on the number.

I ended up applying that rule three separate times, and every time it was the difference between a demo and something I'd hand real money to.

TL;DR

What it is: an autopilot commerce agent — Qwen builds the store, stocks it, prices it, watches it, and proposes actions; the merchant approves the exceptions.
What's novel: (1) a role-scoped swarm that proposes and a merchant who disposes; (2) a structural guard + 3-layer interceptor the agent literally cannot bypass; (3) a closed learning loop — every decision reads back real revenue, so it gets smarter per store.
The principle: the model decides what; deterministic code owns every number.
Stack: Qwen (qwen-vl-max + qwen-max) on Alibaba Cloud ECS + OSS. Two models, seven jobs, one learning loop.
Repo: https://github.com/Alpha-dev-001/elevate-hackathon

The principle, three times

Pricing. Resale inventory has no honest MSRP — web-search "the usual price" and you get $400 designer retail for a slide a local reseller sells for a fraction of that. A confidently-wrong price is worse than no price. So Qwen never picks the number: it anchors to a merchant-set baseline and nudges by the premium-ness it can actually see in the photo, clamped so a hallucinated figure can't reach the storefront. It decides how premium this looks. It does not decide what it costs.

Revenue estimates. Left to invent "how much will this promo make," Qwen answered the same trigger with $760, then $175, then $285 — confident and meaningless. So I took the number away. The estimate is now computed from real signals: the size of the anomaly it actually detected × the store's real average price × a tunable rate. Qwen decides there's an opportunity here. Arithmetic decides how big.

Discounts. This is where the brakes get physical. Before an action is even considered, a Layer-0 structural guard makes an illegal one unrepresentable — a negative discount, an over-100% discount, a zero price, a phantom product simply can't be constructed into an action. Whatever survives hits a three-layer interceptor neither the merchant nor Qwen can bypass:

Layer 1 — Brand Guard: Qwen-authored rules, checked client-side with zero latency, so a clashing color warns the instant you pick it — in Qwen's own words.
Layer 2 — Business Constraints: margin floors and discount ceilings, auto-clamped with a visible reason. In testing, a decision cycle proposed a 75% win-back; it was clamped to that store's 40% ceiling before it could reach a customer. Qwen's number, the merchant's limit.
Layer 3 — System Safety: anything that would sell below unit cost is hard-blocked. No clamp, no exception — refused.

The agent can propose freely precisely because the brakes are real and it can't touch them. That's what makes autopilot safe to hand real control.

[screenshot: the Layer-2 clamp — Qwen's 75% struck through, clamped to 40%, reason shown]

What it actually does (the fast version)

A logo becomes a store. One upload. qwen-vl-max reads it into structured brand DNA — colors, mood, industry cues — and qwen-max turns that into a full brand plus a LayoutDSL: a JSON description of the store's structure, not a template with the colors swapped. Forty logos give forty visually distinct storefronts. And because a model returning structure will hallucinate an invalid variant or eight sections where there should be two, the renderer never trusts raw output: it passes through type-coercion, structural normalization, and a deterministic brand-seeded fallback so that even a total Qwen failure yields a distinct, on-brand store. A broken storefront is impossible by construction.

[screenshot: three generated storefronts side by side — Burger Blitz (light, editorial), Xair (dark, structured), Owoyemi of Offa — same pipeline, no shared template]

A folder of photos becomes a catalog. Inventory doesn't arrive as a tidy spreadsheet — it arrives as 98 phone photos of branded footwear, names on nothing, prices nowhere. (I know because a real seller handed me exactly that.) qwen-vl-max reads every photo into a sellable name, colorways, brand-voice description, category, and a suggested price. It also stays honest about its own eyes: it once misread a "SUICOKE" strap as "Suicide," fully confident — which is exactly why low-confidence reads are drafted inactive and handed back for a human glance instead of going live. The agent does the 98× of tedious work; the human rules on the handful that matter.

Shopper behavior becomes action. Once live, events stream over WebSocket into Redis. A deterministic threshold watches for patterns — a cart-abandon surge, a velocity spike — and Qwen also proactively checks pricing, scarcity, and catalog health on a schedule. When something crosses, it doesn't hand the whole problem to one do-everything prompt. It routes to one of four role-scoped specialists — a Pricing Strategist, a Sales Rep, a Store Curator, an Inventory Overseer — each holding only its own tools, each able to escalate to another when the real fix is outside its lane. That specialist runs a decision cycle, and before it decides, it reads its own memory: every past action for this store and whether it drove revenue. It even carries a quantified learned stance — "kept offers averaged 9% off, dismissed ones 35%, so lead nearer 9%" — so its proposals converge on what this specific merchant actually approves.

It returns one option card: the play, the trigger, the (computed) estimated revenue, a confidence score, a brand-safety check. Then it stops. The merchant taps Approve, and the storefront morphs, live. Qwen proposes; the merchant disposes; nothing happens behind the owner's back.

[screenshot: an option card in the merchant terminal — play, trigger, estimated revenue, confidence, brand check]

And the loop closes. When a promo resolves, a background observer counts the orders attributed to it and writes a memory entry the next decision reads. In a live run on the demo store, a cart-abandon surge → an approved win-back → a shopper checking out under it attributed $74.70 to that one decision — revenue moving $150.50 → $225.20, the platform's 10% fee ($7.47) computed against it — measured on the exact path a merchant would watch, not asserted by the model.

The bugs all lived in the seams

Every hard bug had the same shape: each component was individually correct, individually tested — and nothing connected them.

The one that still bothers me: our flagship dynamic-pricing feature — the one that reprices a product from its own sales history, earns trust, and eventually auto-applies — had never once executed in the live system. The reasoning, the reversion logic, the trust graduation: all written, all unit-tested, all green. But the daily job that rolls raw behavior into the price-history table was never wired into any background loop. So that table sat at zero rows forever, and the eligibility check that reads it was therefore always false. An entire headline feature, dead behind a passing test suite — surfaced only by querying the live database and asking "why are there no history rows?"

Its twin: the attribution dashboard — the closing beat of the whole pitch, "this action drove $X" — was quietly reading $0, because it joined orders on a promo's human-readable label instead of its id. That silent mismatch didn't just zero the number; it fed the memory loop false "no conversions," teaching Qwen its working actions had failed.

Same lesson twice: the happy path is not the interesting path. A feature isn't done when its logic passes tests — it's done when something on the live path actually calls it. The most dangerous failures don't throw. They quietly report zero. (I added a live end-to-end test that seeds a real purchase and proves the feature flips on — because "unit-tested" is exactly what lied to me.)

Does it pencil out?

Both were design constraints, not afterthoughts. Building a full store — logo read, brand, icons, ~90-product catalog — costs on the order of a few cents in tokens, once, then it's cached forever. After launch Qwen doesn't busy-poll; it fires on a real anomaly or a bounded scheduled check, and sends a telemetry diff, not the whole state. A decision cycle lands in seconds. Cost scales with the events that matter, not the hours the store is open — the only way "an agent per merchant" is economically sane.

Deployment: FastAPI, Postgres, and Redis as Docker containers on a single Alibaba Cloud ECS instance, with Alibaba OSS for logo storage and Qwen Cloud for every model call.

The feature I built, then deliberately took away from the model

I built graduated autonomy first: a trust streak where, once a product's small, already-safe price moves had been approved enough times, the model could apply the next one without a tap. It felt like the natural endpoint of a learning agent — earn your way to acting alone.

Two things killed it. First, at final review I found the streak was structurally dead — built, tested, and never actually firing, the second feature I caught passing its checks while doing nothing (the seams strike again). But fixing the bug is what made me question the whole idea. Because the real problem wasn't the bug. It was the premise: why is the model the thing that earns the right to act unattended?

That's the same mistake as letting it pick the number, one level up. An agent grading its own trustworthiness and then promoting itself is exactly the blind spot you don't want — the human's rubber-stamp quietly becomes consent they never actively gave.

So autonomy is now opt-in, per product. The model never grants itself authority. The merchant flips a switch on a specific product — "you handle this one" — and hands over a scoped sample, revocably, when they decide Elevate has earned it. The model still learns, still proposes, still gets sharper per store. It just never promotes itself. That's the actual goal of the whole system: not an AI that seizes control by clearing a threshold, but one a merchant can safely delegate to, one product at a time, so they can go run the parts of the business that need a human.

Which turns out to be the same principle as everything else here, applied to power instead of price: let the model decide what to do. Never let it decide the number — or how much authority it has. Everything trustworthy in Elevate came from that one line.

Code: https://github.com/Alpha-dev-001/elevate-hackathon — MIT licensed. Built for the Global AI Hackathon Series with Qwen Cloud, Track 4: Autopilot Agent.