AI meeting assistant: what to check before a call

An AI meeting assistant can prepare you for a call before anyone joins. It can gather the attendee list, retrieve notes from the previous meeting, identify decisions that still need action and draft questions worth asking. The useful output is a short brief you can read in a few minutes, not another long document to work through.

The hard part is getting the context right. A meeting title rarely tells an assistant what happened last time, and an old note may describe a proposal that was never approved. If you rely on an AI-generated brief without checking those details, you can walk into a conversation with the wrong understanding of what was agreed. A good setup gives the assistant a defined job, a limited set of sources and clear rules for marking uncertainty.

Decide what the assistant must bring back

Start with a recurring meeting that has a clear purpose, such as a client review, a weekly operations call or a project check-in. These meetings tend to have a history worth retrieving. A one-off introduction may need only an attendee list and a little background, while a project review needs the decisions and unfinished work from previous sessions.

Write down the questions you want the brief to answer before choosing tools or connecting accounts. For a weekly project meeting, the brief might need to tell you who is attending, what the team agreed last time, which actions remain open and what needs a decision today. That gives the assistant a test it can pass or fail.

Keep the output short enough to read just before the call. One page is a useful limit because it forces the assistant to rank information instead of copying everything it finds. A long transcript summary might be accurate and still leave you searching for the one decision that matters.

Give it a reliable trail of meeting history

The assistant needs access to the places where your team records meeting context. That may include calendar details, previous notes, project documents and a task list. Each source should have a clear purpose. Calendar data can establish who was invited and when the call takes place. Notes can record what was discussed. A task tracker can show whether an agreed action has been completed.

Do not assume that connecting a source makes its contents trustworthy. Meeting notes may be incomplete, an action item may have been copied into a new document without its status, and an attendee may have changed roles since the last call. Tell the assistant which source takes precedence when records disagree. If there is no clear authority, the brief should say that the information conflicts.

Keep the scope narrow at first. Give the assistant access only to the records needed for the meetings it prepares. A client review usually does not require access to every internal document or every person's calendar. Restricting the source material makes it easier to understand where a claim came from and reduces the chance of unrelated information appearing in the brief.

Use a brief that separates facts from questions

A useful pre-call brief has a consistent structure. When every meeting follows the same format, you can spot missing information quickly and compare the current position with the previous one. The assistant should distinguish a recorded decision from an open proposal, and a completed action from one that has simply gone unmentioned.

• The meeting details: date, purpose, attendees and any relevant changes to the invitation.
• The previous meeting: the main decision, the reason for it and any conditions attached to it.
• Open actions: the owner, the expected next step and the latest recorded status.
• Questions requiring an answer: unresolved issues, missing evidence or decisions that have been deferred.
• Items to verify: conflicting notes, uncertain attendee details or claims without a supporting record.

Consider a product review where the previous notes say the team discussed a launch date. The assistant should not turn that discussion into an approved launch date. It should report that the date was discussed, identify whether a later record confirms the decision and flag the point for you to check if no confirmation exists.

That distinction matters because a polished sentence can hide weak evidence. Ask the assistant to attach a source or document reference to important claims, particularly decisions, deadlines and commitments attributed to another person. If it cannot find supporting material, it should label the item as unverified rather than fill the gap with a plausible answer.

Set up the task and its limits

Once the brief is defined, write a specific instruction for the assistant. Include the meeting type, the sources it may consult, the required sections, the length limit and what it must do when information is missing. Avoid vague requests such as 'get me ready for the call'. They leave too much room for the assistant to decide what preparation means.

Prepare a one-page brief for the next project review. Use the calendar invitation, the latest approved meeting notes and the project task list. Report the previous meeting's confirmed decisions and the status of each open action. List unresolved questions separately. Include source references for important claims. Do not treat a suggestion as an approved decision. Mark missing or conflicting information for human review. Do not contact attendees, change records or send the brief outside the workspace.

The last instruction sets a boundary between preparation and action. Drafting a question is part of the job. Sending that question to a client is a separate action with an effect outside the workspace. The assistant should not treat permission to prepare a meeting as permission to contact people or change the underlying records.

If you use an agent workspace such as Delagents, you can give a meeting-prep agent a written brief and review its deliverable at a checkpoint. The workspace has an approvals inbox for actions that affect the outside world, along with a hard budget cap for each delegation and an append-only activity log. These controls help keep the preparation task separate from decisions that still belong to a person.

Test the brief before trusting the routine

Do not begin by relying on the assistant for a high-stakes client call. Run it against a meeting whose history you already know. Compare the generated brief with the original notes and records. Check whether it found the right attendees, preserved the exact status of decisions and included unfinished actions rather than only the latest activity.

Pay particular attention to errors that sound reasonable. A task marked complete in an old document may have reopened. A proposal in the meeting notes may have been rejected in a later discussion. Someone copied into the calendar may not be attending. These mistakes are easy to miss if you read only for fluency.

• Check every claim that changes what you expect to happen in the meeting.
• Open the source for each important decision and confirm that the brief represents it accurately.
• Look for missing actions, unexplained status changes and deadlines without clear owners.
• Confirm that private or unrelated material has not been pulled into the brief.
• Record recurring mistakes and revise the instructions or source priorities before the next run.

A useful test is to remove one source the assistant normally uses and see whether it admits the gap. If the previous meeting notes are unavailable, it should not invent a history from the calendar title. It should say that the previous decisions could not be verified and leave you with a clear question to resolve.

After several checks, decide which parts you are comfortable reviewing quickly and which still need closer inspection. A reliable process does not require you to re-read every source from scratch, but you should retain access to the evidence behind consequential claims. Revisit the setup when your team changes its note-taking habits or moves project records to a new system.

Make preparation part of the meeting routine

Choose a preparation deadline that leaves time to correct mistakes. For a morning call, the brief might be ready the previous afternoon. For a meeting that depends on late updates, a shorter window may work better. The important point is to avoid generating the brief so early that its open actions and attendee details are already out of date when you read it.

Give the brief a clear owner. The meeting organiser or the person responsible for the agenda should check it before the call, resolve any flagged gaps and decide which questions deserve time. If a decision is still uncertain, the brief can help put it on the agenda. It should not silently settle the question on the team's behalf.

Keep a simple record of whether the brief was useful and what needed correction. You do not need a complicated scoring system. A short note about a missing decision, a stale task status or an irrelevant section will tell you what to fix. The goal is to reduce the time spent reconstructing context without replacing the judgement that makes the meeting worthwhile.

To get started, pick one recurring meeting scheduled for next week and gather its last set of approved notes, current action list and calendar invitation. Use the meeting prep template to define the brief, run one test and check every decision and open action against its source before you use it to prepare for the call.