Gem is a conversational product-discovery interface that helps a shopper describe what they need, clarify preferences, and explore relevant Amazon results inside a chat experience.
I designed and built the product end to end, then transferred the source code and intellectual property to the client. The client uses it for prospective-customer demonstrations and product research.
The delivered interface combines streamed conversation with product cards and filters in one shopping flow.
The Brief
Keyword search works when a shopper already knows what to type. Gem explored a different path: let someone explain the occasion, constraints, budget, or preferences in normal language, then refine the request through conversation before presenting products.
The build needed more than an LLM response. It required a customer-facing interface, a backend that could coordinate product tools, image input, result filtering and reranking, session state, persistent preferences, authentication, and deployable infrastructure.
What I Built
- A responsive Next.js shopping conversation with streamed text, tool progress, filters, and product cards.
- A FastAPI agent runtime for interpreting requests and coordinating product retrieval.
- Natural-language search that can ask follow-up questions about budget, category, use case, and preferences.
- Image input for visually guided product discovery.
- Filters for price, category, rating, deals, discounts, and other supported product attributes.
- Semantic reranking after product retrieval so results can be reordered around the shopper's request.
- Authentication and session handling through Clerk.
- Redis-backed short-term conversation state and a separate long-term preference layer.
- Dockerized delivery for a portable client handoff.
How the Agent Decides
The flow separates interpretation from product retrieval:
- The shopper describes a need or provides an image.
- The agent identifies missing constraints and can ask a focused follow-up question.
- Product tools retrieve candidate results and supported filters narrow the set.
- Cohere reranking reorders candidates by semantic relevance to the request.
- The application streams narrative text, tool state, and product cards through the same event channel.
This kept the model responsible for interpreting the request while the application remained responsible for product data, filters, state, and rendering.
Decisions That Mattered
Separate temporary intent from durable preferences
The last few conversation turns belong to short-term state. A recurring brand preference or stable shopping constraint may be useful later; a one-off gift search usually is not. A dedicated memory manager applied an explicit persistence policy so durable preferences stayed separate from transient requests.
Rerank after retrieval
Product retrieval supplied candidates. Semantic reranking then compared those candidates with the shopper's actual request. Keeping those stages separate made the behavior easier to inspect than treating a single search response as final.
Use one stream for the complete experience
Text, tool progress, and product cards can arrive at different times during an agent run. A single Server-Sent Events pipeline gave the frontend an ordered event model and allowed it to stay responsive while work continued.
Delivery
The delivered scope included the customer interface, FastAPI backend, agent and product-tool flow, image input, filtering and reranking, memory layers, authentication, Redis state, Docker configuration, and handoff documentation. The source code and IP were transferred to the client for its own demonstrations and research.
What I Took Forward
Shopping intent has different lifetimes. The architecture became clearer once current-session constraints, durable preferences, product data, and generated language were treated as separate kinds of state rather than one conversation transcript.
