Turn meeting notes into action items without inventing commitments

Use AI to sort out what a meeting actually agreed, not to invent a plan that only looks complete. Every action should trace back to the notes. Missing owners, unsure dates and suggestions should stay visible until someone confirms them.

This method uses only text you paste into a chat in Mono by Reunified. It doesn’t cover recording, transcription, calendar events or syncing with a task app. Mono isn’t out yet, so you can join the waitlist and use the same method with any text assistant in the meantime.

1. Prepare a small, clearly dated source

Remove personal details and anything you don’t need for the follow-up. Keep the meeting date, the project and the names needed to understand who agreed to what. If your notes cover several meetings, split them before you ask for action items.

Use these made-up notes as an example:

Project: Help-page update. Meeting: 9 October 2026.
[1] Lina will send the draft by 12 October.
[2] Omar will review it after Lina sends it.
[3] Friday launch? Confirm with the group.
[4] Maybe commission new screenshots; no owner agreed.

The line numbers are references you add yourself. They let you check the result without hunting through a rewritten summary. Keep question marks and words like “maybe” and “after” instead of “cleaning up” the notes into firmer promises.

2. Ask for extraction before planning

Paste the notes with a clear, limited instruction:

Extract only explicit action items from these notes.
For each, show action, owner, deadline or dependency, and source line.
Use Not specified for missing information.
Separate open questions and suggestions from agreed actions.
Do not assign people, invent dates, create tasks or send messages.

The last line tells the assistant what you want, but it doesn’t replace checking tool permissions. If the assistant suggests doing something in another service, review that on its own. The first useful result is a draft table you can compare with the notes.

Don’t ask it to “make every item actionable” until you’ve checked the extraction. That wording can lead to guessed owners or deadlines that look more certain than the notes.

3. Compare the result with the original notes

An accurate table for the example looks like this:

The launch date belongs under open questions. New screenshots belong under suggestions, with no owner. Neither should quietly turn into a task for whoever’s name happens to be nearby in the notes.

Check that every row has a line that supports it. Then check the other way: did any clear commitment go missing? Keep the verbs exact. “Review”, “approve” and “publish” are different jobs, even if a summary blurs them together.

4. Resolve missing details without rewriting history

Write specific follow-up questions: “Which Friday did we mean for the launch?” and “Should we commission screenshots, and who will own that if we do?” These are questions for people to answer, not gaps for the model to fill.

“After the draft arrives” is a dependency, not a date. Keep it that way until the person responsible gives a timing. If the year comes from the meeting date, say so; if the notes span the new year, check it.

Keep the original notes next to any confirmed correction. Mark later decisions as later, with their date. Otherwise an updated list can make it look as if the meeting agreed on something it didn’t.

5. Prepare a handoff people can use

After your review, put together a short note:

Project and meeting date:
Confirmed actions: action / owner / timing / source
Open questions: question / who can confirm it
Suggestions awaiting a decision:
Changes confirmed after the meeting: date / decision
Next review:

Use names and dates your readers will recognize. Remove details they don’t need before you share it. If you send it through another service, check where it’s going and who will receive it; writing the note doesn’t send it.

You can keep it in a Markdown note or save the whole chat with Markdown export. Saving a note doesn’t add events or tasks to any connected service.

6. Test the workflow before repeating it

Try three test cases: a note with no owner, a proposal that was later rejected, and a relative deadline such as “next Friday” with no meeting date. A good answer keeps the uncertainty or the rejection instead of filling every cell with a guess.

If the answer mixes up meetings, invents commitments or drops dependencies, give it less text and compare again. The fact-checking guide explains the evidence-table method. Only when the reviewed results are reliably useful should you turn this into a saved prompt or a task you describe to Mono. Automation saves time, but people still need to confirm their own commitments.