Case study 03 · Multi-agent orchestration

Making 800 Products Findable Online

Customers were falling back to search, and search only works if you already know what you're looking for.

Our Shopify storefront had grown collections the way most retail catalogs do — one at a time, as products got added, with no consistent axis behind them. By the time I audited it, tagging coverage was inconsistent, naming conventions had drifted across a dozen-plus variants for some vendor names, and a customer trying to drill down by brand, equipment type, or application had no reliable path to the right product. We already had that vocabulary — it's how the print catalog and the sales floor talk about equipment. The storefront just didn't use it.

Scope

800 products and 250 collections, rebuilt on a live, actively-selling store: everything staged on a locked-down dev theme until cutover, and every write during the build additive-only, so a partial run couldn't leave the storefront in a broken intermediate state.

Architecture

The taxonomy design came out of an agentic workflow: eleven domain-analyzer agents fanned out in parallel, each covering one equipment category — handheld sawing, wall saws, core drilling, generators, safety gear, and so on — against the full catalog, with coverage verified down to the individual product ID. Design decisions were written once to a shared ledger that every analyzer patched against — the coordination mechanism that keeps parallel agents consistent instead of divergent. The output is a three-axis structure — brand, equipment type, and application — all converging on the same product pages regardless of which path a customer takes in.

11 DOMAIN ANALYZERS · RUN IN PARALLEL · COVERAGE VERIFIED TO PRODUCT ID, NOT SAMPLED handheld wall saws core drill generators blades bits grinding safety concrete power accessories Single decisions ledger one authoritative doc; agents patch against it, never re-litigate it Three-axis taxonomy brand equipment type application all three paths converge on the same product pages Phase 1 · tagging dry-run previewed the plan 921 tags · 523 products 31 collections · LIVE Phase 2 · templates 27 landing pages built card-image bug found + fixed dev theme Phase 3 · brand hubs 21 vendors · 18 name variants 27 brand + category pages 1 brand tree LIVE Phase 4 · navigation 50 header links rewritten dev header only live menu untouched Additive-only writes throughout — no deletes, no rule changes, no retitles. A partial run cannot break the storefront.
Eleven analyzers work from one shared ledger of decisions, so parallel agents stay consistent with what has already been decided.

Rollout

A dry-run generated the exact write plan — 921 product tags across 523 products — for review before the live run executed it. From there, the workflow built landing pages for every category and brand hub pages for all 21 vendors. Vendor naming had drifted into 18 inconsistent variants over the years; the workflow normalized them, then generated every brand-plus-category page automatically from rules rather than by hand, and rewrote the store's header navigation on the staged theme. One brand's full category tree shipped to the live site the same day.

Breadcrumbs are generated by a script that walks the taxonomy tree and writes ancestor chains into a collection metafield, applied across 202 collections. A separate image pipeline normalized card images across 135 collections — trimming and padding to a consistent fill ratio, center-cropping to square, and detecting dark scene photos to swap for white product shots by measuring border-pixel whiteness — with originals kept for rollback.

Outcome

Status: partially live. The tagging pass and the first brand's full category tree are in production; the remaining landing templates, 20 brand hubs, and the navigation rewrite are complete and staged on the dev theme for a full QA pass before cutover — including an evaluation pass by an independent reviewer agent, separate from the agents that built it, checking the staged output against the taxonomy spec.

That reviewer-agent pattern is standard practice here, not a one-off, and it has real teeth: on another build, an independent security-review agent returned four must-fix findings and blocked the release as not production-safe until the fixes shipped and a second independent agent verified them.

One implementation note: parsing blade diameters from free-text product titles failed on most of the test set; parsing the same values from structured variant data was fully deterministic, and that's what shipped.

Stack
Shopify Admin GraphQL Python Shopify Liquid smart-collection rules metafields multi-agent workflow