Why AI meeting action items go wrong, and what to check

Why are AI meeting action items wrong? Because the model makes the list tidier than the meeting was: it names owners nobody named, adds dates nobody said, files decisions as tasks and closes questions still open. Before you send the list, check every item against the transcript for who committed, what the group decided and what is still open.

We build Chief, a meeting-capture tool, so these four drifts are our problem too. The last section takes each drift in turn for Chief and names what you still check.

Key Takeaways

• An AI action list goes wrong in one direction: it fills the gaps the meeting left, so the list looks finished.
• The four drifts are an owner nobody named, a date nobody said, a decision written as a task, and an open question marked closed.
• The costliest is the decision filed as a task. The ticket gets an owner, and the decision behind it doesn't.
• A 2006 research system found the owner the hardest part of an action item to detect (Purver et al.).
• Before you send the list, check each item against the transcript: who said it, did they commit, did the group decide it, is it still open.

What are the four ways an AI action list drifts?#

Brittany Bonds named all four, among others, in one sentence on dev.to (2026-09-22). Her checklist is for the morning you send the list, when:

…an invented owner is still looking assigned, a due date nobody said is still looking calendar-ready, a decision is still padded in as a task someone can "own," an open question is still marked closed so the list looks tidy…

All four lean the same way: the model fills a gap the meeting left, so the list looks more finished than the conversation was.

Ramprasad, Ferracane and Lipton studied dialogue summaries at ACL 2024 and found that "over 30% of LLM-generated summaries contain inconsistencies". For GPT-4, the figure was about 23%. The largest share, "Roughly 38% of errors", were circumstantial inference: plausible conclusions the dialogue doesn't directly support. The study covers dialogue summaries in general, not action items. An invented owner looks like that kind of inference.

An owner nobody named#

Meetings often end on "we should look into that." The list needs a name in the owner column, and the person who raised the topic is a plausible guess. A plausible guess is the circumstantial inference the ACL study counted.

The owner was hard long before today's models. Purver, Ehlen and Niekrasz split an action item into four parts: a task description, a timeframe, an owner and agreement. Their 2006 detection system, built well before LLMs, scored an F-score of 0.17 on owner, against 0.40 for agreement. "The worst performing class is owner," they wrote (Purver et al., 2006). Read that as a sign the problem is structural, not as a current accuracy figure.

The cost comes late. As alapha888 put it on dev.to (2026-10-02), "an invented owner is a bug nobody notices until the deadline passes."

A date nobody said#

Dates drift for a related reason. The same 2006 paper notes that the timeframe "is often not specified with a date or temporal expression". People say "soon" or "after the launch". A blank date column looks unfinished, and a model that fills it produces the list you expected, with dates the room never said. Bonds's word for the result fits: the date looks "calendar-ready", and nobody said it.

A decision written as a task#

"We're moving the launch to June 15" is a decision. Rewritten as "Move launch to June 15, owner: Sam", it becomes a task. The task looks actionable. The model keeps the task and drops the record of who decided, and why.

An open question marked closed#

Some items are questions nobody answered. Alex (@saaspet) tested an AI notes tool for a week. On dev.to (2026-08-29), Alex wrote: "twice it was spot-on, once it included an action item that was actually a question (I edited before sending)." The same review reports "0 corrections to decisions", so these drifts don't hit every list. When this one does, "Decide on pricing tiers, owner: Dana" reads as settled work while the question is still open.

Why is a decision filed as a task the worst of the four?#

On a given day, a wrong owner can cost more. If the list sends the wrong person to handle a customer escalation, the damage is immediate. We grant that.

But a wrong owner is visible. The named person reads the list, objects, and someone fixes the item. Someone checking a calendar can catch a wrong date the same way. Both errors have a reader who cares.

A decision filed as a task has no such reader. The list still looks complete. The task has an owner, so the board looks calm. The list is missing the owner of the decision: who made the choice, on what grounds, and who can reopen it.

Yura Solovey put it in one line on dev.to (2026-10-02): "A ticket owner is not necessarily the owner of the decision that made the ticket necessary." Solovey describes the result: a team can distribute work efficiently "while leaving the central question to be answered accidentally by the first implementation that reaches production."

That is the slow cost: someone builds the task, a question comes up that the decision should answer, and nobody can say who decided. Whoever is building answers it, and the code settles a question the group never closed.

Solovey's fix is narrow: "do not let an unresolved decision be converted into assigned work without recording who owns it and what must wait for it." Decisions need their own line in the list, with a name next to them.

The 2006 study gives a reason to split the types. An earlier flat annotation marked each line as action-item-related or not, and "inter-annotator agreement was low (κ = .36)". The 2006 team labelled the four parts separately. Their "initial reliability between two annotators on the single ISL meeting" was "encouraging": timeframe κ = .86, owner κ = .77, description and agreement κ = .73. The two figures come from different studies, so treat this as a direction. If people agree more once they label the types separately, your list should split them too.

What should you check before you send the list?#

Open the transcript beside the list and ask four questions of every item.

1. Who said it, and did they say they'd do it? Find the line in the transcript. If nobody took the item on, write "owner: ask" instead of a name.
2. Did anyone say the date? If the date isn't in the transcript, delete it or mark it "to agree".
3. Is this a decision or a task? If it's a decision, write it as one, with the person who made it. List any tasks that follow from it underneath.
4. Is it still open? If nobody answered it, move it to an Open questions list, with the name of the person who needs to answer.

Then send the list in three parts: decisions first, tasks second, open questions third. Decisions go first because the tasks depend on them. Open questions go last, each with a name, so nobody reads them as settled work.

A full owner column is not proof that anyone agreed to anything. Bonds's phrase "still looking assigned" names it: the column looks finished because the model filled it.

The check has to be a habit, because people skip it. A University of Melbourne and KPMG survey of more than 48,000 people in 47 countries found that "many rely on AI output without evaluating accuracy" (66%). In the same study, 56% reported "making mistakes in their work due to AI" (Gillespie, Lockey et al., 2025).

Skipping the check can leave you worse off than having no list. On Hacker News (2026-09-23), gfody wrote about summarizing meetings with a cheap model. It "is worse than not doing it at all - especially if you relieved the scribe thinking ai had you covered". Send an unchecked list and the room gets that same false cover.

How does Chief sort a decision from a to-do?#

In a Chief Live Session, as people talk, Chief sorts each point it writes, and the To-dos and Decisions tags apply themselves. Chief gives each point it writes one kind. A point is a to-do, a decision or neither, never both. When the same outcome shows up as both a to-do and a decision, Chief keeps it as the decision. Sorting is a judgement, so check it.

The other three drifts get narrower rules:

• Owners. A to-do names its owner only when someone says who owns it during the call. Chief doesn't pick an owner. A named owner can still be wrong, since names are machine-transcribed.
• Dates. Chief doesn't set due dates. A deadline someone says out loud stays in the to-do's text.
• Open questions. An open question that work hinges on stays in Live Notes as a point with no tag. Chief doesn't mark questions open or closed. You can add a tag of your own, such as Open questions, switch on Automatically apply this tag, and write one sentence about what it should match. It applies itself when Chief judges a point matches, so it can miss a point or land on the wrong one.

You still run the four-question check. In the Chief desktop app, the Executives workspace puts Decisions and To-dos up front, with the transcript one click away. A point shows when it was said, and View in transcript takes you to that moment. Open a point to add a tag or take off one Chief applied, and a tag you take off stays off.

A tag can miss a point or land on the wrong one. Chief doesn't track whether a decision held or whether anyone answered a question. These views live in the desktop app. If your team already sends decisions, tasks and questions as separate lists checked against the transcript, you have the fix already. Leave the meeting with decisions and to-dos already sorted walks through the setup.

FAQ#

Before you send the list, make sure it says only what the room said.