An AI agent fleet that owns the supply side of a DTC supplement brand — the work that would otherwise require a team of buyers, category managers, and catalog analysts running daily.
The Problem
Hewyn sells 4,700 supplement products via dropship to the UAE. At that catalog size, three things become impossible to do manually:
Pricing. Competitor prices on iHerb and Amazon.ae change constantly. Without daily checks, you’re either leaving margin on the table or losing to a competitor on price without knowing it.
Product discovery. New SKUs to add were reviewed every 28 days. That’s stale by the time anyone acts on it. Brand catalogs update continuously.
Catalog health. At 4,700 products, quality drift is invisible unless you check systematically. Missing images, short descriptions, no reviews — individually small, collectively they compound into lost conversion.
The alternative is a team of buyers and catalog analysts. A team costs salary. The harder constraint is cognitive: no one holds 4,700 products in context simultaneously. An agent doesn’t forget what it checked yesterday.
The Approach
I built 11 agents organized into three operational layers:
Scheduled daily (GitHub Actions, 09:00 GST):
- competitive_monitor — Scrapes competitor pricing across iHerb and Amazon.ae for the catalog. Writes results to Redis (
fleet:price:{product_id}) with a TTL so stale prices don’t persist. - stock_strategist — Flags OOS and low-stock SKUs, recommends reorders based on sales velocity and supplier lead times.
- analyst — Per-product performance review: winners, losers, and margin outliers.
- category_reviewer — Portfolio-level view: which categories are over- or under-represented versus actual demand. Writes to
fleet:portfolio:report. - pdp_cr_scanner — 13 heuristic quality checks per product: images, bullet points, reviews, schema markup, FAQ sections, dosage tables, trust badges, and more. First run flagged 49 issues across 5 products, roughly half auto-executable.
Scheduled weekly (GitHub Actions, Sunday):
- product_finder_pipeline — Discovers new SKUs to add from brand catalogs.
- amazon-ean-scan — Cross-matches the Hewyn catalog to Amazon.ae by EAN. After a rewrite to direct HTML scraping with UA rotation and retry logic, match rate is 90% at 99% accuracy.
On-demand (triggered from the dashboard UI):
- scout → validator → builder — Full discovery pipeline: find a candidate product, validate it meets quality gates, create a Shopify draft listing.
- optimizer — Generates specific fixes for flagged catalog health gaps.
- coordinator — Merges outputs from prior agents into a single
ProductActionCardfor human review.
The Cross-Agent State Problem
The agents need to share state without coupling to each other. The competitive monitor needs to write prices that the merchandising fleet can read. The discovery pipeline needs to persist failed attempts for retry. The coordinator needs to merge outputs from multiple prior agent runs.
The solution is Upstash Redis as the shared data plane, with typed key namespaces and TTLs:
fleet:price:{product_id} → competitive pricing (24h TTL)
fleet:discovery:{brand} → new SKU candidates
fleet:asin_backlog:{brand} → failed ASIN lookups (30d TTL, retry queue)
fleet:created:{sku} → auto-created products (dedup guard)
fleet:portfolio:report → category balance analysis
fleet:pdp_cr:report → quality check results
TTLs mean no stale state persists across workflow cycles. The 30-day backlog TTL on failed ASIN lookups gives a future retry worker a window to resolve misses without holding them forever.
ASIN Resolution
Matching our catalog to Amazon.ae by EAN was harder than it sounds. The original approach used an API aggregator that covered ~13% of lookups. The fallback chain I built now runs:
- Regex match on known ASIN patterns
- Serper (Google) search with redirect parsing
- APIGuru US catalog
- APIGuru AE catalog with brand + Jaccard similarity validation
The rewrite to direct Amazon.ae HTML scraping with UA rotation and 503/429 retry reduced the ASIN miss rate from 87% to a projected 20-35%.
Auto-Execute Path
Products that pass a quality gate (≥3 images, ≥200 character description, ≥3 tags) can be automatically added to homepage collections. These are written as completed fleet tasks with auto: true so the merchandiser sees what was done rather than being asked to approve things that clearly meet the bar.
Catalog health gaps route to the right team: image gaps generate a design team task with pickShotsNeeded(N), content gaps go to the AI-executable queue for the optimizer agent.
Key Decisions
-
GitHub Actions for scheduling, not a server. The fleet runs on a schedule with no persistent infrastructure. GitHub Actions with
continue-on-errorand 60-minute timeouts means one agent failure doesn’t block the rest. A Slack summary fires at the end of each run. Zero idle cost. -
Redis over a database for cross-agent state. The agents are ephemeral — they run, write their output, and exit. A database would require schema management, connections, and migrations every time the fleet evolves. Redis with typed key namespaces and TTLs gives the right semantics: data persists long enough to be consumed, then expires.
-
Typed key namespaces with TTLs over a shared blob. Without TTLs, stale pricing data from last week would look identical to today’s data. Each key type has a TTL matched to how long its data is actually valid.
Scale
- 11 agents across 3 operational layers
- 4,700 products monitored daily for pricing, stock, and quality drift
- 13 PDP quality heuristics, ~49 issues detected on first run
- 90% ASIN match rate to Amazon.ae after EAN cross-match rewrite
- Zero infrastructure cost — runs entirely on GitHub Actions
Built for Hewyn (hewyn.com), a DTC supplement brand in the UAE. Agent architecture and Redis key structure shown.