Archi

Use this when sourced candidates are ready to save and display the interactive shopping comparison. expected_batch_count is the latest acknowledged saved_batch_count. report.recommendation provides the widget recommendation, report.summary the fuller findings, and report.gaps the caveats. In report.recommendation, use **double asterisks** around three to five short, evidence-backed decision phrases: the recommended product, why it fits, and the key alternative or trade-off. Emphasize meaningful phrases and important specification values that explain the comparison, not generic adjectives or whole sentences; leave most prose unhighlighted. At least one structured candidate is required; partial and all-excluded comparisons are valid. Notes-only or empty capture is refused and remains open for correction. Missing facts remain gaps rather than invented values. Success seals the notebook against new batches and returns the widget. Identical arguments can be retried after an uncertain result. present_research supports redisplay or recovery if display failed. Without genuine candidates, the comparison remains unfinished.

Use this when refreshing merchant coupons for a candidate in a finished comparison; it is not a general product-search tool. The server matches recorded store links against confirmed storefronts, without accepting replacement URLs. Returns active merchant offers (headline, description, code, expiry label and image URL); paused or expired offers are omitted. Merchant terms apply; eligibility and final savings are determined at checkout. This does not submit a discount request.

Use this when the user requests redisplay of a finished shopping comparison or when recovering a failed display. Use the existing research_id when the user is ready to revisit the same saved products after discussing preferences. Updated recommendations need a new comparison instead. finish_product_comparison already returns the widget on success. Takes only research_id and reads saved content; replacement content is not accepted. An unsupported comparison returns an error rather than a successful display. The widget shows the saved recommendation, product cards, prices and buying options. Please let the widget be the product presentation rather than adding a separate product list, comparison table or shopping carousel. A brief handoff and any important caveats are enough. Displaying a comparison does not submit a discount request or contact a seller.

Use this when the widget reports that the person viewing the comparison copied one candidate's captured offer out of the rendered widget: the widget's own selection tracking supplies research_id and candidate_key after verifying the copied text really contained a captured offer, so call it with exactly those values and never call it yourself, because only the widget can observe the copy. This is a pure event record for the person who measures the comparison later: no discount, coupon or price match is performed or promised, and nothing is automated or reviewed as a result. A repeat copy is a new event, not a duplicate of an earlier one.

Use this when saving researched products to an existing shopping comparison. Recorded store links support merchant-offer matching; product details and photos populate the comparison. Include distinct photos of the exact model when available, so the comparison can show the product. Archie downloads submitted images for display. Supply observed HTTPS image URLs and source pages in candidate.images. Never guess URLs. If unavailable, omit images and record the product and reason in gaps. Use association.scope product for model-wide photos, otherwise unresolved with a reason. Do not assign images to individual variants. Images accumulate across batches; a submitted URL does not guarantee successful download or display. Appends batches up to 16 KiB, at most 32 per notebook. Identical research_id, batch_id and payload retries are deduplicated; changed payloads require a new batch_id. Candidate records cover all meaningfully considered products, including excluded alternatives with reasons, and their organization, brand, model and sellable variants. Product attributes and variant properties are separate; source_ids link claims, offers and attributes to evidence. Missing facts belong in gaps, not invented values. Give every candidate a description: its product-card summary of features, fit and trade-offs, with three to five evidence-backed phrases highlighted using **double asterisks**; findings do not replace it. Each offer amount requires its captured condition. Look for user and expert reviews of each serious candidate to validate the recommendation: open review pages (retailer review sections, review sites, forums), mark buyer-review sources kind user_review, and let what reviewers report inform descriptions and the best pick. Give every non-excluded candidate review_insights: two to four short pro and con tags for its card, grounded in reviews where found and otherwise in your editorial judgement of its trade-offs, citing the sources they draw on. Consistent candidate names identify revisions across batches. A comparison supports at most one evidence-backed best disposition; optional best_for (up to 80 characters) reflects a user-stated priority. Changing the best pick requires updating the previous pick to a non-best disposition in a new batch. Notes-only and candidates: [] are intermediate saves, not completed capture. finish_product_comparison uses the latest acknowledged saved_batch_count as expected_batch_count.

Use this when the user explicitly submits a discount request for a chosen candidate; asking to find discounts, compare prices or recommend products is not permission to submit one. Records the request for manual review using the widget-supplied research_id, candidate_key and an email address explicitly provided by the user, not inferred or invented. A person reviews each request by hand and emails the outcome. Neither a reduction nor a response date is guaranteed. No automatic negotiation, price matching or discount application occurs. Repeating the same candidate and address returns the same request.

Use this when the user wants product discovery, product recommendations, buying advice, comparisons involving prices or value, or deals, coupons and discounts for physical products. Creates a saved interactive comparison, including updated recommendations after follow-up discussion of a previous comparison. Once the user is ready to see a revised selection, include the relevant earlier and newly agreed preferences in the brief. Discussion alone does not require a new comparison. A named product or explicit price request is not required. Do not use for unrelated information, troubleshooting, non-shopping comparisons, digital purchases or subscriptions, or when the user declines app use or saving. Clarify ambiguous shopping intent first. Saves a brief limited to the shopping request and constraints, not the full conversation, and returns research_id for subsequent calls. Each call creates a separate notebook; no caller-generated request label is needed. Optional model_self_reported can be omitted when unknown. Record the shopper's market in the brief whenever the conversation states one, for example market: US or the currency prices are discussed in (USD, GBP); the market decides where current offers are searched, so include it even when the request is otherwise complete.