Let the agent propose the catalog change before it writes live

Start from the blast radius

A ranking pin is a customer-facing write. So is a synonym map, a collection rule, a boost, or a "hide when OOS" exception. Chat that explains search performance is analytics. Chat that can change those rules is operations with a softer UI.

Vendors will demo the second while you are still evaluating the first. Your job is to keep them separate in the purchase and in the permission model. If the agent can write, the first production question is not "how smart is it?"—it is "what does the merchandiser see before Approve?"

If you cannot see the diff, you are not approving a change—you are blessing a surprise.

Merchandising is full of changes that look small in admin and large on the storefront: a synonym that redirects a high-intent query, a pin that displaces a funded brand placement, a collection rule that drops gift-with-purchase eligibility. Each of those needs the same change discipline you would give a price file—except the UI now speaks in chat.

If your storefront, app, and marketplace feeds read different rule stores, the proposal must say which stores will update and in what order. A preview of only the desktop PLP is how you ship a mobile-only surprise.

Walk the dry-run path once

Do this on a staging catalog or a held-out category before any production write scope:

1. Ask for a recommendation only. Same prompt you would use in a live demo: "What should we pin in the winter boots collection this week?" Capture the suggestion and the evidence it cites.
2. Demand a structured proposal. Affected collection or query, SKUs added/removed/boosted, rule text before and after, and which channels inherit the change.
3. Show the customer-visible preview. Not a JSON blob—category page order, search result strip, or collection grid as a shopper would see it.
4. Name the approver. Role, not "the team." Dual approval if the change touches margin heroes or gift sets.
5. Execute only after Approve. Log who approved, what version went live, and how to roll back within minutes.
6. Re-open the category after an hour. Confirm the live state matches the approved proposal. If not, you found a sync bug—stop widening scope.

Run that path with a human merchandiser scoring usefulness. If step 2 or 3 is missing in the vendor product, you do not have a merchandising agent—you have a chat window with a dangerous API key.

What the preview must contain

Minimum viable proposal:

• Before / after for the rule or ranking slice.
• SKU list with titles humans recognize, not only IDs.
• Inheritance — does marketplace, app, or wholesale catalog also move?
• Inventory honesty — will this pin an OOS or oversold unit?
• Rollback handle — one action that restores the prior rule version.

Nice-to-have, not a substitute: estimated conversion impact. Vendor impact estimates are hypotheses. Your approver needs the diff even when the estimate looks great.

Catalog lies still win. An agent that accelerates pins on bad collection membership will amplify the wrong products faster. Fix membership and inventory truth before you grant write scope—the same lesson as reading zero-result searches before buying another AI search layer.

Widen writes in layers

Week one: synonyms and spelling maps only, dual approval. Week two: pins on non-peak categories. Week three: boosts with a daily change-log review. Never start with automated collection rebuilds across the whole tree.

Freeze writes before major promos until rollback is rehearsed. Holiday calendars are when merchandising assistants get pressure and when a bad pin hurts most. If weekend approvers do not exist, scheduled agent writes do not exist either—recommend-only is the honest mode.

Custom agents on your stack follow the same ladder. Tool permissions should expose propose_catalog_change before apply_catalog_change. If your harness can only call the live write API, wrap it. The wrapper is the product.

Document the ladder in the same place you keep feature flags. New hires should not learn write scope from folklore. When a vendor ships a new write type—collection rebuilds, price-adjacent boosts, "AI reorder of whole nav"—it enters at recommend-only until the preview path is proven again.

For multi-brand or multi-store setups, scope proposals to one storefront identity at a time. An agent with access to every catalog will eventually optimize the wrong brand's heroes.

Failure modes to name out loud

Rubber-stamp Fridays: volume of proposals exceeds review quality. Fix with rate limits and a daily cap per approver.

Silent channel drift: storefront updated, marketplace feed lagged. Fix with inheritance in the proposal and a post-apply check per channel.

Orphan rules: agent creates a pin nobody can find in the admin UI later. Fix with durable change logs and human-readable rule names.

Confidence theater: high-confidence suggestions on thin evidence. Fix with a required evidence panel and a merchandiser scorecard that tracks "would have done anyway" vs "novel and correct" vs "would have hurt."

Shadow mode is useful when the vendor supports it: agent proposals land in a queue with no apply button until you flip a flag. If the product cannot shadow, simulate it—export proposals to a ticket queue and apply by hand for the pilot. The friction is the point.

After the pilot, keep a monthly review of applied changes: how many rolled back, how many customer complaints referenced a ranking shift, how often approvers edited the proposal before accept. Those numbers tell you whether to widen scope. Vendor NPS does not.

Put this into practice

Write a one-page policy: which write types exist, who approves each, what the preview must show, and when writes freeze. Pilot on one category for two weeks recommend-only, then one write type. Hold a retro with the scorecard—not the vendor slide.

If you are building the agent yourself, put propose and apply behind separate tools and separate audit events. If you are buying it, make preview-and-approve a contractual requirement, not a roadmap smile. Soft signals from merchant-assistant launches in this category keep repeating the same promise—chat that can change rules—so the governance pattern matters more than any single logo.

We build AI applications and agents where catalog and merchandising writes stay gated and reversible. If you are evaluating a merchant assistant with write access—talk to us.

Related work: Spin:Market.