Buying well online means reading dozens of shop pages, reviews and spec sheets, and judging whether a "-40 %" banner is real. A shopping agent turns a wish into a researched shortlist, compares the true total cost, watches prices and warns about fake discounts. In 2026 the same agents can also check out on the user's behalf through new payment protocols, which makes spending limits and consent the central design question.
Problem & value
- Today: consumers use comparison portals (price lists, test reports), browser extensions and forums, and still struggle with fake reference prices, hidden shipping costs, variant confusion and review manipulation.
- AI value: natural-language requirements instead of filter menus, cross-source synthesis of reviews and tests, total-cost-of-ownership comparison (energy, consumables, warranty), long-running monitoring that a human will not do, and automation of tedious steps (coupon search, form filling).
- EU context: the Omnibus Directive (EU) 2019/2161 requires that, when a price reduction is announced, the trader states the lowest price applied in the prior 30 days. Price-history agents can verify this claim independently [1]. Quantified savings figures from vendors are marketing claims; no neutral study of savings is cited here.
Variants
- Product research assistant: conversational advice and shortlist (electronics, appliances, bikes).
- Price tracker and deal alerts: watchlist with price history and target-price notifications.
- Grocery and household basket optimiser: weekly shopping list across supermarkets and delivery services (links to PERS-004 meal planning).
- Agentic checkout: agent buys within a mandate (budget, merchant, item class) via payment protocols.
- Second-hand and marketplace hunter: monitors classifieds for matching offers, drafts messages.
- SMB variant: small-business procurement of standard goods, see AGENT-005; merchant-side shopping assistants are CONV-006.
How it works
- wish + constraints (budget, brand rules, values, delivery)
- clarifying questions (LLM)
- candidate retrieval (comparison-portal data / merchant feeds / web search / scraping)
- entity resolution (same product across shops: EAN/GTIN, MPN)
- enrichment (specs, tests, review summaries, energy label, warranty)
- total-cost calculation + price-history check (fake-discount test)
- ranking with explanation
- user decision
- [optional] checkout under mandate (agent payment token, spending cap, confirmation step)
- post-purchase: order tracking, return window and warranty reminders
- Retrieval: structured product data (GTIN-keyed feeds, APIs) beats scraping; browser-operating agents are a fallback for shops without APIs (AGENT-003).
- Reasoning: LLM maps vague needs to specs and weighs trade-offs; deterministic code does the arithmetic and price-history statistics.
- Review analysis: summarise and cluster reviews, down-weight suspicious ones; treat results as indicative.
- Human-in-the-loop: user confirms the purchase by default; autonomous buying only below a cap and for pre-approved merchants, with an audit log.
Data preparation
For consumers there is little to prepare: the data is the wish list, budget, brand and values constraints, delivery address and past orders (mail receipts, shop accounts). The heavy data lives with the merchants: product feeds, specs and reviews.
For an SMB buyer the sources are the ERP or accounting system (item master, past purchase orders, preferred suppliers), framework contracts on the file share, and approval rules that often exist only in people's heads. Typical gaps: no stable item numbers or GTINs, free-text descriptions of recurring purchases, duplicate suppliers, unwritten spending limits, and shop accounts shared by several employees.
Preparation steps: - Write down the purchase mandate: budget caps, allowed merchants, item classes, who approves (PREP-012 for a glossary approach, PREP-024 for what may go into the tool). - Clean the item master: map recurring items to GTIN or MPN, merge duplicate suppliers (PREP-005 for ERP exports, PREP-011 for tidy tables). - Export the last 12 months of orders as a test set to compare AI proposals with actual decisions (PREP-018). - Create separate shop accounts and payment tokens with caps per person.
Effort share is low for private use (under 10 percent) and low to medium for SMB (20 to 30 percent), mostly the item master cleanup.
Implementation paths
Which path for whom
- Private: Path A. Comparison portals with AI features, price trackers and general assistants cover occasional purchases at no or low cost.
- Developer: Path B. Merchant feeds, search APIs and tool-calling LLMs let you build custom rules and payment mandates; self-hosting scrapers adds little value.
- SMB: Path A. Procurement of standard goods is commodity; portals, marketplace business accounts and ready-made shopping assistants are mature, so build only if you have unusual rules.
Path A — Buy (recommended for most people)
- Comparison portals with AI features: Idealo (DE), Geizhals (AT, EU), PriceRunner (SE), Google Shopping with AI Mode, Amazon Rufus; EU-based portals are noted where marked.
- General assistants with shopping modes: ChatGPT shopping research, Perplexity shopping, Gemini agentic checkout in Google's ecosystem; availability of in-chat purchase in the EU varies and changed in 2026 [2][3].
- Price tracking: Keepa (Amazon price history), CamelCamelCamel, Idealo price alerts, browser extensions (check privacy policy: many monetise browsing data).
- Choose A when: occasional purchases; start with a portal plus alerts.
Path B — Build on cloud APIs
- Models: frontier LLMs with tool use (Claude, Gemini, GPT) or Mistral (EU provider) via EU regions where offered; use structured outputs for product comparison tables.
- Data: merchant and affiliate product feeds (e.g. Awin, Idealo partner feeds, Amazon Creators API, the successor of PA-API 5.0 [10]), search APIs; respect each provider's terms.
- Orchestration: MCP tools for search, price history and cart; n8n or Python agent framework.
- Payments: Agentic Commerce Protocol (OpenAI and Stripe) with scoped Shared Payment Tokens, and Google's Agent Payments Protocol (AP2) with signed intent, cart and payment mandates [3][4].
- Choose B when: you build a shopping feature or a personal tool with custom rules.
Path C — Self-host (open source)
- Models: Qwen3, Mistral Small, Llama or gpt-oss class open-weight models via Ollama or vLLM; an embedding model for review and spec retrieval.
- Agents and scraping: browser-use or Playwright, Crawl4AI, Firecrawl (self-hostable), n8n; price history stored in SQLite or TimescaleDB; changedetection.io for watchlists.
- Hardware: HW1 for tracking and small models; HW2 (24 GB GPU) for a capable ~30B quantised agent. Keeps wish lists, budgets and addresses at home (see PERS-005).
Path D — Custom training
Rarely sensible. Possible: a small classifier for fake-review or fake-discount detection or a product matcher trained on labelled GTIN pairs; needs thousands of labelled examples.
State of the art (2026)
- Agentic commerce protocols have emerged: ACP (OpenAI and Stripe) and AP2 (Google) define how agents get scoped payment authority without seeing card numbers; their composition is still settling, and OpenAI deprioritised standalone in-chat Instant Checkout in March 2026 in favour of product discovery and merchant-run checkout, while ACP continues for feeds and apps; Google's Universal Commerce Protocol (UCP, announced 11 Jan 2026) powers checkout in Gemini and Search AI Mode for eligible US merchants [2][3][4][9].
- Shopping research modes in major assistants produce multi-source buyer's guides; quality depends on data access and is uneven for niche or local products.
- Failure modes: hallucinated specs or prices, stale prices, wrong variant or size, affiliate-driven bias in rankings, and prompt injection from shop pages or reviews that tries to steer the agent (for example hidden text telling it to buy a specific item). Browser agents remain slower and less reliable than API integrations.
- Limits: price data is often delayed; personalised or dynamic pricing means the user may see a different price than the agent.
Shared resources & combinations
- Same stack as AGENT-003 (browser agents), AGENT-005 (procurement), KNOW-015 (deep research) and CONV-006 (merchant side of the conversation).
- Combine with PERS-001 (budget and subscriptions), PERS-015 (returns, warranty, withdrawal right), PERS-016 (opt out of tracking and profiling), PERS-004 (grocery baskets).
- One local LLM server (HW2) can serve PERS-001, PERS-004 and this case.
Effort, cost & KPIs
- Path A: hours; mostly free, portals earn via commission.
- Path B: days to weeks for a prototype; cost is LLM tokens and feed access; checkout adds PSP integration.
- Path C: a weekend for a tracker; a stable agent needs ongoing maintenance as shop layouts change.
- KPIs: savings versus first-seen price, share of recommendations the user accepts, price-claim accuracy, return rate of purchases, false alerts, number of agent purchases requiring correction.
People & change
Private: involve the household members who share the budget and agree on caps and confirmation rules before enabling any automatic purchase. Keep checkout confirmed by a person by default.
SMB: involve management (spending limits and policy), the purchasing lead as process owner, the buyers who will use it, IT for accounts and payment tokens, and the data owners of the item master. Bring in key suppliers if the agent interacts with their shops or portals. Include the DPO only if employee or customer personal data (delivery addresses, named buyers) flows through the tool.
Works council: usually no, since the tool compares prices and does not evaluate employees. It becomes relevant (§87(1) no. 6 BetrVG) if usage logs per buyer are analysed, or a purchase agent changes work processes (§90(1) no. 3 requires timely information). Public sector: involve the Personalrat and respect procurement law (Vergaberecht) thresholds.
AI literacy: support the buyers with a short session on fake discounts, sponsored results and review manipulation, and the limits of agent checkout. See GUIDE-006.
Typical concerns: "will purchasing be automated away?" and "who is liable for a wrong order?" Answer with a spending cap, an audit log, a four-eyes rule above a threshold and a pilot with one buyer and one item class. See GUIDE-009 and GUIDE-007.
Risks, regulation & compliance
- EU AI Act: typically minimal risk; transparency (Art. 50) applies if offered as a chatbot, and AI literacy (Art. 4) for providers' staff. Manipulative techniques exploiting vulnerabilities fall under the Art. 5 prohibitions; a merchant-side agent that does this is a compliance problem, not a user tool [5].
- GDPR: purchase history, addresses and wish lists reveal health, finances and family situation; profiling needs a legal basis; DPA with providers; data minimisation toward shops.
- Consumer law: Omnibus price-reduction rules, 14-day withdrawal right, and the Digital Services Act duties for marketplaces and dark-pattern bans (Art. 25) [1][6]. An agent acting for a consumer does not remove the consumer's responsibility for the contract.
- Terms of service: many shops forbid scraping or bots; use official feeds and APIs.
- Mitigations: hard spending caps, merchant allowlists, confirmation for new merchants, disclosure of affiliate links, sandboxed browser, ignore instructions found in web content, audit log.
Getting started
- List your last three bigger purchases and note what research cost you; define must-have criteria.
- Try a comparison portal's alerts plus a general assistant's shopping mode on one real purchase.
- Add a price-history check (Keepa or a self-built tracker) before every "sale" purchase.
- For automation: build a read-only agent first (no payment), compare its picks with your own.
- Only then test agentic checkout with a low cap, one allowlisted merchant and mandatory confirmation.
Sources
- Directive (EU) 2019/2161 (Omnibus Directive) — https://eur-lex.europa.eu/eli/dir/2019/2161/oj
- OpenAI — Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol — https://openai.com/index/buy-it-in-chatgpt/
- Agentic Commerce Protocol specification — https://github.com/agentic-commerce-protocol/agentic-commerce-protocol
- Google — Agent Payments Protocol (AP2) — https://github.com/google-agentic-commerce/AP2
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2022/2065 (Digital Services Act) — https://eur-lex.europa.eu/eli/reg/2022/2065/oj
- browser-use project — https://github.com/browser-use/browser-use
- Model Context Protocol — https://modelcontextprotocol.io
- Google — About the Universal Commerce Protocol (UCP) and UCP-powered checkout (Merchant Center help) — https://support.google.com/merchants/answer/16837055
- Amazon Associates — Migrating to Creators API from Product Advertising API — https://affiliate-program.amazon.com/creatorsapi/docs/en-us/migrating-to-creatorsapi-from-paapi