File Uploads in AI Chat: Letting Agents Read Contracts and Screenshots

The moment users trust an AI chat, they try to hand it things: a contract PDF, a screenshot of an error, a spreadsheet of billing rows, a photo of a whiteboard. If the chat can't take them, the conversation dies right where it was about to get valuable. File intake is not a bolt-on — in our production builds it's one of the top three most-used features, and it has real architecture behind it.

Three Ways In, All Mandatory

• Drag and drop onto the conversation — the desktop default
• Paste from clipboard — this is how screenshots arrive; skipping paste support kills the most common use case
• Attach button — the discoverable fallback, and the only path on some mobile browsers

Show the attachment as a chip in the input area before sending, with a remove control. Users often stage a file, add context text, then send — forcing immediate upload-and-send breaks that flow.

Routing by File Type

Behind the single drop target sits a router. Each format gets a different processing path before anything reaches the model:

Vision Models Changed the Economics

Two years ago document intake meant an OCR vendor, layout-analysis tuning, and template maintenance per document type. Today a vision-capable model reads a rent roll, a term sheet, or a whiteboard photo with no per-template work. Our rule of thumb: text extraction when the document is born digital and layout is simple; vision when layout carries meaning — multi-column contracts, forms, tables, stamps, handwriting. For contracts we often run both and let the model reconcile, because extraction gives precision on wording while vision catches structure extraction mangles.

The demo that sells this every time: paste a screenshot of a confusing invoice and ask "is this consistent with what we agreed?" The agent reads the image, pulls the engagement terms from connected systems, and answers with a comparison table. Cross-referencing uploads against live data is the feature — reading the file is just the entry ticket.

UX Details That Separate Solid From Flaky

1. Progress states per file: uploading → processing → ready. A 40-page PDF takes real seconds; silence reads as breakage.
2. Partial failure handling: three files attached, one corrupt — process two, flag one, never fail the whole message.
3. Size and page guardrails with honest messaging: "This 300-page PDF exceeds the limit — want me to process the first 50 pages, or should I pull it from the document system instead?"
4. Persistence in thread context: the file stays referenceable for follow-ups ("what does clause 7 say?") without re-uploading.
5. Show what the model saw. When answers depend on a specific page, cite the page. Users verify, trust grows.

Security Is Not Optional Here

• Validate file types by content signature, not extension
• Store in access-controlled object storage with signed, expiring URLs — uploads inherit the thread's permissions
• Strip EXIF and metadata before persisting images
• Confirm your model provider's data retention terms cover uploaded documents; clients will ask, in writing
• Log every file's processing chain — for a legal or finance client, "which model saw this contract" is an audit question

Budget roughly a week for a production-grade intake pipeline covering images, PDFs, Office, and CSV — most of it in the routing and failure handling, not the model calls. It's the feature that turns your chat from a Q&A box into the place where documents get understood.