Most meeting “prep” fails for a boring reason: the context is scattered.
There’s the calendar invite. The last email thread. A doc you vaguely remember. A Slack message you meant to respond to. A decision that happened three meetings ago.
So you do the same ritual every time: 90 seconds of panic-skimming right before the call.
An AI pre-meeting packet is one of the few personal-agent workflows that feels immediately useful because it solves a concrete pain: context thrash. It doesn’t need creativity. It needs retrieval, compression, and a stable output format.
But only if you keep it constrained.
This blueprint is advice-only. The agent can read and summarize and draft a packet. It does not email anyone. It does not update docs. It does not change the calendar. It’s a one-screen briefing for you.
What the packet should contain (and what it should never contain)
A pre-meeting packet should fit on one screen. That’s not a nice-to-have; it’s the whole point.
It should include:
Context: what’s going on, in two to four sentences.
Decisions: what might need a yes/no.
Risks: what could go wrong or what’s ambiguous.
Questions: two or three questions that improve the meeting.
It should not include a transcript of your inbox. It should not include “every possible detail.” If you have to scroll, you’ve already lost.
The product is the shape of the output, not the model.
Trigger: 15 minutes before (with filters)
The biggest mistake is generating packets for every meeting.
If you do that, you’ll train yourself to ignore them.
Start with a filter that captures the meetings that benefit from prep:
External meetings.
Meetings longer than 25 minutes.
Meetings with more than 2 attendees.
Or meetings with a tag in the title like “[prep]” if you want explicit control.
The trigger itself should be time-based: 15 minutes before the event. That gives you time to skim, not just time to feel guilty.
Inputs: choose a single source of truth for “history”
This workflow only works if the agent has somewhere to look for “what happened last time.”
You have two good options:
A meeting notes doc that you actually use.
Or a single notes page per project/client where you keep a running log.
If you don’t have either, don’t pretend. Create a single place to write the last decision and the open questions. Even a short bullet list is enough.
The agent can enrich with threads and emails later, but it can’t invent history.
The output template (copy this)
Here’s a template that works in practice:
Pre-meeting packet: {Meeting name} ({Start time})
Context {2–4 sentences}
Decisions {1–2 items}
Risks {1–2 items}
Questions {2–3 items}
Example packet
Pre-meeting packet: Customer call (2:00)
Context Last time they asked for an integration timeline; you promised a follow-up. They’re deciding between two vendors this week.
Decisions Offer a fixed-scope pilot, or commit to a full rollout date?
Risks Security review could become the gating item; you don’t yet know their process.
Questions Who signs off on security? What’s the single workflow they want automated first? What does “success in 30 days” mean to them?
Notice the tone: crisp, not verbose.
Defaults that make it reliable
This agent should not be smart. It should be consistent.
Set a one-screen cap.
Always include the “Decisions” section even if it’s “None obvious.” This is how you notice you’re walking into a meeting without a purpose.
If the agent can’t find relevant notes, it should say so explicitly and fall back to a generic packet instead of hallucinating.
And don’t let it run continuously. Only run it in response to a calendar event.
Permission boundaries
Keep this advice-only.
The agent can:
Generate a packet.
Draft questions.
Highlight a risk.
But it cannot:
Send the packet to attendees.
Update the meeting invite.
Email follow-ups.
If you later want to add one automated action, make it something reversible and low-social-risk, like creating a private note draft.
Failure modes (and playbooks)
Failure mode 1: wrong meeting, wrong context
What it looks like: the packet pulls notes from a different project with a similar name, or it summarizes an old thread.
How you catch it: include one “evidence line” at the end of the packet: the name of the source doc or the last updated timestamp. Not a full citation list—just enough to sanity check.
How you fix it: tighten retrieval. If you’re using a notes page per project, key on the project identifier. If you’re using meeting notes, key on the meeting series ID.
Failure mode 2: it becomes too long
What it looks like: every section turns into paragraphs and you stop reading it.
How you catch it: enforce a strict character cap per section. The simplest approach is “max 3 lines.”
How you fix it: drop the “Context” length first. Keep Decisions and Questions.
Failure mode 3: it’s polite but not useful
What it looks like: it restates the agenda and says nothing concrete.
How you fix it: force the packet to include one “Decision” or explicitly say “No decision found.” Useful packets have teeth.
Failure mode 4: it fails silently
What it looks like: no packet arrives.
How you fix it: treat missing packets like missing infrastructure. One alert if the trigger ran and no packet was produced, then stop.
What to do when you have no notes (yet)
A surprising number of meetings don’t have “history” in any system. Maybe it’s a first call. Maybe the last conversation happened in a hallway. Maybe the notes are in someone else’s doc.
If the agent can’t find notes, it should not pretend.
Instead, it should generate a fallback packet that is honest and still useful:
It should restate the goal of the meeting in plain language (based on the invite title and attendees), propose two likely decisions, and give you three questions that surface constraints.
You can think of this as “prep scaffolding.” Even if it’s generic, it often turns into the first real notes you capture.
The next step is to create a tiny ritual: at the end of the meeting, write a two-line update in your source-of-truth page. One line for the decision, one line for the open loop. That’s enough to make next time’s packet accurate.
A small upgrade that’s safe: pre-writing the follow-up
The highest leverage part of many meetings isn’t the meeting. It’s the follow-up.
A safe upgrade (still advice-only) is to have the agent draft a follow-up email for you to send later. Not immediately, not automatically.
The draft should have three parts: what you agreed on, what’s next, and the deadline.
If you keep it in drafts and require an explicit “send” from you, you get the speed without the risk.
A simple acceptance test
Tomorrow, pick one meeting where you normally show up slightly underprepared.
Read the packet 15 minutes before.
If you walk into the meeting and immediately ask a better question—or avoid a “wait, what did we decide?” moment—this workflow is already paying for itself.
If it doesn’t help, don’t tweak prompts for an hour. Remove an input source. Tighten the template. The output format is the product.
Closing
Most people don’t need an AI that can “run meetings.”
They need an AI that can hand them one screen of context at the right time.
Keep it advice-only. Keep it short. Keep it triggered by the calendar.
That’s how it becomes a habit instead of another experiment.