An AI research-and-generation engine for marketplace sellers
A multi-tenant platform that researches a product and then generates listing copy and creative for it — LangChain orchestration, three vector stores and a direct marketplace API connector behind a FastAPI service.
- Sector
- Software vendor serving e-commerce marketplace sellers
- Engagement
- April 2025 – January 2026
- Python
- FastAPI
- LangChain
- Celery
- React
- Vite
- Redis
Context
For a marketplace seller the listing is the product: the main image, the supporting creative, the copy. Producing all of it per SKU is manual and repetitive, and it cannot start until someone has actually researched the product and its buyers. The engineering problem is not calling a model. It is holding what was learned about a product, keeping many generated outputs consistent with it, doing that for many tenants at once, and keeping long generation work off the request path so the interface stays usable while it runs.
What we built
Web app
The seller-facing product — 24 routes under src/pages/.
Agent backend
Orchestration, tool use, retrieval and generation, with long work moved off the request path.
Marketplace connector
Direct catalogue and seller data, separate from the scrapers.
Architecture
The backend is a FastAPI service with LangChain for orchestration, instructor for structured output, litellm for routing across model providers, and MCP for tool access. Retrieval is not one vector store but three — Pinecone, Qdrant and Chroma — behind the same service, which is the shape you get when different retrieval jobs have genuinely different latency and recall requirements rather than one being 'the' database. Long-running generation runs on Celery and Kombu workers, so a request never blocks on a model. Product data arrives two ways: scraped, via Apify, Selenium and BeautifulSoup, and direct, through an Amazon Selling Partner API client. State is Postgres through SQLAlchemy and Alembic alongside Supabase and Redis. Instrumentation is symmetric across the stack — Sentry and PostHog on both the browser and the server — so a failed generation can be followed from the click that started it. The front end is a React 18 + Vite application of 24 routes. Delivery ran through a tracked process: branches carry issue-tracker ticket identifiers, and the repositories use non-default working branches rather than committing to main.
Stack
- Web app
- React 18
- Vite
- Tailwind
- TanStack Query
- Zod
- Agent backend
- Python
- FastAPI
- LangChain
- Celery + Kombu
- SQLAlchemy
- Redis
- Marketplace connector
- Python
- Amazon Selling Partner API client
- Integrations
- OpenAI, Google Gemini and Cohere — model providers, routed via litellm
- Pinecone, Qdrant and Chroma — three vector stores behind one service
- Amazon Selling Partner API — direct marketplace data
- Apify — managed scraping alongside Selenium and BeautifulSoup
- Supabase and Redis — state, auth and queues
- Sentry and PostHog — errors and product analytics, browser and server
- SendGrid — transactional email
Scale
Counts that can be re-derived from the same repositories. Nothing here is a business result — a repository cannot evidence one.
- 1,524 commits across three repositories (950 + 564 + 10).
- 285 dependency entries in the agent backend's requirements.txt.
- 3 vector stores behind one service.
- 24 web routes.
Where the evidence stops
- The product's own generation logic is not described — only the architecture around it.
- No business outcome is claimed.
Evidence
Each statement above, and the artefact it was read from. The client cannot be named, so the sources are given instead.
1,524 commits across three repositories.
Sourcesum of history.totalCount on each repository's default branch (950 + 564 + 10)
285 backend dependency entries in requirements.txt.
Sourcerequirements.txt in the agent backend repository
3 vector stores — pinecone, qdrant-client and chromadb.
Sourcebackend requirements.txt
24 web routes.
Sourcesrc/pages/ directory listing in the web application repository
14 distinct commit-author accounts on the front end, 9 on the backend.
SourceGitHub contributors API (anon=1) — a count of author identities, not a team size
Engagement span: 2025-04-01 → 2026-01-16.
Sourcefirst and last commit dates on the default branches
Related capability