How to write an AI meeting brief people can check
Start with a filled pre-meeting brief, then learn how to connect its claims to evidence, handle conflicting sources and review it before the room relies on it.
Before a meeting about release support, give everyone a short brief they can inspect. They should arrive knowing the decision in front of them, the evidence available and the question the evidence cannot settle. Here is a filled version you can adapt before asking an AI assistant to write yours.
The brief, before the meeting
Decision meeting: support coverage for a release
Use these sample inputs to see how the brief works. Replace the source labels, roles and timing with the agreed details for your meeting.
- Decision for this meeting
- Choose whether to release on Thursday with the proposed support rota or move to Tuesday after training is complete. The release owner makes the call after Support confirms what coverage is available. We need an answer before the customer announcement is approved.
- What the records establish
- The release checklist says the product work is ready. The training plan still has an open walkthrough for the support team. The proposed rota includes an owner for Thursday, but their acceptance is not recorded. Sources: release checklist; support training plan; coverage rota, checked for this brief.
- Options and their consequences
- Thursday: preserve the planned release date, provided Support accepts coverage and the release owner accepts the remaining training gap. Tuesday: allow the planned walkthrough to finish first, but revise the announcement and the customer-facing date. No source in this packet establishes which trade-off is acceptable.
- Unresolved before we decide
- Does the proposed Thursday owner accept the shift? Which support questions require the walkthrough? The support lead will answer these in the meeting. Until then, mark coverage as unconfirmed and do not describe the release as fully staffed.
- What leaves the room
- Record the chosen date, the reason, any condition and the decision owner. Assign the announcement update and the rota update to named people with agreed deadlines. If the missing coverage answer prevents a decision, record that blocker and the next checkpoint instead of filling in a date.
This is a pre-meeting brief, so it contains an unresolved choice. It is not minutes, a transcript summary or a claim that the decision has already been made. The AI's assignment is to prepare this artifact; the meeting resolves what the artifact cannot.
Choose the records before asking for the summary
Start with the decision question and work backward to the records that can answer it. For the release meeting, that means the accepted release plan, readiness evidence, support rota and training status. A folder containing everything about the project invites irrelevant history into the brief. A packet that omits Support cannot establish coverage, however well it describes the product work.
Ask the person responsible for each record whether it is current enough for the meeting. Note the version or last check alongside the source link. ‘Latest’ is not a meaningful instruction when one document was edited yesterday but an older signed plan is still authoritative. If a newer comment proposes a different date, describe it as a proposal until the owner confirms the change.
Give the assistant the filled brief's headings and ask it to use only the supplied or approved sources. Require links beside the claims they support, and ask it to flag contradictions and unavailable records. Specify who will read the brief so it does not copy sensitive account notes into a wider meeting packet. Access to a source does not automatically make every detail appropriate for every attendee.
Read it for the mistake the room could inherit
The dangerous sentence in the example is ‘Support is ready for Thursday.’ It sounds like a compact summary of the rota. The rota only names a proposed owner; it does not show acceptance. Open the supporting record and check that distinction before circulating the draft. The review should test the claim, not just whether a link exists beside it.
Read the options with the same care. ‘Tuesday is safer’ adds a judgment unless the team has agreed what safer means and why the evidence supports it. The draft can say that Tuesday allows the planned training to finish. Whether that benefit outweighs the delay belongs to the release owner. Keep the consequence concrete and let the person with authority choose.
Send the reviewed brief with enough time for people to challenge a specific line. If a source changes afterward, update the affected claim and make that change visible. Do not leave a polished attachment in circulation while privately correcting it in a separate thread. The people deciding need to be reading the same accepted version.
A weekly status recap has a different job: establish what changed before deciding whether a meeting is needed at all. Use the four-section Monday brief for that job.
Leave with a record the next brief can use
After the meeting, replace the open question with the accepted decision and its reason. Keep any condition attached. ‘Thursday, provided the support lead confirms coverage by Wednesday noon’ is different from ‘Thursday.’ Ask the decision owner to review that line, then put the accepted record where the release plan links to it. The next brief should not have to infer the outcome from a transcript.
Zeke can prepare a sourced brief from connected Google Drive documents that have been scanned, and a scheduled task can repeat that preparation. A schedule alone does not make the records fresh; changed documents need another scan and the draft needs review. It is not automatic capture of every Slack conversation. Someone still owns the source packet and approves the decisions or external commitments that follow.
When attendees disagree with the brief, they should be able to point to the sentence and the evidence they dispute. That gives the meeting a place to begin.