OpenBoxZone

what it is

An e-commerce platform, live at openboxzone.com, and larger than that sentence suggests: catalogue and product models, inventory and stock alerts, pricing and promotions, cart and checkout, orders, payments, shipping, returns, warranty, trade-in, B2B accounts, sourcing and intake, marketplace channels. Every module of it mine, from the schema to the deploy.

the interesting module: composing a product

Listing a product properly is the tedious, expensive part of running a store. Somebody has to research the model, work out which variants exist, write a description that isn't the manufacturer's marketing, pick a category, set attributes, find images — and then do all of it again for the next item, and the one after that.

The composer writes that first draft. It researches the product on the web, produces a structured composed-product object validated against a schema, and hands it to a materialisation step that creates the real thing.

The split between those two halves is the part worth defending.

The materialiser is deterministic and has no LLM in it. It takes a validated composed product and creates the product, its variations, its purchasable items and its seeded inventory — through the same catalogue and inventory services a human goes through. Slugging, validation, uniqueness and inventory seeding are not reimplemented for the AI path. That is why a composed product is indistinguishable from a hand-created one, and why the whole step can be unit-tested from a fixture with no API key anywhere near it.

The model's job is confined to producing something schema-shaped. Research and generation run in a queued worker with progress streamed back, so a composition that takes half a minute never holds a request open.

The guardrail at the end is deliberately boring: a composed product with no image or no stock is blocked from auto-publishing and stays a draft, with the reasons attached. The failure mode of an AI content pipeline is a storefront full of half-finished listings, and the fix for that is a rule, not a better prompt.

the AI platform underneath

The MCP layer is the same architecture I built for Bishwopatra — around forty-one files exposing the platform's operations as governed tools, the same provider-portable agent loop, the same scope gating, plan-and-confirm on writes, always-stop on destructive operations, and recorded transcripts.

The reuse is the point. Building the second agent platform is where you find out whether the first one was a design or an accident.

the stack, in shape

• Backend: NestJS on Node, Prisma over PostgreSQL, Redis for sessions, cache, throttling and BullMQ queues, S3-compatible storage, CASL permissions, and passkey- and MFA-capable auth.
• AI: an MCP tool server over the platform's own operations, the composer with web research and structured output, and embeddings with pgvector retrieval.
• Infrastructure: Docker behind nginx, Prometheus metrics, structured logs, health and readiness probes.

what stays with me

Put the AI at the edge of the system, not in the middle of it. Everything the composer produces goes through the same validated services as a manual entry. The LLM proposes; the platform still decides.

Two products, one platform. The tooling, the invoker and the retrieval layer moved across from another backend almost unchanged, which was the first real evidence that they were architecture rather than one project's clever code.