Product Helper
Product Helper is a guard-railed AI agent that builds and fills product pages on Sartoro's Shopify store — safely, at roughly ten times the speed I can manage by hand. I designed it, built it, and wrote the safety model that lets it touch a live, order-taking catalog without breaking anything.
The problem
Sartoro is custom-made menswear: over two thousand products, and a single product page isn't a description and a photo — it's dozens of dynamic metafields and metaobjects. Fabric and care, SEO, taxonomy attributes, listing filters, cross-sell references, quick-switch wiring, and the configurator data that drives price and the finished garment. Most of it is written by other systems, and the defaults call out to apps. Get one value wrong and you don't get an error — you get a broken price rule or a wrong output, silently, on a page that's live.
That complexity is deliberate — Sartoro sweats product options harder than most of the custom-tailoring market — but it makes setup brutal. Filling a luxury line by hand took me the better part of six months. And under launch deadlines, the tempting shortcut (Shopify's built-in description generator) produces near-duplicate copy that reads flat and gets indexed poorly, because every product ends up saying the same thing. Product setup had quietly become the bottleneck.
What it is
A small toolkit, not a magic button: sixteen stdlib-only Python scripts over the Shopify Admin API, plus a written knowledge base of the store itself. The scripts read, validate, snapshot, diff, apply, and roll back — one product at a time. The knowledge base is the real asset: a store map, a schema for what a good page looks like, a theme map of which fields the storefront actually renders, and a playbook of every trap that ever caused a real error, written so a cheap model can run the recurring work mechanically.
The safety model is the product
Anyone can get a model to write a description. The hard part — and where the real engineering went — is doing it without corrupting the 90% of the page you weren't asked to touch. Every write passes the same gates:
- Read before write — always fetch the live product first, never act on memory.
- Snapshot before write — the full current page is saved first. No snapshot, no write.
- Diff and approve — a field-by-field old → new, and only approved fields get written.
- Allowlist only — the agent can touch a short list of content fields; price, inventory, status, the configurator, and every app namespace are hard-blocked by code that refuses.
- One at a time — no silent bulk edits; bulk means a canary of one, verified live, first.
- Everything is reversible — each change is logged and can be rolled back from its snapshot.
The principle underneath: on a live store, additive and reversible beats clever. A single shared fabric record can be wired to dozens of products at once, so most of the code is about refusing, not writing.
What it does
With those rails in place, the agent audits every page against the schema, drafts real per-product content and SEO (unique copy from real attributes, never invented), wires the mechanical layer — category, taxonomy, collections, quick-switch and swatch fields — and handles images at catalog scale, mapping a photo library to the right product and ordering the gallery the way the theme expects. Because it writes each page from that product's own data, the descriptions come out distinct and machine-legible — the opposite of the duplicate-copy problem it replaced.
Where it stands
The read, validate, diff, and snapshot paths are tested live on Sartoro; the write path is gated end-to-end. The headline result: a luxury line that took roughly six months by hand, and a full collection pushed with the agent in about a week — with fewer of the small, scattered errors, because a verified workflow runs the same way on the hundredth product as the first. It stays deliberately human-in-the-loop: it never sets a price, never touches stock, never publishes, and never writes without a yes on the diff. The next rung is a second agent whose only job is to check the first.
I wrote up the thinking behind it as a field note — an agent you can trust on a live store — and it sits inside the broader marketing-engineering work: a marketer who builds the systems that do the marketing.