MnT Commerce
The AI-native commerce platform we start client builds from — semantic search, a shopping assistant, and an ops agent that writes its own code and can't run it until you say so.
MnT Commerce is the base we start client commerce work from: a headless engine with AI built into the product rather than bolted on. Shoppers get semantic search and a conversational assistant; operators get an Ops Copilot that answers questions about the store, then proposes changes as real workflow code it cannot execute until a human approves. We ran every AI path against it for real — including the one that creates a promotion — and the approval gate held: zero store changes reached the database before a human clicked Approve.
An agent that can spend your money is a different problem.
Most "AI commerce" is a chatbot parked next to a store: it can describe the catalog but it cannot change anything, because nobody trusts it to. The moment an agent can actually act — create a promotion, move inventory, place a restock order — the hard problem stops being intelligence and becomes authority. An agent that can spend your money is a different engineering problem from one that can answer a question, and it needs a different architecture: one where the interesting work is what the agent is prevented from doing.
A senior-led path from idea to live.
Split reading from writing, in the executor
Research runs through a read-only executor that refuses code with side effects. The identical code that creates a promotion is blocked while the agent is investigating and only becomes runnable after a human approves it. The boundary is enforced where the code executes — not in the prompt.
Let the agent write code, not call a fixed API
Rather than a menu of pre-baked actions, the Copilot composes the engine's own workflows — the same ones the admin UI calls. You read the actual code before approving it, so the review surface is the change itself, not a summary of it.
Make every AI path degrade, not fail
No key, no credits, provider outage — every feature falls back to a deterministic path: rule-based chat, keyword search, affinity recommendations. Shoppers see a working store; the real provider error goes to the logs.
Dogfood it: run every path for real
We put a live key on it and exercised each AI feature end to end — chat, embeddings, semantic ranking, Copilot reports, and the full propose → approve → execute chain. Two real bugs surfaced that no amount of reading the code would have found.
What happened when we ran the AI against our own store?
Asked in one sentence to create a 10% promotion, the Ops Copilot wrote the engine's own workflow code and stopped. The promotion did not exist in the database until a human clicked Approve — then it did, with the approver's ID recorded against it. Semantic search initially ranked one of three probe queries wrong; the fix was the catalog text, not the retrieval code.
One platform, two audiences.
The shopper side
- Semantic search — Voyage embeddings in Postgres via pgvector, ranked by cosine distance, blended with keyword matching and per-shopper affinity
- Conversational assistant — a Claude tool-loop that searches, recommends, and manages the cart in natural language
- Per-shopper recommendations — affinity scoring from real activity, with cold-start handling and optional AI curation
- Shopper profiles — anonymous activity that merges into the customer record on login
- Every path has a deterministic fallback that runs with no AI key at all
The operator side
- Ops Copilot — asks and answers questions about live store data, writing and running its own read-only queries
- Proposals, not actions — changes arrive as reviewable workflow code with a risk tier, held at zero effect until approved
- Multi-step plans that halt on the first failure instead of half-applying
- Demand and restock — velocity from real activity, stockout projection, and drafted purchase orders for approval
- Proactive checks on a schedule — digests and low-stock alerts, idempotent per day
- Every approval records who approved it
What we shipped, on screen.
The approval gate
The Copilot has written real workflow code and is holding it. Nothing has reached the store yet — the promotion does not exist until Approve is clicked.
A self-correcting research loop
Asked about stock, it queried the store, noticed its own query was missing a field, refined it, and answered — read-only throughout.
The shopping assistant
"Breathable for a hot summer day" returns the lightweight tee — matched on meaning, then explained with the product's real specs.
Where the hard problems were.
Capability is the easy half. These are the decisions that make an acting agent safe enough to put near a real store.
The approval gate is the product
Store changes are proposed as code and held at zero effect. Before approval the promotion did not exist in the database; after one click it did, with the approver's ID on the record.
Code, not a fixed action menu
The agent composes the commerce engine's own workflows — so what you approve is the real change, and the agent isn't limited to actions we predicted in advance.
Fallback-first, not AI-first
Every AI feature has a deterministic path underneath it. The store kept selling with no key, no credits, and a provider returning 400s — because that is exactly how we ran it for weeks.
Composable — including removable
Seven custom modules, zero forks of the commerce engine. The chat feature can be deleted without touching search, recommendations, or the Copilot; shared catalog logic is deliberately feature-agnostic.
AI config is global and in the admin
One place owns the provider key and model for every AI feature — set in the dashboard, not in an env file, never returned to the browser unmasked.
White-label in one file
Brand name, tagline, mark and colours live in a single module that drives the admin shell, favicon, and widget — via the framework's supported extension points, so upgrades don't undo it.
Why each piece is there — and what it buys you.
Every technology earned its place by solving a specific problem better than the alternatives.
Medusa v2 (unforked)
Used for: The commerce engine — products, carts, orders, promotions, inventory.
Advantage: Everything we added is a module beside it, not a patch inside it. Clients get an upgradeable engine and full code ownership, with no fork to maintain.
Read-only executor for research
Used for: The boundary between the Copilot investigating and the Copilot acting.
Advantage: The same code is blocked in research mode and runnable only post-approval. Authority is enforced by the runtime, not requested in a prompt.
pgvector in the existing Postgres
Used for: Product embeddings and cosine ranking, alongside keyword search.
Advantage: Semantic search with no extra service to run, pay for, or keep in sync — the vectors live next to the catalog they describe.
Voyage embeddings
Used for: Turning product text into vectors; re-indexed automatically when the text changes.
Advantage: Anthropic has no embeddings API, and Voyage is the recommended pairing. Content-hashed, so editing a description is the whole re-index step.
Claude tool-loops (provider SDK, no framework)
Used for: The shopping assistant and the Ops Copilot.
Advantage: Direct control over the loop, the tools, and the failure path — which is what lets every branch fall back cleanly instead of throwing.
Deterministic engines under every AI feature
Used for: Rule-based chat, keyword search, affinity recommendations.
Advantage: The AI is an upgrade, not a dependency. Turning it off degrades the experience; it does not break the store.
What it's built on.
- Medusa v2
- PostgreSQL
- Core workflows
- 7 custom modules
- Claude (Anthropic)
- Voyage embeddings
- pgvector + pg_trgm
- Admin-managed keys
- Read-only executor
- Human approval gates
- Risk tiers
- Approver audit trail
- TypeScript
- Node 20
- Hand-written migrations
- One-file white-label
The questions buyers ask about this build.
No — and we're explicit about that. MnT Commerce is our own platform, built as the base we start client work from, running on a small demo catalog we wrote ourselves. The engineering is real and every number here came from running it; the traffic is not. We have no conversion data from it and don't claim any.
It can't act on its own. The Copilot proposes changes as real workflow code with a risk tier, and a read-only executor refuses to run anything with side effects while it's researching. We tested this by asking it for a promotion: it wrote the code, and the promotion did not exist in the database until a human approved it. Every approval records who approved it.
Claude handles judgment: understanding what a shopper means, deciding what to propose, writing the change. Everything else is ordinary code — the approval gate, the executor's read-only check, the vector maths, the workflows that actually touch the database. The model never grades its own work and never holds the authority to act.
Two things worth reporting. A model-specific API parameter was being sent unconditionally while the model itself was admin-selectable, so choosing one of the three models returned a 400 — a bug only a live run finds. And an AI failure was being swallowed into a silent fallback, which meant the real cause (an unfunded account, not the code) stayed invisible until we logged the provider's actual error. Both are fixed; both are why we dogfood.
Usually, and usually not in the retrieval code. Ours ranked one query wrong at first, and the cause was the catalog: every product description was the same marketing sentence with one word swapped, so there was nothing distinguishing to match on. Rewriting four descriptions with real detail — fabric weight, warmth, season — fixed the wrong result and widened the confidence gap between the top two hits by roughly ten times. We look at your product text before we touch your search stack.
No to both, by construction. The engine is unforked and every feature we added is a separate module — we tested that the chat feature can be deleted without disturbing search, recommendations, or the Copilot. Each AI feature has a deterministic fallback underneath it, so switching the AI off degrades the experience rather than breaking the store. You get full code ownership.
Want this as the base for your store?
MnT Commerce is where our client builds start — your brand, your catalog, your storefront, on a platform where the AI is already built in and already gated. Book a free architecture workshop and we'll map it to your stack.