WORK / AI WORKSPACE
AI Workspace
A unified AI workspace for startups: a RAG-powered support agent trained on your own documents, per-employee assistants, and the operational plumbing underneath.
ROLE
Co-building with Anubhab Das
STACK
Python · Django · FastAPI · React · LangChain · RAG · PostgreSQL · Docker · AWS
TIMELINE
Building — not yet launched
STATUS
Building
THE PROBLEM
Startups without a dedicated engineering team end up buying five separate tools for support, HR, and billing, none of which talk to each other, and none of which know anything about the company's own documents.
We wanted one workspace: a support agent trained on a company's actual docs (PDF, DOCX, TXT, or just a URL) with lead extraction and a public hosted URL for teams without a website, per-employee AI assistants, automated billing and HR tracking, and full conversation oversight for founders.
CONSTRAINTS
- —Multi-tenant from the start — every customer's documents and conversations have to stay isolated from every other customer's
- —Needs to work for a team with zero website — a hosted public URL has to be part of the product, not an add-on
- —Two-person team, so scope has to be sequenced, not built all at once
- —Founders need full conversation oversight without that turning into a second full-time job
ARCHITECTURE
Django handles the CRUD-heavy business logic — billing, HR, tenancy. FastAPI serves the RAG and agent layer. Per-tenant documents are ingested into isolated vector stores; the frontend is React, deployed on Docker.
- 01Django — auth, tenancy, billing, HR tracking
- 02FastAPI — RAG retrieval and agent serving, async by default
- 03Per-tenant ingestion — PDF / DOCX / TXT / URL, into isolated vector stores
- 04React — frontend for both the founder dashboard and the public-facing agent
- 05Docker — one service per container, deployed the same way as everything else I run
DECISIONS
1. Tenant isolation at the retrieval layer, not just the database
Row-level tenant IDs in Postgres aren't enough once a vector store is in the mix — a leaked retrieval means one customer's support agent could quote another customer's private documents. Isolation has to be enforced at the embedding and retrieval boundary itself, not just in the SQL layer.
2. Django and FastAPI, not one framework for everything
Django's batteries — admin, auth, ORM — are the right fit for billing and HR, which are CRUD-heavy and benefit from convention. The RAG and agent layer is a different shape of problem, async and LLM-call-heavy, where FastAPI's lighter footprint fit better. Running both costs more ops overhead, but each piece does the job it's actually good at.
3. Ship the support agent first
Of the four pieces — support agent, assistants, billing, oversight — the support agent is the one a prospective customer can evaluate in five minutes. Sequencing it first gets a demonstrable product in front of people before the harder-to-explain pieces are done.
RESULTS
4
Core modules in scope
2
Founders building it
Pre-launch
Current status
WHAT I'D DO DIFFERENTLY
I'd nail down tenant isolation testing before writing the first line of the retrieval layer, not after. It's the kind of bug that's invisible in a demo with one test account and very visible the day a second customer signs up.