Can AI prepare me for a meeting using email history?

Meeting preparation is usually a retrieval problem disguised as a writing problem. The professional knows the attendee's name but must search several threads, remember the last commitment, locate the current document and work out what changed since the previous call. A generic summary of recent email can add volume without answering those questions. Useful meeting AI starts from the real event and assembles only the evidence required to participate intelligently. This page defines the dossier, identity controls, relevance rules, delivery timing and current product boundary. The objective is not a biography of everyone attending. It is a compact, source-grounded view of why the meeting exists, what remains open and which decisions or materials need the user's attention before the call begins.

How can AI build a meeting brief from email history?

The calendar event provides the retrieval key, while email, people, files and operational records provide the evidence. The assistant should join those sources through verified identities rather than broad keyword similarity alone.

The event supplies date, time, title, description, organiser and attendees. Attendee email addresses can resolve to known contacts and organisations. From there, retrieval can find recent threads, relevant filed documents, earlier meeting records, open tasks, unpaid bills and promises involving the same people or work item.

The result should answer five questions quickly: Who is attending? Why are we meeting? What happened last? What is still open? What must I bring, decide or ask? Each important answer should link back to a message, document, calendar event or record. Suggestions—such as “ask about the revised timeline”—must be labelled as suggestions, not facts the source established.

What does a strong pre-meeting dossier contain?

The best brief prioritises the meeting's current business state over a chronological inbox dump. Relevance and provenance matter more than the number of messages reviewed.

For a 13:00 meeting with Costas about a client event, a useful mobile brief could contain:

This is why an assistant working across email, calendar and documents is more useful than separate summaries. The meeting is the point where several sources need to become one accurate operating picture.

How should identity and relevance be controlled?

A brief must never combine records from the wrong person, company or engagement merely because names or words resemble one another. A short wrong brief is more dangerous than no brief.

Email address is a stronger person key than display name, but even addresses change and shared mailboxes exist. Organisation domains, known contact records and prior attendee mappings can improve confidence. Work-item identity is separate: the same client may have several deals, matters or listings running at once. The event title and recent thread can narrow the correct one, but ambiguity should trigger a question.

Relevance also requires restraint. A five-year-old invoice or unrelated confidential matter should not appear simply because the attendee was involved. Rank sources by explicit work-item match, recency, open state and meeting purpose. Respect permissions when attendees span teams or organisations. The system should log which sources were considered and allow the user to exclude a source or mark a wrong match. That correction is part of business memory, not merely a cosmetic edit.

When and how should the brief appear?

The brief should arrive early enough to act on missing information but late enough to reflect current email and calendar changes. A practical default may be the morning of the meeting with a refresh shortly beforehand.

Timing depends on the event. A weekly internal catch-up may need no automatic brief. A first client meeting may need one a day earlier so the user can find documents. A rescheduled event should update its preparation time, and cancellation should suppress the brief. Private calendar entries and personal appointments should be excluded unless the user explicitly requests them.

The interface should be readable on a 375-pixel phone: a top answer, five compact sections and links to sources. It should state when it was assembled and offer refresh. If connected evidence is thin, say “I found the event and two emails but no prior meeting or filed document.” The assistant should not pad missing context with web research or generic talking points unless the user asks for that separately.

What is the current Hank product boundary?

The components required for meeting preparation exist separately, but automatic dossier assembly and timed delivery are not complete. The page must remain a draft until the joined workflow is implemented and shown on real events.

The product can read the user's Google Calendar, search email, retrieve filed documents, find contacts, return open bills and tasks, and search source-linked memory records. It also distinguishes calendar changes involving other people from private diary entries, including the approval boundary used when rescheduling a meeting from email. Those are useful foundations, but asking the agent several manual questions is not the promised proactive meeting brief.

The proof packet requires at least five events: known client, ambiguous same-name attendee, new contact with little history, rescheduled meeting and private event. It must demonstrate correct isolation between two matters for one client, current document selection, source opening, missing-data honesty and mobile layout. The product should also confirm that cancelled meetings do not produce briefs. Until that evidence exists, proof.status remains needed.

Who it is not for

Automated meeting briefs are not appropriate when calendar titles are deliberately vague, source access is prohibited or the meeting concerns material outside connected systems. A human may need to curate highly sensitive board, legal, medical or personnel dossiers.

Large teams with formal account plans may already have a better briefing surface in their CRM. A dedicated research product may suit first meetings where public company intelligence matters more than private email history. The workflow is strongest for an individual professional whose relevant context already exists across their mailbox, calendar, files and personal operating lists. It should assist judgement, not decide negotiation positions or disclose everything known about an attendee simply because retrieval is possible.

That distinction is applied to a regulated client workflow in the guide to AI assistants for financial advisers, where a useful briefing must surface missing information without inventing suitability conclusions.

Conclusion: can AI prepare a useful meeting brief?

Yes, when the assistant starts from the real event, resolves the correct people and work item, retrieves only relevant evidence and shows its sources. The value is not a longer summary; it is arriving with the last commitment, current document, open work and unresolved decision already assembled. Identity mistakes, stale versions and invented context are the main risks, so an honest “not enough evidence” state is essential. This product can already reach the required sources individually, but proactive assembly remains roadmap work. Publication should follow a real multi-event test demonstrating isolation, relevance, mobile usefulness and timely refresh. The decisive proof is whether the user can enter a client call prepared without searching—and still open every important claim back to its receipt.