Ask anything about Westeros. Sight reads the full A Song of Ice and Fire saga — roughly 3,400 pages across five books — and answers grounded in the actual books, citing the exact title behind every claim and admitting plainly when the text simply doesn't say.

The same engine on a real support desk. Point Sight at a business's own policy documents — here a bank's — and it answers customers straight from those docs, cites the source, and escalates to the owner's inbox the moment it can't, so a human steps in.

Owner inbox (escalation)	Knowledge base	AI answering, with sources

Features

• RAG-grounded answers — hybrid retrieval (vector + BM25 + RRF) over each
  tenant's own documents; the AI cites their knowledge base, not the open web.
• Human-in-the-loop escalation — anything the AI can't answer lands in the
  owner's inbox with the AI's attempt for context; the reply relays back.
• Omnichannel — WhatsApp Cloud API, Telegram, and a built-in chat/dashboard,
  all behind one agent gateway.
• Multi-tenant by design — strict per-tenant isolation at the app layer plus
  Postgres Row-Level Security; per-tenant LLM provider/model/keys.
• Per-contact memory + cost accounting — the agent remembers key facts across
  conversations and tracks token spend per tenant.
• Bilingual UI — English + Arabic with full RTL, light/dark mode.

Start here

Architecture

flowchart TB
    subgraph channels [Channels]
        WA[WhatsApp]
        TG[Telegram]
        API[Chat API / Dashboard]
    end

    subgraph drivers [Drivers — entry points]
        WH[Webhooks]
        REST[FastAPI /api/v1]
    end

    subgraph ai [AI orchestration]
        GW[gateway.chat_with_agent]
        AG[Agent loop — LangGraph]
        TOOLS[Tools: search · escalate · key facts]
    end

    subgraph core [Application + Domain]
        UC[Use cases — CQRS]
        DOM[Rich entities + events]
    end

    subgraph infra [Infrastructure]
        PG[(PostgreSQL + pgvector + RLS)]
        RAG[Hybrid RAG — vector + BM25]
        LLM[Per-tenant LLM client]
        CH[Channel adapters]
    end

    subgraph ui [Frontend]
        SPA[React SPA — Mantine + TanStack Query]
    end

    WA --> WH
    TG --> WH
    API --> WH
    API --> REST
    WH --> GW
    REST --> UC
    REST --> SPA
    SPA --> REST
    GW --> AG
    AG --> TOOLS
    TOOLS --> UC
    GW --> UC
    UC --> DOM
    UC --> PG
    TOOLS --> RAG
    AG --> LLM
    GW --> CH

Dependency direction (backend): drivers → application → domain ←
infrastructure. The ai/ layer orchestrates by calling use cases — never
repositories or ORM directly. LangGraph is isolated to a single file:
backend/src/infrastructure/ai/graph.py.

Deeper dives: backend architecture ·
RAG pipeline ·
AI orchestration ·
channel integration ·
frontend architecture.

How it works

1. Owner registers and creates a tenant.
2. Uploads documents (PDF, DOCX, Markdown, plain text) — chunked,
   embedded, and indexed for hybrid retrieval.
3. Connects channels — WhatsApp and Telegram via the settings dashboard.
4. Contacts message through any connected channel.
5. AI answers using RAG over the tenant's documents.
6. Unanswered questions land in the owner's inbox with the AI's
   attempted answer for context.
7. Owner replies from the dashboard — the response relays back
   through the original channel.

The AI remembers key facts about each contact across conversations and
tracks token usage per tenant with full cost accountability.

Stack

Quick start

Docker (recommended)

Requires Docker + Docker Compose. Brings up Postgres (with pgvector), Redis,
the backend, the ingestion worker, and the frontend.

cp .env.docker.example .env.docker
# Edit .env.docker: set JWT_SECRET_KEY and ENCRYPTION_KEY (commands are in the file).
docker compose up --build
# Frontend: http://localhost:3000   API: http://localhost:8000

The backend container applies database migrations on startup, so the schema —
including the pgvector extension, which the first migration enables via
CREATE EXTENSION IF NOT EXISTS vector — is ready on first boot with no manual
step. The frontend is served by nginx, which reverse-proxies /api and
/webhooks to the backend, so the app talks to the API over the same origin
(no CORS, and the auth cookie stays first-party).

Then open http://localhost:3000 and register an owner account. To use document
ingestion and chat, add an LLM + embedding API key under Settings — keys are
per-tenant (stored in the database), so the RAG features light up once one is saved.

Local (without Docker)

Requires PostgreSQL 17 with pgvector, Python 3.13 with uv, Node 22+.

# Backend
cd backend
cp .env.example .env
uv sync --extra dev
createdb sight_db && psql sight_db -c 'CREATE EXTENSION vector;'
uv run alembic upgrade head
uv run uvicorn src.main:app --reload --port 8000

# Ingestion worker (second shell, same dir) — processes uploaded documents.
# Without it, uploads stay "uploaded" and never become "ready".
uv run arq src.drivers.jobs.worker.WorkerSettings

# Frontend
cd frontend
npm install
npm run dev    # http://localhost:5173 (Vite proxies /api + /webhooks to :8000)

Stuck on first run? See Troubleshooting for common fixes — pgvector, migrations, ports, the ingestion worker, and Docker resets.

Frontend highlights

• Bilingual UI (English + Arabic) with full RTL — language switcher in the
  app shell, self-hosted Arabic font, layout mirrors via Mantine's
  DirectionProvider. Backend API error messages localize via Accept-Language.
• Light / dark mode toggle.
• Unified DataTable — @adapttable/mantine via a thin app facade (@shared/components/datatable): sort, search, filter drawer + chips, paged & infinite modes, responsive desktop/mobile, URL-synced state, row actions with confirm modals, EN/AR labels, and mount animations.
• Route-level code splitting, path aliases, typed config, Prettier + strict
  TypeScript/ESLint.

Notes & current limitations

• Authentication is cookie-based. Login/register set an httpOnly
  sight_token cookie (the SPA never stores the JWT in JS, so it is not
  exposed to XSS). The API also accepts a Bearer token for programmatic
  clients (curl, scripts, the test suite).
• One tenant per user (v1). A user is currently resolved to their first
  tenant membership. Multi-tenant data isolation is fully enforced
  server-side, but a per-user tenant switcher is not built yet.
• /auth/refresh is a sliding-session re-issue, not a separate
  refresh-token grant: it mints a fresh access token for the already
  authenticated user. The JWT_REFRESH_TOKEN_EXPIRE_DAYS setting is reserved
  for a future refresh-token flow.

Documentation

Contributing

Contributions are welcome — bugs, features, docs, and tests. See
CONTRIBUTING.md for local setup, which checks to run, and
good first issues if you're looking for a
place to start.

License

This project is licensed under the MIT License.