work · scancart
ScanCart.ai
Parallel multi-agent trust scoring for Indian e-commerce
Solo: extension, backend, agents · 2026
Problem
Shoppers on Indian marketplaces can't easily tell a fake product or a paid review from a real one. ScanCart runs checks on a listing and gives one Trust Score with the reasons behind it.
In short
- -Six specialist agents run in parallel (reviews, ratings, seller, price, quality, alternatives); a compliance agent then uses the seller and price results.
- -Latency equals the slowest check, not the sum: parallel fan-out cut scan time 2.8× (13.7 s of sequential model time → 4.8 s).
- -Failed checks are left out of the score and shown as "X of 7 checks", never guessed. With one agent hung, 100% of scans still scored.
- -JMeter at 50 concurrent users: 200/200 scans OK with no latency increase over a single user.
- -Pitched at Rajasthan AI Builders Pitch-a-Thon 2026.
Architecture
A Chrome MV3 extension sends the listing to an Express backend, which fans out six Claude agents in parallel, runs a compliance agent on their results and combines all seven into a weighted score.
- user
- client
- guard
- ai
- service
- data
- call
- ← scroll →
- 01Extension extracts the listing from the product page
- 02Express backend fans out 6 specialist agents in parallel, then runs the compliance agent
- 03Each check returns a score plus a source
- 04Failed checks are dropped; the rest are weighted into one Trust Score
- 05Extension shows the score, reasons and "X of 7 checks"
Decisions
+ Parallel fan-out of independent checks- A sequential agent chain The checks don't depend on each other, so parallel calls cut latency to the slowest one.
+ Model id from an environment variable (default Haiku 4.5)- A hard-coded model id A retired model id once broke the backend; config makes swaps a one-line change.
+ All model calls from the backend- Calling the API from the browser Keeps the API key off the client.
Failure handling
One or more checks time out or error
Excluded from the score; the UI shows how many checks ran.
Demo data could look like a real scan
Every result carries a source so demo data is labelled.
- user
- client
- guard
- ai
- service
- data
- call
- ← scroll →
- user
Shopper opens a product page
- client
Chrome MV3 extension
content script extracts the listing
- guard
Express API
Zod validation · rate limiting · Helmet · API key stays server-side
parallel ×6 · parallel fan-out · per-agent timeouts · one failure can't break a scan
aiReviews
aiRatings
aiSeller
aiPrice
aiQuality
aiAlternatives
- ai
Compliance agent
uses the seller and price results
- service
Trust Score fusion
weighted score
failed checks left out and shown as "X of 7 checks", never guessed
output
clientVerdict card in the extension
score + reasons
clientReact dashboard
scan history
A sequential agent chain
Parallel fan-out of independent checks
The checks don't depend on each other, so parallel calls cut latency to the slowest one.
A hard-coded model id
Model id from an environment variable (default Haiku 4.5)
A retired model id once broke the backend; config makes swaps a one-line change.
Calling the API from the browser
All model calls from the backend
Keeps the API key off the client.
One or more checks time out or error
Excluded from the score; the UI shows how many checks ran.
Demo data could look like a real scan
Every result carries a source so demo data is labelled.
Numbers
6 + 1
Agents per scan
2.8×
Faster than running checks in sequence
13.7 s → 4.8 s
200/200
Scans OK at 50 concurrent users
100%
Scans still scored with one agent hung
Load tests
JMeter 5.6.3 against the Express backend with all seven agents; Claude replaced by a mock server answering in 1–3 s per call.
Baseline
1 user × 20 scans
Avg 4.8 s vs 13.7 s total model time per scan: 2.8× faster
Concurrency
50 users × 4 scans
200/200 OK, avg 4.76 s (same as 1 user), p95 5.8 s
Hung agent
Review agent never answers, 20 scans
20/20 still scored in ~12 s (10 s timeout, then fallback)
Validation
50 bad payloads
50/50 rejected with 400
Rate limit
120 calls from one client
100 allowed, then 429
Next
- ○ Labelled eval set of real vs fake listings
- ○ Cache repeat scans of the same listing