Retail Lab · Methodology
Marketplace filter search answers "what's listed as matching?" An agentic shopping search answers "what actually matches, and how do I know?" — treating every retailer spec field as a claim to verify, not a fact to filter on. This page documents the methodology, the patterns and antipatterns that emerged from actually running one of these searches end to end, and a reusable drop-in prompt for the next one.
The differentiator from ordinary search is epistemic discipline: every number and every status the agent reports carries a visible provenance (published vs. inferred, confirmed vs. assumed), every requirement change triggers a full re-verification pass rather than a patch, and every comparison shown to the user is an honest, non-dominated, apples-to-apples set. This isn't a one-off checklist for a single search — it's the operating discipline for any agent doing hard-requirements product research.
Trusts the "Product Dimensions" field as-is. Can't tell an overall measurement from an interior one. Has no way to catch a scrambled W×H×D field. Treats a catalog "in stock" flag as proof of real availability. Returns everything that matches the filter, verified or not.
Identifies the actual binding constraint and verifies it against a primary source. Labels every fact PUBLISHED or INFERRED. Hunts deliberately for known failure modes instead of waiting to trip over them. Confirms availability at a real location, not from a catalog flag. Shows its work.
Don't skip a step because a candidate "looks fine." The failure modes below are specifically the ones that look fine until checked.
Identify which dimension/spec actually gates fitness for the user's purpose. For storage/furniture this is almost always an interior/usable measurement, not the overall/exterior footprint marketplaces show by default. If the user's requirement is expressed as an overall dimension but the real constraint is interior, say so and re-derive the actual threshold before screening candidates.
A retailer's on-site search box, a product-line listing page, or even a general web search is a query against a relevance/ranking algorithm, not a lookup against ground truth. A narrow query can silently miss sibling SKUs, differently-named variants, or newer/older listings — "no results" or "these are the only matches" means "not surfaced by this query," not "doesn't exist." Search the same product line by more than one angle (exact product name, the brand's own collection/category page, guessed sibling-name variants) before concluding a candidate isn't available anywhere.
PUBLISHED: found in a manufacturer's own spec sheet, diagram, or dimensional drawing — cite where. INFERRED: estimated by the agent (e.g., extrapolated from a sibling SKU, backed out from an overall-vs-interior offset). Always show the arithmetic used to infer it, and never present it with the same confidence as a published number.
Actively search for hidden internal dividers or partitions that shrink a wide-looking product's usable compartments — a standing check on every wide/multi-compartment candidate, not a reaction to something looking suspicious. Check sibling SKUs in the same product family/name explicitly: a trap SKU often shares a product name with the clean version, differing only by a size or suffix.
When more than one retailer or listing carries the same SKU, compare their published dimensions for agreement. Disagreement is a signal to dig further, not to average or shrug. Sanity-check each spec table internally: does overall-minus-interior leave a plausible wall/base thickness? An implausible or negative result means the field pairing is probably wrong.
Never trust a marketplace spec table's field-label-to-value pairing at face value. Axes (W/H/D) get swapped between systems — a field rendered as "8"W x 14"H x 18"D" can be reality's H×D×W. Cross-check against a second source or the product photo before accepting it.
A catalog-level flag embedded in a page's own JSON (isDiscontinued:false, isSoldOut:false) means the SKU exists in the catalog — it is not proof of current buyable stock at any specific location. True availability requires a live, location-specific stock check (a real zip code or store). One signal that is trustworthy: an explicit "Currently unavailable, we don't know if/when this will be back in stock" block — that reads as discontinued, distinct from a normal "temporarily out of stock, notify me" restock message.
If a real stock check contradicts an earlier catalog-flag-based claim for one item, immediately walk back every other availability claim made the same insufficient way — don't fix just the one item and leave the others standing as false-confident.
Retailer pages often embed richer data (price, stock flags, item numbers, sibling-SKU/color links, "this bundle contains" sub-product lists) in their own JSON/HTML than what's visibly rendered. Fetch and parse it directly. If an automated fetch gets blocked or errors on a given retailer, that's a tool/method failure, not proof the data is inaccessible — retry with a real browser user-agent before concluding "can't access."
When any requirement changes — color, availability, a geometry constraint, a unit of measurement — re-check every existing candidate against it directly. Never assume a candidate that passed before still passes, and never guess whether a variant exists without checking that SKU's own listed sibling links. If a unit/threshold driving a ranking changes, recompute every derived ranking and dominance relationship from scratch — a small change can flip which option is actually best.
If an item is sold as one fixed-price bundle, never decompose that price into implied per-component prices, and never merge a bundle-included component with a separately purchased unit of the "same" item into one line. When summing units against a total budget, only sum footprints of units placed side-by-side — stacked units contribute zero additional footprint. Before quoting "N inches to spare," do the arithmetic explicitly and check both a narrower and a wider alternative.
Only present options that are genuinely different in a real tradeoff (cost, verification confidence, or a real substitution). Never show a strictly-dominated option next to a better one with no offsetting advantage. When excluding something, state the true, agreed categorical reason first — don't substitute a coincidental numeric near-miss for the real reason even if both happen to be true.
Named, reusable moves — apply them by default, not just when something goes wrong.
Search a product line by more than one angle — exact product name, the brand's own collection page, guessed sibling-name variants — before treating a search's result set as the full universe of what exists.
Always screen against the interior/usable dimension, not the overall footprint — the overall dimension is what marketplaces default to showing and is rarely the binding constraint.
Tag every fact PUBLISHED or INFERRED at the point of use, with inferred values carrying their derivation inline, so confidence travels with the number instead of flattening into one undifferentiated list.
Run a deliberate, standing search for known failure modes (like hidden dividers) on every relevant candidate — including sibling SKUs sharing a product family name — rather than waiting to notice one by accident.
Treat "in stock" as unproven until confirmed by a live, location-specific check. Catalog-level flags only confirm the SKU exists, not that it's currently buyable where the user is.
When a verification method is shown insufficient on one item, immediately apply the same correction to every other item verified the same way — don't fix the single instance and leave siblings falsely confident.
Keep a fixed-price bundle's total intact and undecomposed. Never infer per-component prices within it, and never let a bundle-included item visually merge with a separately purchased unit of the same product.
Any time a requirement, unit, or threshold changes, recompute every downstream ranking, total, and "best pick" from the underlying data rather than patching the one item that prompted the change.
Only present options that differ in a real tradeoff. Drop options strictly worse in every dimension than another shown option, and explicitly explain the absence of any option the user would reasonably expect.
When excluding something, lead with the actually-agreed categorical rule, not a secondary numeric coincidence — even when the numeric fact is also true.
Mistakes actually made and corrected while running this exact search — stated as warnings so the next agent doesn't repeat them.
Trusting that a store's search tool, category page, or a single web search query surfaced every relevant product. Real episode: a pass searched "HAVSTA sideboard" and never separately searched "HAVSTA Cabinet with Base" — the sibling product existed the whole time, just never surfaced by that query.
Fix: report "not found in this search pass," not "doesn't exist," and try at least one more discovery angle before ruling a candidate out.Claiming "AVAILABLE" from a page's own isDiscontinued/isSoldOut flag alone, with no per-location stock check.
Fix: treat catalog flags as "needs checking." Only claim availability after a live, location-specific check; otherwise say "unconfirmed."Placing a fixed-bundle total next to itemized standalone totals as if directly comparable, without flagging the two represent different purchase structures.
Fix: label each total by its pricing model and explain the difference before comparing.Displaying a per-item price for something only ever sold as part of a bundle, implying a discount or allocation that doesn't exist.
Fix: show the bundle as one atomic price; never divide it.Justifying an exclusion with a secondary numeric near-miss instead of the real, agreed categorical rule.
Fix: always state the true governing reason first; a numeric fact may be mentioned, but never as the headline reason.Omitting a requested comparison option without saying why, leaving its absence unexplained.
Fix: explicitly state that the option doesn't qualify and why (e.g., "doesn't fit the budget by X inches").Carrying forward an old "best pick" or ranking label after a requirement, unit, or threshold changed, without re-deriving whether it still holds.
Fix: recompute rankings from scratch on every relevant change before restating any "best" claim.Visually indenting or grouping a separately-purchased item as if nested inside a bundle it isn't part of.
Fix: keep bundle contents and separate purchases in visually and structurally distinct groups.Assuming a product line offers a needed color/finish/size variant without checking that SKU's own sibling-variant links.
Fix: always check the specific SKU's listed sibling links before claiming a variant exists.Authored by an agentic-systems prompt-engineering pass over this session's full methodology. Paste this as a system/task prompt at the start of a future agentic shopping session to encode all of the above concisely.
Distilled from a real, iterative agentic shopping session run on this site — see the live case study for the buffet/sideboard/credenza search that produced every pattern and antipattern above, including the exact color-disqualification, availability-correction, and bundle-pricing episodes referenced here.