Agentic Commerce
AI shopping solutions need a relevance layer, not necessarily a bigger brain
Brute force is fine when it's small enough to run on the customer's own laptop or phone.
Fighting jet lag in beautiful Carmel-by-the-Sea (Prague → SFO, a 9-hour time shift is brutal), I spent a few hours wrapping up my experiments with self-hosted agentic commerce.
Everyone is building shopping agents… OK, not everyone, but plenty of people are. And everyone is crazy about Jev.
Why? Because agents keep recommending a rainbow-LED gaming keyboard to someone who asked for a quiet home office, and Jev promises a judge that catches exactly that.
Let's be honest about what that is: brute force. Every customer × every product goes to a model and gets judged from scratch. Compared to old-school machine learning, which slowly fits a model to customer behaviour (clicks, purchases, returns), it's a completely different bet. Brute force might be smart or it might be stupid. That's not the topic of this experiment.
So I asked a different question:
Can a retailer answer "how relevant is this offer for this person?" on its own, without burning billions of tokens?
Turns out, yes. It's still brute force, but here's why that's OK: it's small enough to run on the retailer's own server, and potentially on the customer's own laptop or phone. Brute force stops being a problem when it's this cheap.
So now there are three bets on the table:
- Old-school ML: learn the customer from behaviour over time
- Cloud judge: brute-force every pair through someone else's model
- Self-hosted relevance layer: brute-force cheaply on your hardware, or the customer's, with rules doing the heavy lifting
Three bets on the table. The highlighted one runs on your hardware, or the customer's.
Here's how the third one works.
The job
Input: a buyer persona (budget, must-haves, things they hate) and a product card.
Output: a score from 0 to 1, plus the reason: "over budget", "wrong category", "gamer aesthetic, customer avoids it".
The shopping agent calls this as a tool before it reasons over a single product. The agent handles the conversation. The relevance layer decides what's worth talking about.
The architecture: three cheap stages instead of one expensive call
Stages 1 to 3 fit on a laptop, and are close to phone-class.
1. Hard rules, and only truly hard ones
Budget. Product category, matched against the shop's real category tree rather than keywords. Fail one of these and the product scores 0 with a reason code. Deterministic, auditable, instant, and zero tokens.
2. Two small models in parallel
- A compact local relevance model (4B parameters) scores how well the product fits the persona.
- A tiny embedding model scores how close the product is to the things the customer explicitly doesn't want.
3. Calibrated fusion
Final score = fit − penalty(avoid-risk). The penalty curve is tuned per persona with three knobs, so the system can be strict for a minimalist and relaxed for a gamer.
The whole thing runs locally. No per-call token bill, and no customer data sent to a third party.
And it's small: deterministic rules, a 4B model and a tiny embedding model. That's laptop-class today and close to phone-class. Run it on the customer's device and the persona never leaves their pocket at all.
Does it hold up?
Mean F1 on the 3-persona core set. The dashed line is the 0.85 pass bar.
I tested it on hand-labelled Alza.cz products across 5 very different shoppers: a quiet home office, an RGB gamer, a Mac photographer, a budget student and an ergonomic coder.
- Mean F1 of 0.92 across the 5 personas
- ~100% of junk products rejected (wrong category, wrong budget, wrong vibe)
- 0.86–0.89 F1 on products the system never saw during tuning
- On the same task, it scored higher than calling a cloud judge directly (0.91 vs 0.84 on the core 3-persona set)
The local model on its own scored 0.79. The architecture added the rest.
What I learned building it
1. Hard rules must be truly hard.
My first version turned "avoid RGB" into a keyword filter. It threw away good products and recall collapsed. Budget and category are facts. Taste is not.
2. Taste is a penalty, not a veto.
"No gamer aesthetic" belongs in a soft, tunable score. Then a white keyboard with subtle backlighting can still make the list.
3. Calibration beats complexity.
I tried adding stages: multiple avoid profiles and a "second look" for borderline items. Both measured as no-ops, so they're out. Tuning one penalty curve per persona did more.
4. Structure beats brain size.
Swapping a cloud judge into the same pipeline didn't improve it. The win came from splitting the decision into crisp rules, a fit score and a taste penalty.
Why this matters for agentic commerce
Agents are becoming the new storefront. Whoever controls what the agent is allowed to recommend controls conversion, returns and trust.
Retailers shouldn't rent that layer. It touches their most sensitive data (customer intent), their most valuable asset (their catalogue) and their brand (what gets recommended). It should be:
- Self-hosted, edge-ready: runs on your servers, and small enough to move onto the customer's device
- Catalogue-aware: built on the shop's own taxonomy
- Explainable: every rejection has a reason code
- Agent-agnostic: one tool over HTTPS, MCP and A2A, so any agent can call it
Brute force or behaviour-fitted ML, that debate isn't settled. But brute force small enough to run on a phone changes the economics, and the privacy story, completely.
The agent chats. The relevance layer decides.
Early results from a jet-lagged experiment on a small hand-labelled set, not a benchmark. Happy to compare notes with anyone building in agentic commerce. get in touch.
#AgenticCommerce #AIagents #Ecommerce #SelfHosted #MCP #Retail