When you attach a document to a chat message or upload it for training, your employee turns it into readable text on its own. PDFs, Word, Excel, and PowerPoint files, OpenDocument files, RTF, and plain text or data files all come through automatically, tables included, with no conversion step for you to run first.
Attach a PDF, a Word document, a spreadsheet, or a slide deck to a chat message, or upload it to an employee's Knowledge, and the text comes out the other side ready for the employee to read and reason over. There is no button to press and no separate conversion step. The file goes in, the words come out.
The extractor reads by format, not by guessing: paragraphs and tables from Word documents, sheet-by-sheet rows from spreadsheets, slide text from presentations, and paragraph text from OpenDocument and RTF files. Plain text, Markdown, CSV, JSON, and XML pass straight through. Every zip-based format (Word, Excel, PowerPoint, OpenDocument) is checked against a decompression cap first, so a maliciously oversized file cannot exhaust shared server memory before anything is read.
What sets this apart from a bare text extractor is what happens when there is nothing to extract. Most tools that hit a scanned PDF, a page that is really a photograph with no text layer, either return an empty string or fail outright, leaving the employee to guess or the user to think the upload silently worked when it taught nothing. This pipeline checks the extracted text against a minimum length, and if a PDF page is effectively textless, it hands the page images straight to the employee's vision model instead, so a scanned contract or a photographed whiteboard still gets read. Training runs the strict version of the same check: a file that parses but yields no real text is reported as failed rather than marked Completed with nothing learned, closing the exact gap that once let a batch of .docx uploads report success while teaching the employee nothing.
PDF, Word (.docx), Excel (.xlsx), PowerPoint (.pptx), OpenDocument text/spreadsheet/presentation (.odt/.ods/.odp), RTF, plain text, Markdown, CSV, JSON, and XML all extract to readable text automatically. Tables inside Word and Excel files are preserved as rows rather than dropped, so a pricing sheet or a comparison table reads the same way to the employee as it does to you.
Legacy binary Office formats (.doc, .xls, .ppt) are the one gap: they need a full office suite to parse reliably, which is not part of this pipeline, so those files come back with a message asking you to re-save as a modern format or PDF before uploading again.
A PDF that is really a stack of scanned images has no text layer for a standard extractor to find. Instead of returning an empty result and leaving the employee unable to answer questions about it, this pipeline detects when a PDF's text is too thin to be real (an empty page, or just a repeated header stamp) and sends the page images themselves to the employee's vision model, capped at five pages per file to keep the cost and context bounded.
This only applies where a vision model is available in that context. It means a scanned invoice, a signed contract photographed on a phone, or a printed form still gets read by the employee instead of coming back as a dead end.
One dispatcher, one format handler per file type, two strictness levels
A single dispatcher looks at the file's MIME type and routes it to the matching handler: pypdf for PDF, python-docx for Word, openpyxl for Excel, python-pptx for PowerPoint, a stdlib XML strip for OpenDocument, and a lightweight stripper for RTF. Everything else that is already text (plain text, Markdown, CSV, JSON, XML) is decoded directly. Legacy Office formats (.doc, .xls, .ppt) are recognized and rejected with a plain-English message asking for a .docx/.xlsx/.pptx or PDF version, since those old binary formats need a full office suite to parse and are not supported.
In chat, extraction never blocks the conversation: if a file cannot be read, the employee gets a short note in its place ('Could not read <file>') and the turn continues. When a PDF's extracted text is too thin to be real content, usually a scan, the employee is handed up to five of the PDF's embedded page images instead, so it can read the document visually the same way it would read an uploaded photo.
Training uses a stricter path on purpose. A file that decodes but produces no usable text, or a scanned PDF with no vision fallback available in that context, is treated as a failed upload rather than a quiet success, so what the Knowledge tab reports as learned is always true.
Drop a PDF or Word contract into a conversation and ask your employee to summarize the payment terms or flag anything unusual. It reads the document directly, no separate upload step or manual copy-paste required.
Upload a folder of Word docs, PDFs, and spreadsheets to an employee's Knowledge. Each file is extracted to text and learned individually, and any file that fails to yield real content is reported as failed instead of silently counted as learned.
Upload a scanned agreement or a photographed form as a PDF. Because it has no text layer, the employee reads the page images directly through its vision model instead of coming back empty-handed.
Attach an Excel file with several sheets and ask a question about a specific tab. The extractor walks every sheet row by row, so the employee can reference the exact figures without you exporting to CSV first.
No. Attach or upload the file in its native format (PDF, Word, Excel, PowerPoint, OpenDocument, RTF, or a plain text/data file) and the text is extracted automatically. The only exception is legacy .doc/.xls/.ppt files, which need to be re-saved as their modern equivalent or as PDF first.
The extractor detects that the PDF has no real text layer and hands up to five of its page images to the employee's vision model instead, so it can still read a scanned document rather than reporting it as unreadable.
Yes. Training uses a stricter check than chat: a file that parses but yields no usable text, whether it is empty, corrupted, or a scan with no fallback available, is reported as a failed upload rather than marked Completed, so the Knowledge tab never shows a file as learned when it was not.
Yes. Word tables extract as rows of text, and Excel sheets extract row by row, sheet by sheet, so structured data like a pricing list or a comparison table stays intact rather than getting flattened into a single unreadable block.
Zip-based formats (Word, Excel, PowerPoint, OpenDocument) are checked against a 64MB decompressed-content cap before extraction runs, which is generous headroom for any normal document while blocking a maliciously oversized file from exhausting server memory. Overall upload size and monthly upload counts are separately capped by your plan.
Document Text Extraction is part of Things they can do out of the box.
Every AI employee ships with built-in abilities that work out of the box. Search the live web for real-time information, scrape and crawl any website for structured data, and generate images directly in conversation. No plugins to install, no APIs to configure.