Can AI find a document I was emailed months ago?

Old attachments are rarely remembered by filename. A professional remembers that Tom sent proof of bank before a client application, or that a signed schedule arrived after a pricing discussion. Conventional search works well when the right sender, phrase or filename is known. It works less well when the remembered concept exists inside a blandly named PDF or a long thread. AI can bridge that gap by resolving people, document types and work context, then searching both metadata and extracted text. This page explains the retrieval path, archive and retention boundaries, version selection and evidence required before a buyer should trust a result. Finding a plausible file is not enough. The workflow succeeds only when the correct document opens and its relationship to the original email remains clear.

How can AI find an old emailed document without its filename?

The assistant can translate remembered business meaning into several retrieval signals, then rank matching attachments and filed documents. The user describes the thing; the system searches names, people, messages, folders and contents.

“Find Tom's proof of bank from earlier this year” yields a person, document type and time range. Contact records may resolve Tom's email addresses. Message metadata can identify attachments from those addresses. Extracted text can distinguish a bank confirmation from proof of address even if both files are called scan.pdf. Folder paths and source subjects add evidence.

The result should show file name, document type, person, source date, email subject and storage location. It should also let the user open the actual bytes. A generated explanation without a downloadable or provider-linked file has not completed retrieval. If several candidates score similarly, show a short choice rather than allowing semantic similarity to decide a consequential version question.

What does the complete retrieval workflow look like?

Useful retrieval ends with the exact accessible file and a visible source trail, not a quotation from its text. Search, selection and opening are separate steps that all need to work.

1. Interpret the request into person, organisation, document type, work item, date and remembered phrase.
2. Resolve contact identities without merging two similar names.
3. Search provider mail, stored attachment metadata, extracted text and permanent files within authorised scope.
4. Rank candidates by explicit matches, current-version state and source date.
5. Present the best result with enough evidence to recognise it.
6. Open or download the underlying file.
7. If asked to send it, attach the real file to a draft and keep sending as a separate approved action.

This is a practical test of an assistant spanning email and documents. The query begins in human memory and ends in a source-backed document.

Why do archive coverage and retention matter?

Retrieval cannot be more complete than the mailbox folders and stored files the product is authorised and able to search. A beautiful answer does not repair missing coverage.

Inbox-only search loses visibility when a user archives a message. A recent-message ingest window may never have captured something sent years earlier. Locally cached attachments may expire under a storage policy, while the provider copy still exists. Conversely, a document deliberately filed into permanent storage can remain accessible even if the original email is later removed.

Products should state which route produced the result: live provider search, captured email, transient attachment or permanent filing. When a local copy has expired, the interface can link to the original provider or explain that the source must be reopened. A proof test should deliberately archive the message, move it between folders, wait beyond any cache period or simulate expiry. “Searches your email” is too broad a claim without those conditions.

How should versions and similar documents be handled?

The assistant must distinguish newest, current, signed and relevant because the latest received file is not automatically the correct one to use. Version choice needs evidence, not filename optimism.

A client may send two proofs of address, a draft contract followed by a signed copy, or a corrected schedule with an earlier-looking filename. Document type, version metadata, extracted signatures, later email statements and user filing decisions can identify the current version. Older versions should remain available for history but not rank as the default.

When the system cannot establish precedence, it should show both: “Signed schedule received 18 July” and “Schedule v4 received 21 July, unsigned.” That allows the user to choose based on purpose. Automatic sending should be stricter still. The chosen file must be accessible, recognisable and attached in bytes before a draft can say it is included. A business-aware memory preserves the relationship between file, person and work rather than flattening every PDF into search text.

What is the current Hank product boundary?

The current product can search captured attachments and permanently filed documents by metadata and extracted text, but complete old-mail retrieval is blocked by live archive coverage and retention conditions. This is why the draft answers “yes, if” rather than making an unconditional promise.

The global search indexes observed email attachments as well as filed files. Filing search uses file name, folder path, sender, subject and document text. Filed documents can be opened and attached to drafts. Email attachments initially live in transient storage, and filing promotes selected files into permanent storage.

The gap is documented: live IMAP search currently covers Inbox rather than All Mail. An archived message outside captured history can therefore be invisible. Before publication, All-Mail or provider-equivalent coverage must ship and the proof packet must test archived, never-filed, filed, expired, renamed and duplicate-version cases. Every successful result must open. Until then, the article remains draft with proof.status: needed.

Who it is not for

This workflow is not a records-management guarantee, legal hold or universal search across systems the assistant cannot access. Regulated retention and discovery require formal policies, permissions, audit trails and preservation controls.

It is also unsuitable when attachments are encrypted without an approved handling path, when client documents may not leave a controlled repository or when shared-mailbox identities are unresolved. A dedicated document-management platform may be better for strict version approval, check-in and records schedules. The workflow is strongest for ordinary professional retrieval where email was the delivery channel and the user needs to recover a known document by meaning quickly, while retaining a clear path to its source.

Conclusion: can AI recover an old email attachment?

Yes, provided the relevant mailbox history or a retained copy is actually searchable. AI improves retrieval by converting remembered people, work and document meaning into metadata and content searches; it does not conjure files outside its access. The trustworthy result names the candidate, explains its source, distinguishes versions and opens the actual document. Archive scope and retention must be visible limitations. In this product, captured and filed document search already establishes part of the path, but complete All-Mail coverage remains necessary before the broad claim can publish. The decisive trial is not searching a recent inbox message by filename. It is finding a blandly named, archived, months-old attachment by client and purpose, then opening the correct current version from its source.