Why I'm building buyer agents for marketplaces

Online marketplaces have a search problem. Not the kind where you can't find results, but the kind where you find too many. Search for a used MacBook Pro on eBay, Facebook Marketplace, and Mercari, and you'll get hundreds of listings. Most are overpriced, some are scams, and the good deals are buried on page four. All the work of filtering and comparing falls on the buyer.

This is the problem I'm working on with Quoril. The idea: instead of making buyers search harder, give them an agent that does it for them.

Why keyword search isn't enough

Marketplace search is keyword-based. You type "MacBook Pro 14 M3" and the platform returns listings with those words. But what you really want is more specific: good condition, fair price, reputable seller, maybe local. That level of intent doesn't fit into a keyword box.

LLMs make it possible to close that gap. We can now build systems that understand what a buyer actually wants from a plain English description and evaluate whether a listing is a real match.

What a buyer agent looks like

A buyer agent goes beyond search. Given something like "I need a reliable used laptop for school under $800," the agent can:

Buying isn't a single query. It's a workflow: search, evaluate, compare, decide. A good agent handles the full thing.

Why now

Two things make this work today. LLMs are good enough at structured reasoning to evaluate listings against nuanced criteria. And inference costs have dropped enough to make running a model over hundreds of listings per query economically viable.

On the demand side, resale marketplaces are growing fast. More inventory means more noise, and the platforms are optimized for sellers (who pay fees), not buyers.

What I've learned so far

Building Quoril has mostly been about managing the gap between what LLMs can do in a demo and what they do reliably in production. Parsing listing data across platforms is messy. Getting consistent price estimates takes more than a prompt. And latency matters. Nobody wants to wait 30 seconds for results, even if they're better.

The architecture I've landed on is a pipeline: fast retrieval first (keyword search plus embeddings for candidate generation), then LLM evaluation and ranking on the shortlist. It keeps costs and latency reasonable while using language model reasoning where it counts.

We haven't launched yet. Still building. I'll share more as the system matures. If you're curious, check out getquoril.com.