AI assistant over a company's internal data: a RAG bot in Telegram with access tiers

Collection: merge by id

Chats are pulled in lanes and merged by message id. The reason is plain: a naive copy-over would wipe history on the first partial pull — the source returns only the last N messages. Voice notes go through whisper, screenshots through OCR, forwarded documents are indexed as their own sources. Everything ends up as text, and every chunk keeps a link back.

Editing a sent message now updates the record, and the previous wording is filed into an edit history. Deduplication by id used to throw the edit away wholesale: one team member's reply sat in the chat for 15 hours, and the truncated version led to the opposite conclusion.

Attachment intake: what actually reaches the base

Images sent as documents go to OCR. A PDF with no text layer is rasterized and read page by page, capped at 20 pages, with an honest note left in the extracted text. Archives are unpacked recursively through the same extractor, bounded at 60 files and 40 MB. Slide decks are supported. A video's audio track goes to the same speech recognizer as voice notes: a second bespoke call would create a second truth about how we transcribe speech.

The first run in production: 98 stuck attachments returned to the queue, 45 extracted immediately, 76 attachments outside working chats deliberately left alone. One archive yielded 573,572 characters, and 14 such archives were sitting in the queue. Two PDFs of 9.7 and 16.3 MB returned exactly 0 characters until page-by-page OCR. The intake loop knew only documents and photos, so 27 video messages slipped past the handler entirely, 15 of them in the owner's private chat. A live clip yielded 2,201 characters of product analysis.

Honest statuses: you can see what failed to land

Three of the four lost attachments carried the status "done": they looked delivered and showed up on no problem list anywhere. The status now names the reason — no text, PDF without OCR, video, unsupported format, size limit exceeded. The summary prints everything that failed to land, and the run finishes on a warning.

The commit to the database happens after every attachment. A single commit used to sit at the end of the whole cycle, so any interruption wiped the statuses back to zero.

"Empty" labels re-checked against the live files

All three labels turned out to be wrong: 12 "download failures" were hitting the size limit, 6 "videos with no audio" had audio, and 20 "no text" cases were hiding different problems entirely. One finding stood out — a leading-bracket check was discarding recognized text in its entirety: a table came back with 771 characters and landed in "no text" because OCR had clipped its first letter.

Access tiers with a single source of truth

Three tiers: owner — team — hub. They are implemented as an ACL over sources themselves. And here's the part that actually matters: the base has two consumers — the bot and a fact-distillation job — and the job's filter is separate code that will happily drift away from the bot's ACL.

So both sides call the same is_private_source function, and a guard test watches for drift: if someone introduces a second copy of the privacy logic, CI breaks.

The same principle holds up the "never index a screenshot with a password in it" guard. It was moved off how the messenger happened to file the attachment and onto the extraction type — and it was changed in the same commit as the intake work: two separate commits would have left a window in which screenshots containing keys were indexed.

Search: in-memory BM25 → SQLite FTS5

The first version kept the whole index in process memory. That was fine while the bot lived on a laptop. I moved storage to SQLite FTS5 with one deliberate twist: FTS5 is used purely as a postings store (via fts5vocab), while ranking stays custom.

The reason is concrete: FTS5's built-in bm25() returns a single scalar per document and hides the per-term detail. That detail is what the coverage factor runs on: how much of the query a document actually covers, kept separate from the weight it picks up on one frequent word. Handing ranking to the engine would have meant worse results.

The migration was made risk-free: the engine is switched by a single environment variable, old and new were run against the same queries, and the output was compared rank for rank. No differences — only the cost changed.

Answers come back whole

An empty response from the reasoning model is cured by a single retry with a budget of 8,000 tokens. Measured on a production prompt of 6,466 characters, the reasoning itself takes 400–700 tokens — and the worst answers were coming back on exactly the hard questions, with the main model working perfectly.

What got built on top of the base

The knowledge base turned out to be a platform. Living on top of it:

• Fact distillation — correspondence is collapsed into structured facts
• Morning digests and boards in a Telegram hub: business pulse, campaign pulse, infra pulse, tracker digest
• About twenty watchdogs on a "if it breaks, DM me and post to Discord" principle: CRM liveness, stuck orders, the chargeback protection window, an important message from the owner, index staleness
• An MCP server over the base — the owner's personal models see the same knowledge base, with no second pipeline

The whole collection pipeline moved off the laptop

The 20× memory drop paid for itself in practice. It's precisely what allowed moving the bot off a contractor's laptop onto a server with just 961 MB of RAM. The chronic "the laptop went to sleep, so the bot is silent at night" problem is gone at the root: it answers around the clock.

The mail followed. IMAP fetching of the mail corpus on the laptop is switched off, and the finished, parsed corpus is pulled from the server. The laptop was downloading 34 GB of raw mail to end up with 459 MB of parsed text; the server has been assembling the same corpus itself since late July, and its copy weighs 450 MB and is more complete. The laptop's disk was 98 percent full — 12 free gigabytes out of 460.

Switching the fetch off in one line was off the table: local tooling reads that corpus. So the pull works from an explicit file list — mirroring the whole directory with deletes would have taken other people's files with it — and the kill switch is read both from an environment variable and from a marker file, since a variable would only survive until the next reboot.

A separate guard protects the history: a file is replaced only when it is no shorter than the local one. On the very first production run the guard rejected the second mailbox (8,022 → 7,985) and prevented the silent erasure of 34 messages.

Along the way, a 103 MB index build was removed from the laptop: it was rebuilt 96 times a day and read by no consumer at all — the last-read time on both of its files matched the moment they were written.

The watchdogs live on the server

About twenty watchdog processes now run on the server under systemd timers. The launchd agents on the laptop are unloaded and renamed to a disabled form, and the rollback command is written down in the infrastructure journal.

A telling repair from the same pass: the messenger data-freshness watchdog spent six hours reporting "last updated 0 minutes ago" while the collector was dead. Parsing the output of the file-status utility was returning garbage, and garbage counted as zero age. The parse variants are now tried in order, and the result is checked for being a number in the first place.

Privacy: measured

You can argue about ACLs in the abstract for a long time. So I measured it on the live index: how many private chunks does the "team" tier actually reach? The answer was unpleasant — 1327.

After the ACL fix, the volume visible to that tier shrank from 6139 to 4560 chunks, of which private ones now number 0 — and no working data was lost. Separately, the access log was checked: it confirmed that no one had actually reached those chunks in the meantime.

What changed day to day

"What did we decide about this" is now a question to the bot, and it comes back with citations to specific messages — including ones that were originally voice notes. Morning digests arrive on their own, watchdogs speak up before a customer notices the problem, and the owner's personal models work against the same base through MCP — no second pipeline, no second copy of the data.