Why a PDF summary is often not the end of the conversation
A structured summary is the fastest way to get the gist of a long PDF, but the moment you have specific follow-up questions — "what's the exact deadline in section 4," "does this contract mention a non-compete clause," "what was the sample size in the study" — a bullet-point summary is the wrong shape for the answer. You either re-read the whole document yourself, or you paste the relevant paragraph back into the bot as a new message and hope it has enough context to answer well. Chat-with-PDF closes that gap directly: once @vustSummaryBot has already summarized a PDF-document upload, a single button tap arms a short follow-up Q&A mode on the exact text it already extracted, so a specific question gets a specific, grounded answer instead of a second full summary.
This is deliberately scoped as a lightweight follow-up, not a full document-chat product. It rides on the same extracted text the summary was built from and closes after a short bounded window. The bot shows the current Balance charge before a paid question is accepted.
How @vustSummaryBot's PDF pipeline actually wires this up
To be precise about the mechanics rather than hand-wavy about them: @vustSummaryBot's PDF-document upload path (packages/summary-telegram/src/pdf-extractor.ts) extracts the text layer from an uploaded PDF file and runs it through the normal summarization pipeline. When that specific path succeeds — the extraction status the handler checks internally is pdf_document, meaning a real PDF file was uploaded and read directly, not a link to a PDF fetched some other way — the delivered summary message gets one extra row appended to its keyboard: "💬 Ask about this PDF." No other source type (plain text, a URL, a YouTube link, a forwarded message) shows this button; it only appears on a PDF-document summary's own result screen, appended after the normal feedback/share, format-switcher, and retry/delete rows, so every other summary type's layout is completely unchanged.
Tapping the button "arms" a per-user flag stored in the same result_context mechanism the bot already uses for other short-lived state (the same table backing the "long YouTube video, pick a format" quote flow). The row is keyed to your Telegram user ID, holds the extracted document text (truncated to a hard cap if the original was very long), and tracks two things: whether you're currently armed for a question, and how many of your 3 allotted questions you've already used. Once armed, the very next plain-text message you send to the bot is treated as a question about that document — not as a new summarization request — right up until you hit the 3-question cap or the 30-minute window from the original summary's delivery closes.
The 30-minute window, explained honestly
The 30-minute clock starts at the moment the PDF summary was delivered, not at the moment you tap the button. If you summarize a PDF, get distracted, and come back 40 minutes later to tap "Ask about this PDF," you'll get an honest "Session expired — please resend the PDF" message rather than a stale or confusing partial state. This is a deliberate design choice: extending the window every time you tap the button would let a single document's extracted text sit around indefinitely, which isn't necessary for what is meant to be a quick, in-the-moment follow-up rather than a persistent document-chat session. If you need to ask questions about the same PDF again later, resending it and getting a fresh summary re-arms the whole flow with a new 30-minute window.
The 3-question cap, and why it's not just an arbitrary number
Each accepted question calls the same underlying AI model @vustSummaryBot already uses for summarization, with the extracted document text plus your specific question. The bounded document window limits total provider work without presenting a paid-plan attempt allowance. Once the window closes, the bot asks you to start a new summary; a rejected question consumes no paid value.
What the answers are actually grounded in
Every answer comes only from the text @vustSummaryBot already extracted from your PDF when it built the original summary — not from general world knowledge, not from search, and not from the summary text itself (which would compound any information loss from the summarization step). If your question asks about something the document doesn't cover — a page that was truncated out of a very long PDF, or simply a fact the document never states — the bot is instructed to say so honestly ("not found in this document") rather than guess or extrapolate. This grounded-only behavior matters most on documents where getting a wrong answer would actually cost you something: a contract's exact notice period, a study's precise sample size, a policy's specific coverage limit. A confident-sounding wrong answer on any of those is worse than a bot that says it doesn't know.
A worked example: from summary to three follow-up questions
Below is a realistic, condensed version of what the flow looks like end to end, using a hypothetical 22-page SaaS vendor contract PDF as the source document.
Summary excerpt (what @vustSummaryBot delivered first):
• This is a 12-month SaaS subscription agreement between the customer and the vendor, auto-renewing unless cancelled. • Payment terms: net-30 invoicing, quarterly billing cycle, 1.5% late fee per month on overdue balances. • Data handling: vendor stores customer data in EU-region servers, retains it for 90 days post-termination, then deletes it. • Liability is capped at 12 months of fees paid; the agreement excludes consequential damages. • Either party may terminate for cause with 30 days' written notice and a cure period.
Question 1: "What's the exact notice period if I want to cancel without cause?" Answer: "Not found in this document. The excerpt only specifies a 30-day notice period with a cure period for termination for cause — it does not separately address a without-cause cancellation right or notice period."
Question 2: "Where is customer data stored, and how long is it kept after the contract ends?" Answer: "Customer data is stored on vendor servers in the EU region. After termination, the vendor retains the data for 90 days before deleting it."
Question 3: "Is there a cap on how much the vendor can be sued for?" Answer: "Yes — liability is capped at the equivalent of 12 months of fees paid under the agreement, and the agreement excludes consequential damages."
Notice the shape of these answers: specific, sourced directly from the extracted text, and — in the first case — explicitly honest about what the document doesn't say rather than inferring a plausible-sounding number. That's the entire point of grounding the answer in the document text instead of letting the model reach for a generic, plausible-sounding "usually 30 or 60 days" guess.
What this is not
This is not a persistent, multi-document chat assistant, and it's not a substitute for reading a document you need to act on legally or financially — treat answers the way you'd treat a fast, literal-minded research assistant: good for pulling a specific fact out of a document you've already reviewed at a summary level, not a replacement for your own judgment on anything consequential. It's also not available on every summary source type in the current version: it only appears after a PDF file is uploaded directly to @vustSummaryBot and summarized through that document-upload path. A PDF reached via a URL link goes through a different extraction path in the current build and does not currently show this button — if that's your use case, summarizing the same document as a direct file upload is the way to unlock chat-with-PDF on it today.
What happens if a question fails partway through
Every accepted question follows the bot's ordinary paid-result recovery contract. If the underlying AI call fails — for example because of a transient provider error or timeout — the bot must not claim successful consumption. Delivery uncertainty follows the same refund or Payment Support path used for paid summaries, so chat-with-PDF does not introduce a less careful money-handling path.
How this fits with the rest of @vustSummaryBot
Chat-with-PDF deliberately reuses everything the bot already has rather than introducing a parallel system: the same result-context storage mechanism used elsewhere in the bot, the same underlying model used for the original summary, and the same paid-result recovery path. The only genuinely new parts are the button and the bounded armed state. If you're already summarizing PDFs in @vustSummaryBot regularly — contracts, research papers, reports, meeting notes exported as PDF — this is a small extension of a workflow you're already using, not a separate tool to learn.