Why one more AI platform exists
Most enterprise AI platforms either lean on a single LLM vendor's hosted assistants (lock-in, limited audit, opaque pricing) or require gluing together five separate services (auth, vector DB, workflow runner, billing, audit) before the team can ship even a basic assistant. Multi-tenancy is usually a layer of app code with no defense-in-depth — a single missing WHERE clause leaks every tenant's data.
We built this platform to be the AI control plane we wanted ourselves: one console for assistants, knowledge, connectors, workflows, analytics, audit and billing; hard tenant isolation that survives an app-layer bug; auditable, prompt-cached LLM calls with zero vendor lock-in; and a Phase-1 surface small enough that two engineers can deploy it in a week. Phase 2 layers RAG, on-prem connector agents, billing and the admin console UI on the same foundation.
Key pain points
- ✕Single-vendor AI consoles offer no audit, no eval, no observability beyond the vendor's own metrics
- ✕Multi-tenancy enforced only at the app layer leaks every tenant on a single missing WHERE clause
- ✕Stitching auth + vector DB + workflow runner + billing + audit takes weeks before the first assistant ships
- ✕Prompt caching, RBAC, and tenant-scoped audit logs are missing from most off-the-shelf AI back-ends
- ✕On-prem / private-VPC connector requirements force a self-hosted bolt-on that breaks the SaaS console
What we built
Phase 1 ships a FastAPI + SQLAlchemy 2.0 + Alembic backend on PostgreSQL 16, with the app connecting as a non-superuser DB role (`swenivis`) that owns the tables. FORCE ROW LEVEL SECURITY keeps even that owner subject to the policies — point the app at a superuser and RLS is bypassed, so the deploy guide explicitly forbids it. Every query also passes through an app-layer tenant filter for defense-in-depth.
Auth is JWT (PyJWT) + passlib/bcrypt with full RBAC. Inference is Anthropic Claude with prompt caching — `claude-sonnet-4-6` for the default chat path, `claude-opus-4-8` for complex queries — and every call is logged with token counts, latency, and tenant context for the Analytics + Billing modules to read.
The Next.js 16 console wraps 13 modules: Overview, Assistants, Chat, Knowledge, Connectors, Workflows, Analytics, Audit, Billing, Users, Tickets, Tests, Settings. The Tickets + Tests modules let the customer's own support and QA team work inside the same tenant without a separate tooling deploy.
Technology stack
Backend
Database
AI
Console
Tooling
Key engineering decisions
Tenant isolation in two layers — not one
App-layer filters get every query a tenant_id WHERE clause. PostgreSQL FORCE ROW LEVEL SECURITY enforces it again at the engine, with the app connecting as a non-superuser role so even the table owner is subject to the policies. A bug in either layer doesn't leak data — and we have a Pytest suite that flips one off at a time and asserts the other still holds the line.
Phase 1 surface scoped to deployable in a week
Out of scope for Phase 1 (and explicitly noted in the README): RAG / Pinecone, connectors + on-prem agent, admin-console UI, billing, analytics deep-dive, Terraform / EKS infra, CI/CD. Those land in Phase 2 on top of the same auth + tenancy + audit core — so the platform ships value immediately instead of waiting for everything to be 'done'.
Prompt-cached Claude over a model-router abstraction
We picked Anthropic Claude with prompt caching as the default inference path — Sonnet 4.6 for chat, Opus 4.8 for complex queries — instead of building a model-router. The router can come later when a customer asks; in the meantime, prompt caching gives the same cost win without the abstraction tax.
The results
Swenivis AI Chatbot Intelligence Platform is live at ai.swenivis.com and powers our internal assistants today. Phase 2 (RAG / Pinecone, on-prem connector agents, billing, admin console UI, Terraform/EKS infra, CI/CD) is the next milestone and reuses the same auth + tenancy + audit foundation. If you need an enterprise AI control plane built — multi-tenant, audit-ready, with hard isolation guarantees you can show your security team — we can deploy this for you in a week and extend it for your specific connector + workflow needs.
From our founder
Most enterprise AI offerings either lock you into a single vendor's console or leave you assembling auth, isolation, audit and billing yourself. We built this platform because we wanted a control plane our customers could run on their own infrastructure with security guarantees their CTO would sign off on. Phase 1 is small, opinionated, and deployable in a week — and the Phase 2 roadmap is in the codebase, not a slide deck.
Need a custom HRMS or similar product?
We can adapt this codebase to your organisation's requirements, or build from scratch to your specification.
Book a discovery callMore engineering work
