B Builderlog
Builderlog · ·Playbooks ·Builderlog Field Manual 150 ·Sep 4, 2026 ·6 min read

AI Meeting Workflow: Keep Decisions, Actions, and Open Questions Separate

#ai#project-management#workflow#meeting#decisions
AI Meeting Workflow: Keep Decisions, Actions, and Open Questions Separate

On 2026-09-04, no verified experiment results were available for this AI meeting workflow, so this playbook makes a narrower promise: it shows exactly how to restructure one set of notes and check the result yourself. Paste the notes into an AI chat. Ask for three categories: decisions, actions, and open questions. Then compare every output row with the original before using it for project management.

Decisions record what the group settled.
Actions record work that someone must complete.
Open questions record what remains unresolved.

The AI does the sorting, not the approving. The useful part is not a polished summary. It is a small, traceable table that lets a person detect missing, invented, or ambiguous information.

The table is the meeting record

A conventional meeting summary often blends several kinds of information into tidy paragraphs. That can hide the difference between “we discussed this,” “we agreed to this,” and “someone will do this.”

Use a three-column table instead:

DecisionsActionsOpen questions
Settled choices and accepted constraintsWork that still needs to happenIssues that still need an answer

A sentence belongs under Decisions only when the source notes show that a choice was made. A possible direction is not a decision.

An item belongs under Actions only when the notes describe future work. Preserve the owner and due date when they appear. If either is absent, mark it as missing rather than guessing.

Anything unresolved belongs under Open questions. This includes explicit questions, pending approvals, missing information, and alternatives that the group did not settle.

A clean summary is less valuable than a traceable one.

Start with one imperfect source

Use one past meeting note from a low-risk project. Remove private, identifying, or sensitive information before putting it into any chat system. Replace names with roles such as “editor” or “project lead.”

Do not rewrite the note first. Its rough edges are part of the exercise. Fragments, repeated points, and unclear ownership reveal whether the workflow can preserve uncertainty instead of smoothing it away.

Here is an invented example for a fictional convenience-store deals project:

Keep the weekly update short. Maybe send it on Friday. The editor needs to confirm whether expired offers stay visible. Project lead said the first release should cover grocery deals only. Check the mobile layout before release. We still need somebody to own that check.

This example is a demonstration artifact, not an observed meeting or performance result. It contains no evidence about accuracy, time saved, or business impact.

Give the AI a constrained job

Paste the cleaned source note into an AI chat with an instruction like this:

Sort the meeting note into Decisions, Actions, and Open questions. Use only information stated in the note. Preserve owners and deadlines when present. If an owner or deadline is missing, write “not stated.” Do not infer agreement. Keep each item short and include the exact source phrase that supports it.

Ask for a table with these fields:

CategoryExtracted itemOwnerDeadlineSource phrase

The source-phrase field matters. It turns review from a memory exercise into a comparison task. Without it, a plausible sentence can pass as true simply because it sounds organized.

If the response combines several claims in one row, ask the AI to split them. Each row should represent one decision, action, or unresolved issue. Smaller rows are easier to verify and correct.

Put the original beside the result

The required receipt is the comparison itself. Below, the left side preserves the relevant source text. The right side shows how it should be classified.

Original noteStructured result
“Keep the weekly update short.”Decision: The weekly update will be short. Owner: not stated. Deadline: not stated.
“Maybe send it on Friday.”Open question: Should the weekly update be sent on Friday?
“The editor needs to confirm whether expired offers stay visible.”Action: The editor will confirm the treatment of expired offers. Deadline: not stated.
“Project lead said the first release should cover grocery deals only.”Decision: The first release will cover grocery deals only.
“Check the mobile layout before release.”Action: Check the mobile layout. Owner: not stated. Deadline: before release.
“We still need somebody to own that check.”Open question: Who owns the mobile-layout check?

This table is evidence of how the classification rule applies to the invented text. It is not evidence that an AI system will always classify real notes correctly.

Notice the cautious treatment of “maybe.” Turning that sentence into a Friday deadline would invent certainty. Notice also that “before release” is preserved as written. It should not be converted into a calendar date.

Missing ownership is a finding, not an invitation to invent an owner.

Review every row against the source

Read the structured result from top to bottom. For each row, locate its source phrase and apply three checks.

Supported: Does the original actually state this item?

Correctly classified: Was it settled, assigned, or left unresolved?

Complete: Did the result preserve useful details such as an owner, condition, or deadline?

Then reverse the direction. Read the original note line by line and confirm that every meaningful statement appears somewhere in the table. This second pass catches omissions that a polished output can conceal.

Mark questionable rows rather than silently repairing them. Useful review labels are:

  • Confirmed
  • Missing from result
  • Unsupported by source
  • Wrong category
  • Needs clarification

The final table should contain only confirmed material. Move genuine uncertainties into Open questions. Delete unsupported additions.

The common failures look reasonable

The most dangerous failure is false certainty. “Maybe,” “consider,” and “could” can become decisions after summarization. The grammar improves while the meaning changes.

Another failure is manufactured project management detail. An AI may assign an obvious-looking owner or produce a precise deadline where the source has neither. “Not stated” is the correct output in that situation.

Merged items create a quieter problem. One sentence may contain a decision and an action. Keeping both in one summary bullet makes later tracking difficult. Split them and retain the same source phrase where necessary.

Omission is also easy to miss. Reviewing only the output asks, “Does this look sensible?” Comparing from source to output asks the more useful question: “Did anything disappear?”

No accuracy rate, time saving, cost, user result, or experiment duration is claimed here because none was supplied as a verified operating fact. The method also does not determine whether the original notes were correct. It can organize the record, but it cannot recover statements that nobody captured.

Keep this checklist with the template

Copy this artifact into the free document where you store meeting records:

  • Remove sensitive and identifying information.
  • Preserve the original note unchanged.
  • Request Decisions, Actions, and Open questions.
  • Require owner, deadline, and source phrase fields.
  • Reject inferred agreement.
  • Mark absent details as “not stated.”
  • Check every output row against its source.
  • Check every source line against the output.
  • Split rows that contain different categories.
  • Delete unsupported additions.
  • Move unresolved details into Open questions.
  • Approve the table before sharing or assigning work.

The final decision is simple: use AI for classification and formatting, but keep human approval as the release gate. For beginners, one document, one chat, and one comparison table are enough to make the workflow useful without pretending it is autonomous.

TL;DR

Turn meeting notes into decisions, actions, and open questions, require source phrases, and approve every row against the original.

The next episode will turn the approved action column into a lightweight follow-up record without losing its source trail.