-
-
-
-
-
Supplier portal: a workshop submits from its own app, in its own currency, and the listing is drafted from its photos.
-
Shopper: the collection, a hallmarked piece, the style quiz, and the supplier application an agent reads.
-
The back office: what a model decides, what a rule decides, and which gates are armed in production right now.
-
The console: every agent and what it may do alone, the gates and their limits, and what ran today.
-
Every LLM-backed agent is the same six stages. The model sits in the middle, and it is the only stage allowed to fail.
-
The reflection loop we did not build, and the three mechanisms carrying that load: clamp, bounded critic, machine verification.
-
Nine gates, each bounding one irreversible act. An auto_mode flag exists in settings and no gate reads it: there is no master switch.
-
A crash becomes a pull request. CI gates it, a human merges it, and the deploy rolls itself back if the smoke test fails.
-
One Flutter codebase, one Cloud Run container, one database. The request path and every background agent share the same process.
Inspiration
Most of the jewelry made in Pakistan is sold through an Instagram account. A workshop posts a photo, answers DMs, quotes in rupees, and ships when someone in the same city asks. The pieces are good. The reach is a few hundred followers, the payment rail is a bank transfer between strangers, and a buyer abroad is simply out of the question and consumers have to follow 100s of instagram, tiktok accounts to find jewelry they want.
The obvious fix is a storefront that carries them — one brand, real checkout, worldwide delivery, and a maker who gets paid on agreed terms at a rate that does not move under them. The reason that shop does not already exist is that running it is ten jobs: writing listings, translating them, planning campaigns, chasing stock, vetting suppliers, judging cancellations, and fixing the app when it breaks. A platform big enough to carry small vendors hires a team for each — and those economics only work at a scale no new platform starts with.
So we asked the other question: what if the team is Gemini, and the human just approves the work? Then a shop can carry makers who would never have got onto one, because the cost of carrying them is a model call instead of a salary. We ran a real store on that answer.
What it does
Meshyay is a live single-brand jewelry company — web, Android and iOS, live Stripe checkout, real suppliers, a live order pipeline — whose back office is a roster of 15 AI agents, grouped by the job they do rather than by the model behind them. Every agent ships with a card stating what it decides and what it may do alone.
Order processing
- Orchestrator — the agent that owns the morning. Once a day it reads thirty days of sales against the shelf level, drafts restocks through the ordinary demand path so they meet the same gates an order-triggered one does, re-asks suppliers who went quiet, and writes the round down — especially when it ordered nothing, because an agent that only speaks when it acts trains nobody to trust its silences.
- Procurement — when a paid order can't be covered from stock, it drafts the reorder quantity, a ranked supplier shortlist, the wording of the request, and its own confidence. Suppliers quote in their own currency; Meshyay settles in USD at a rate locked the moment a move is agreed, so an agreed price is never silently re-quoted. It is the one agent allowed an outward action on its own.
- Cancellation adviser — only orders that already shipped reach it, so the question is never "is this allowed" but "is it worth stopping the parcel". It weighs fulfillment stage, order value, time since dispatch and the shopper's stated reason.
Catalog
- Catalog writer — reads a photo of a piece and drafts the catalog fields (title, price, material, category), then renders the result in every language the store sells in, cached at save time rather than translated on every read.
- Image guard — a photo is judged before it is stored on one question: is this a usable picture of jewelry? Refusals come back to the uploader in plain words.
- Style curation — the "shop by personality" quiz. Ranking across five axes (timeless/trend-led, understated/bold, silver/gold, delicate/statement, everyday/occasion) is arithmetic, so it behaves identically every run and cannot be talked into a recommendation. Gemini writes only the narrative.
Marketing — campaigns, first-contact prospects and next-purchase suggestions under a single agent, because they are one decision: who do we write to, and what do we say. Bounded autonomy is built and ships off.
People — one question asked at both doors: is this person real? A supplier applies with an application and social handles; a shopper answers by behaving like one, or by looking like twenty accounts made the same evening. It sorts and evidences. It approves and rejects nobody.
Support — a shopper support agent that is deliberately a state machine, not an LLM, so it cannot invent an order status; plus a jurisdiction-scoped legal assistant for the admin.
Coding — the part we didn't plan: agents that work on Meshyay itself. A coding agent takes a scoped instruction, changes the code, runs the tests and opens a pull request. A diagnosis agent turns both runtime crashes and human bug reports into instructions it can act on. A release agent runs the end-to-end suite, ships, proves it still works, and puts it back if it doesn't. A security agent reads the source and the config this deployment is actually running with, looking for the failures that lose customers and money rather than the ones that lose style points.
Shoppers get the storefront on top of all that: 6 languages including 3 right-to-left (Arabic, Urdu, Sindhi), a ring sizer, and Google Sign-In on every platform. A 360° turntable viewer and a photo-cutout try-on ship with it, both optional per piece: film one slow turn and the backend cuts it into the frames a shopper drags through, and a piece with a photo cutout gets the try-on button. A piece nobody filmed simply shows its photos.
How the agents are bounded
The roster above says what each agent decides. This is the part that matters more: what stops it.
Every LLM-backed agent is the same six stages. The model sits in the middle of them, and it is the only stage allowed to fail.

The model never reaches an effect directly. Stage four clamps its answer back to the facts stage two gathered — the restock agent drops any SKU its own stock review did not flag, and caps quantity at three times what the cover arithmetic suggested, so the model may re-rank and trim but cannot invent a piece to order or inflate a number. Stage five decides whether a human sees it first. Every verdict is written down, the declines included: a log of only the things that happened cannot answer "why didn't it reorder that piece", and the held rows are what tell an owner their thresholds are too tight.
Nine gates, and deliberately no master switch.

Each irreversible act has its own bounds, its own clamped setter and its own audit entry. An auto_mode record exists in settings and no gate reads it — a flag the gates consult is a flag that can bypass them. Before arming one, the admin can dry-run it: the proposed bounds are replayed against thirty days of real rows, and the console reports what would have gone out unattended, per gate, with the held rows grouped by the rule that held them. Two gates come back with nothing rather than a number, because they keep no per-decision record to replay — we would rather show a blank than a figure we invented.
The agent that writes code stops at the merge.

A crash becomes a diagnosis, the diagnosis has to clear a dispatch bar, and only then does a GitHub Actions workflow clone the repo, change the code, run the tests and open a pull request. CI gates the branch and a human merges it. After merge, the deploy smoke-tests the live service and rolls traffic back to the previous revision by itself if the smoke fails.
Does any of it self-reflect? No — and that was the choice.

No agent re-reads its own output, critiques it, or retries on its own judgement. Every run is a single model call: no verifier prompt, no confidence-triggered retry, no debate. Three things carry that load instead — a deterministic clamp on every model output; rules first with the model as a bounded critic, so the security scan's findings are plain code the model may explain and may talk down only when they are tentative guesses, never when they are firm; and machine verification where the action is reversible, which is the tests, the CI check and the smoke-and-rollback rather than the model grading itself. The trade is honest. Single-shot plus a clamp is deterministic, costs one call and cannot spiral, but it will not catch a plausible-and-wrong answer that stays inside the bounds. That class of error is caught by the gate, or by a human, and we would rather say so than claim a reflection loop we did not build.
How we built it

One Flutter codebase, one Cloud Run container, one database. The request path and every background agent share the same process — which is why what an agent may do alone had to become an explicit register in software rather than a deployment boundary.
- Frontend — Flutter, one codebase for web, Android and iOS, with go_router URL navigation and full RTL support.
- Backend — Python + FastAPI on Google Cloud Run, MongoDB, Stripe payments (live), Firebase.
- AI — Gemini 2.5 Flash via the Gemini API. Each agent is an isolated service with a strict validated output schema, so drafts render cleanly in the console and a bad generation fails loudly instead of quietly corrupting the catalog.
- Governance as code — each agent's card is a markdown file in the repo, served to the admin console. It versions with the code that implements it, so a behavior change and its description land in the same diff.
Challenges we ran into
- Too many agents is a bug. We reached 22 agent cards and the console stopped being readable — three cards often answered one question, which made one job look like three systems. Merging down from 22 was the highest-value change we made; runs and decisions still file under their original names.
- Where a coding agent can even run. Cloud Run is stateless, capped at 300s a request, with no checkout and min-instances 0 — so the backend dispatches a GitHub Actions workflow and the agent does its work there.
- Model churn. We started on gemini-1.5-flash and it was retired from the API (404s); 2.0-flash free-tier quotas were too unstable for production. Centralizing the model ID in config meant the fix was one line, not fourteen.
- We did not ship generated 3D. Image→3D reconstruction blobbed gemstones and metal, which is exactly the detail somebody buys jewellery for, so we stopped using it. Try-on became a composited pseudo-3D overlay — tilted plane, occluder, yaw-driven frames — and a 360 became real turntable frames, cut server-side from a phone video of one slow turn so a workshop needs no rig. Building the viewers was the easy half; photographing a catalog for them is the half still ahead of us.
- RTL is not a checkbox. Three right-to-left languages broke layout assumptions everywhere: mirrored navigation, mixed-direction copy, currency placement.
Accomplishments that we're proud of
- Live on Google Play and the App Store with payments wired end to end — shipped software, not a demo. We are pre-revenue: no customer orders had been placed by the end of the competition period, and we say so in the financials rather than dressing it up.
- A closed demand→supply loop: shortfall detected → agent drafts the demand → admin releases it → suppliers bid → settlement at a locked rate.
- A security agent that found real vulnerabilities on its first scan of production config — and which is not permitted to dismiss its own firm findings. Only a human can.
- Agents that maintain the application they run inside.
What we learned
- Agent drafts, human releases. Trust builds fast when the AI never acts unilaterally, and the rule that mattered most was the one naming what each agent may not finish.
- Don't use a model where arithmetic is better. The quiz ranking and the support flow are deliberately deterministic, and they are the two features nobody complains about.
- Legibility is a feature. Fifteen documented cards beat twenty-two undocumented services doing the same work.
- Treat the model ID, quotas and API keys as config, not code — model churn is real.
The agent pays the maker
The newest agent decision is money itself. Supplier payouts at or under a human-set policy cap (USD 50) are settled autonomously in USDC through a Circle developer-controlled wallet — verified end-to-end with real on-chain transfers. The cap is the human decision; under it the agent pays with nobody watching, above it a person must release. Every settled payment produces a downloadable receipt carrying the on-chain transaction hash, and the offer status rail reads the actual payout ledger, so a paid label on screen is never a claim the chain cannot back. Order handling itself now runs as one configurable Auto-mode chain — three sliders set how far the agent goes alone at each step, under a shared weekly spend budget that hard-stops every agent when crossed.
What's next for Meshyay
- Turn on bounded marketing autonomy after a supervised trial period.
- Shoot the catalog for 360 and cutout try-on, so the viewers that are already built have pieces behind them.
- Widen the supplier network and push more of order processing under agent drafting.
- Move the USDC payout rail from testnet to mainnet and raise autonomy tiers with supplier consent.
Source code
The project spans two repositories. Together they contain all source code for the submission:
- Backend, agent fleet and API — https://github.com/mujahidmasood/meshyay-backend
- Flutter client (web, iOS, Android) — https://github.com/mujahidmasood/meshyay-ui
Both are private and shared with [email protected] and [email protected]. The required repo field in Additional Info accepts a single URL, so it names the backend; the client repository is named here.
The Circle Agentic Economy Prize verification repository is public: https://github.com/mujahidmasood/meshyay-agentic-usdc
Log in or sign up for Devpost to join the conversation.