Conversational RAG agent over Telegram that queries my Google Drive documents (real-estate, insurance, contracts) and automatically indexes new collections. Multi-workflow n8n architecture: Telegram orchestrator + idempotent ingestion pipeline (Postgres + Qdrant) + hybrid metadata + semantic RAG agent.

When I bought my apartment (October 2024), my Google Drive ended up flooded with paperwork: notarial deed, mortgage, insurance contracts, condo association meetings, renovation invoices. Finding a specific piece of info ("what's the water-damage deductible?", "next condo meeting date?") quickly became painful: open the PDFs, scroll, hope.
Goal: a conversational RAG agent over Telegram that queries my indexed documents and automatically updates the collection when I drop new files in Drive. Designed generic from day one: 1 Drive folder = 1 RAG collection parameterized by name. Today a single rag_appart folder gathering all the apartment's paperwork (mortgage, insurance, condo meetings, contracts, manuals); tomorrow a rag_societe or another context if needed, without rework.
My role: end-to-end design and development of the multi-workflow n8n architecture (orchestrator + 2 sub-workflows), self-hosted deployment.
Telegram bot accepting text or audio (LLM transcription), with a router AI Agent that dynamically selects between 2 tools: RAG search or indexing of a new folder. Per-chat conversational memory.
Technical challenges: multi-modal input (text + voice), reliable routing to the right sub-workflows depending on the query, stable per-user memory without cross-chat leakage.
Solutions: n8n Switch on message type (text vs voice), AI Agent with a strict system prompt defining the 2 tools and their use cases, sub-workflows exposed as n8n Tool Workflow (callable as functions by the agent).
Indexing workflow with 3 triggers (form, webhook, sub-workflow) that scans a Google Drive folder, detects new/modified files, chunks them, generates embeddings and persists into Qdrant. Metadata enriched by an LLM summarizer (theme, topics, painPoints, keywords).
Technical challenges: avoiding unnecessary re-embedding on every run (cost), cleanly removing modified files from Qdrant, supporting multiple formats (PDF, DOCX, native Google Docs), dynamically creating Postgres tables and Qdrant collections per folder.
Solutions: per-collection Postgres metadata table with reference dates, Drive vs Postgres comparison → skip if unchanged, otherwise delete by metadata.fileId in Qdrant + reinsert; mimeType switch to plug in the PDF or DOCX extractor; 800/100 chunking; tables and collections named after the folder to silo each domain.
Sub-workflow answering user questions in 2 stages: first target collection validation (a mini-agent checks it exists, otherwise asks for clarification), then hybrid search (a main agent first queries Postgres metadata to identify relevant documents, then runs the Qdrant semantic search filtered on the retained fileIds).
Technical challenges: avoiding the noise of pure semantic RAG (off-topic chunks matching by embedding alone), guaranteeing source traceability in the answer, hardening the JSON output despite LLM hallucinations.
Solutions: pre-filtering by structured metadata (theme/topics/keywords) before the semantic search, structured output {message, sources: {documents, themes, keywords}} with systematic file citations, auto-fixing parser via the LangChain OutputFixingParser pattern (a secondary LLM, Claude Sonnet, reformats the JSON output when the primary LLM produces an invalid format).
rag_appart collection: ~30 documents indexed (notarial deed, mortgage, insurance contracts, condo association meetings, appliance manuals, renovation invoices)