PW+-r

Inspiration

Online shopping becomes frustrating when a product is hard to find, out of stock, or priced close to a buyer’s limit. We wanted to build an assistant that does more than chat: it understands a shopping request, searches a live product catalog, applies a transparent purchase policy, and creates a follow-up path when an item is unavailable.

What it does

Scout is an AI shopping assistant built as a multi-agent system.

It routes each request to the right specialist:

a brief agent asks only for details that are necessary to avoid unsuitable results, such as a shoe size or device compatibility;
a fast agent checks product availability and price in the server;
a product-link agent discovers public category and product URLs and sends them to an ingestion pipeline;
an orchestrator coordinates the whole conversation.

When a matching product is available, Scout compares its price with the user's budget. If the deal is clearly below the limit, it can complete a simulated purchase automatically. Otherwise, it requests confirmation first.

When a product is unavailable, Scout can create an availability monitor and optionally enable WhatsApp notifications. If the shopper changes their mind during this flow, the interaction is explicitly resolved without creating a monitor.

How we built it

We built the backend with Python and Google ADK. The agents use OpenAI models through LiteLLM, while MongoDB stores the product catalog and live stock observations gathered from scraping and scouring the web by a yet another agent + beautiful soup.

The frontend is a custom React and TypeScript chat interface. It connects directly to the ADK API and includes persistent chat history, delivery details, a mocked PayPal connection, and an order confirmation card.

The ingestion workflow discovers allowed public product URLs, queues background scraping jobs, and keeps the chat responsive while data is being collected.

Challenges we ran into

One of the biggest challenges was preventing the assistant from asking unnecessary questions while still avoiding unsafe or unusable recommendations. We addressed this with a brief-sufficiency policy: the agent asks only for details that materially affect suitability.

Another challenge was making purchase and monitoring flows reliable. The agent must not claim an item is available, a monitor exists, or a purchase was completed unless the corresponding tool confirms it. We also handled edge cases such as declined confirmations, unavailable products, and users changing their mind while setting up notifications.

Finally, we needed to coordinate several agents without exposing this complexity to the shopper. The orchestrator keeps the experience as one natural conversation while handing off work to the appropriate specialist.