LUXE WEAR AI

Overview

Luxe Wear AI lets a business create an AI agent, teach it from its own documents, and put it in front of customers — without writing any machine-learning code. It started from a concrete idea, an AI stylist for fashion brands, and grew into a multi-tenant platform: many organizations, each with its own agents, knowledge and usage, sharing one deployment.

I own the product and the client application; the backend is a separate service built by the team.

The problem

A generic chatbot invents answers. A useful business assistant must answer from that business's catalog, policies and tone, keep one customer's data away from another's, and show the owner what is happening. That translates into three engineering requirements: retrieval-grounded answers, hard tenant isolation, and visibility.

Architecture

How an answer is produced (RAG)

1. The user's message is embedded with the multilingual-e5-large model (1024 dimensions), which works well for mixed Vietnamese/English content.
2. The embedding and token count are computed in parallel and cached.
3. Pinecone returns the top five relevant chunks, filtered by tenant, user and — when set — the specific agent, so knowledge never crosses organizations.
4. If an agent-filtered search finds nothing (for instance, knowledge that is linked but not yet indexed), a fallback search widens to the tenant's general knowledge and keeps only what belongs to that agent or is unscoped.
5. The retrieved chunks are injected into the prompt and Gemini generates the reply, with citations back to the source documents.

Uploads are processed as a stream and re-indexed by background jobs, so a large PDF does not block the request.

The client application

Built with Next.js 14 App Router and route groups that separate three experiences:

• Public – marketing home, a five-tier pricing page (Free to Enterprise) with a monthly/yearly toggle, and login/register.
• Docs – MDX-based guides such as "Build your first agent", plus integration pages for Shopify, Webflow, WordPress and custom sites.
• Authenticated app – the dashboard: agent grid with search, sorting and pagination; agent creation and editing; a streaming chat view; a knowledge base manager; analytics; usage; workspace and tenant settings; and an admin area for users, tenants and agents.

Frontend decisions

A strict service layer. Components never call fetch or Axios directly. Every endpoint lives in a typed service on top of a single HTTP client that handles refresh tokens, so auth behaviour is identical everywhere.

Redux for the stable core only. Redux Toolkit with Redux Persist holds the session and the active tenant; everything else is local state or hooks (useAuth, useTenant, usePagination), which keeps components presentational.

Forms as schemas. React Hook Form with Zod gives one validation definition per form, shared by types and error messages.

Documented UX contracts. A feature matrix and a tenant implementation guide describe each screen's states (loading, empty, error), so the multi-tenant flows stay consistent as the app grows.

Platform capabilities behind the UI

Tenants and roles with membership checks on every request; Google and GitHub sign-in; rate limiting; request logging; webhooks with signature verification; an embeddable chat widget served per agent; and Model Context Protocol (MCP) support for connecting agents to external tools.

Trade-offs

The UI mixes Shadcn/Radix with some Ant Design components, which speeds up tables and pickers but requires care to avoid style conflicts. Streaming chat and tenant-aware caching add moving parts that need disciplined state handling.

What I took away

RAG quality is mostly a data and filtering problem, not a prompt problem: scoping retrieval correctly by tenant and agent mattered more than any wording change. And in a SaaS, the "boring" parts — roles, usage, empty states — are what make the product feel trustworthy.