Loomerce — An Unattended AI Team That Runs Your E-Commerce
A 10-role agent team autonomously handles sourcing, copy, publishing, support and retros; the human does exactly two things: monitor and authorize. Guardrails cannot be bypassed; memory compounds across cycles.
Chinese e-commerce platforms (Xiaohongshu, Douyin, Pinduoduo, Taobao) offer no complete public APIs, so daily operations are a high-frequency human loop: source products, write copy, publish, answer customers, read dashboards, retro — repeat. With Loomerce I wanted to test a wilder question: can the org chart of an e-commerce company be written directly as code?
Writing the company as code
Loomerce is a 10-role agent team where even model allocation follows "seniority": the CEO and the self-reflection role get the strongest model for strategic judgment; market research, sourcing, and content creation get a mid-tier model; publishing, customer service, and operations — high-frequency, light-decision posts — get the fastest, cheapest one. The company's meeting cadence is code, too:
| Routine | Role | Cycle |
|---|---|---|
| Strategy review | CEO | Every 24h |
| Market scan | Market research | Every 12h |
| KPI analysis | Analytics | Every 6h |
| Guardrail patrol | CEO | Every 2h |
| Self-reflection | Self-reflection | Every 48h |
Self-reflection is the organization's growth mechanism: every 48 hours it reads the last 60 events, the latest KPI snapshot, and the previous reflection, then distills highlights, lessons, and next-cycle experiment hypotheses. The top five lessons are written into long-term memory — and every agent's system prompt automatically carries them in the next cycle. Organizational memory lives in the database, not in word of mouth.
Trust is designed, not declared
"Unattended" only works if a human can relax while not attending. Loomerce earns that through three non-bypassable layers:
- **Guardrails are exceptions, not suggestions.» Price-multiplier caps, mandatory approval for a shop's first listing, banned words in content (the seed shop bans "medical-grade" and "clearance-sale" style claims) — a guardrail violation throws a special exception that the scheduler never retries; the task is terminated. Ordinary failures get exponential backoff; guardrail violations get a full stop. Two different roads.
- Two autonomy levels, trust escalating gradually. Supervised mode approves item by item; full mode runs autonomously. Crucially, an approval is an independent entity rather than an appendage of a task — a modeling decision that quietly prevents a real class of bug: task retries re-issuing duplicate approval requests.
- One path only. Every listing, pricing, and publishing action has exactly one road — through a handler — and the guardrail checks are buried in that road. Code that writes to the database around the handlers does not exist in this repo.
Understand offline, perform online
My favorite design is the PlatformAdapter layer: with zero API keys configured, the whole system runs on a mock engine — in-memory virtual listings, orders that materialize with 25% probability per poll, fluctuating metrics — while the task queue, guardrails, approval flow, and KPI aggregation all run for real. The seed shop ships ready to run, brand voice included ("gentle, unintrusive, like a friend who gets you").
Once you understand it and trust it, drop platform cookies at the configured path, isLive() flips, and the same logic takes over a real shop.
Evaluating an autonomous system should never require gambling a real store on it. That is the entire meaning of "understand offline, perform online."