Reading AI meeting summaries

Day 9: Reading AI Meeting Summaries for What They Leave Out

Every sentence in the recap was true, and the team still built the wrong thing. That happens more often than people think. Most of us now act on more AI recaps than meetings we actually sat through. When a recap makes an open question look settled, nothing in it is technically wrong, so nobody stops to check.

The hook: a recap with no false facts that still misled the team

Here's a recap of the kind every meeting tool produces now:

Summary — Platform sync, Tuesday
• Team agreed to move the orders service to the new event store.
• Minh to own the migration.
• Discussed latency vs. consistency trade-offs.

And here's what was actually said near the end of the call:

Lan:   I'm still not convinced the event store holds up at peak.
Minh:  I can own it if we go ahead.
Huy:   Let's not lock it in today. Revisit Thursday with the load test numbers.
Lan:   Fine, Thursday.

Go through the recap line by line. The event store was discussed. Minh did offer to own it. Trade-offs came up. Nothing is made up. But someone who skipped the meeting reads "Team agreed… Minh to own" and starts work. By Thursday there's a half-built migration, nobody has looked at the load test numbers, and the real question, "should we do this at all?", never got answered. Work shipped against a decision nobody made.

The reframe: summaries are built to sound finished

Earlier in this series we covered hallucination, where AI says things that aren't true. That still happens. In my experience, though, it isn't the main way meeting summaries mislead people. A summarizer's job is to compress, and compression keeps whatever looks like content. Decisions, owners and action items look like content. "I'm not sure", "only if" and "let's revisit" look like noise. They're hedges, they're short and nobody repeats them, so they're easy to cut. What you get back is tidier and more finished than the meeting was. So stop asking "is this true?" Ask "what does this say got closed, and did it really close?"

The three things that go missing

1) Disagreement gets averaged. When people argue, summarizers rarely pick a side. They write one neutral sentence that blends everyone together and names nobody.

SAID:     Three people wanted eventual consistency for speed. Two said the
          finance reports would break. No resolution.
SUMMARY:  The team discussed trade-offs between latency and consistency.

The 3–2 split is gone. So are the names on each side, and so is the risk that finance reports break. You're left with a sentence nobody would object to, and that's exactly why you can't make a decision from it.

2) Conditions get cut, so "yes, but" turns into "yes". Conditions are short and tend to come at the end of a sentence, which puts them among the first things compression drops.

SAID:     Yes, we can ship the new search, but only if p95 stays under 200ms
          in staging.
SUMMARY:  Approved shipping the new search.

3) Open loops disappear. Lines that push a question to later ("we'll look into it", "after the demo", "I'm not sure that scales") often get no reply in the conversation, so nothing flags them as important. Sometimes they're dropped. Sometimes they come back as finished tasks.

SAID:     Huy: I'm not sure the batching approach scales past one region.
          Lan: Let's look into it after the demo.
SUMMARY:  (nothing)            ← dropped
   or:    Batching approach confirmed for rollout.   ← rewritten as closed

How to spot the gaps on the page

You can catch most of this without opening the transcript. Watch for four tells:

• ▹Confident action items with no named agreement. "Minh to own the migration" tells you who does the work. It doesn't tell you who agreed the work should happen, and having an owner doesn't mean a decision was made.
• ▹Passive voice. "It was decided", "it was agreed", "the approach was confirmed" all leave the person out. Real decisions usually have one. If nobody is named, the decision may not exist either.
• ▹Sentences that hedge, name nobody and take no side, like "The team discussed…", "various concerns were raised" or "trade-offs were considered". Treat each one as a marker that an argument happened there.
• ▹Decisions with no condition or caveat at all. Real engineering and business decisions nearly always come with an "if", a "for now" or an "until". If every decision in the recap is unconditional, assume some conditions got cut.

The method: a 5-minute 'read it backwards' audit

Don't reread the whole transcript. Check only the places where the summary says something is finished, because those are the claims people will act on.

• ▹Step 1 (1 min): List what the summary says is closed. Copy out every decision, every owner and every line with "confirmed", "agreed" or "approved". These are the summary's claims.
• ▹Step 2 (1 min): Find the person who said yes to each decision. Search the transcript for the topic and look for a real "yes, let's do it" from someone with the authority to say it. Someone volunteering to do the work doesn't count.
• ▹Step 3 (2 min): Read the transcript wherever the summary hedges or names nobody. Jump straight to the "team discussed…" lines. That's usually where you'll find the argument, the condition or the "revisit Thursday".
• ▹Step 4 (1 min): Write down what was falsely closed and send it to the group. Keep it short: "Recap says X was agreed. From the transcript it's open until Thursday's load test. Correct me if I missed it." That fixes the record for everyone who read the same recap.

Skip anything the summary already marks as open or uncertain, because it's being honest about those. Spend your five minutes on what it claims is done.

Upgrade the prompt so the summary keeps the doubt

Most tools give you a default "summarize" button: Zoom AI Companion, Copilot in Teams, Gemini in Meet, Slack AI recaps, or Claude or ChatGPT with a pasted transcript. If your tool lets you ask a follow-up, or you can paste the transcript into a chat model, ask for this structure instead:

Summarize this meeting transcript. Do not smooth over disagreement.

1. DECISIONS — for each one:
   - What was decided
   - Who explicitly agreed (names + a short quote). If nobody clearly
     said yes, put it under STILL OPEN instead.
   - Conditions attached ("only if", "for now", "until"), verbatim
   - Strongest objection raised, and who raised it

2. ACTION ITEMS — owner, task, and which decision it depends on.

3. STILL OPEN — anything deferred ("revisit", "look into it",
   "after X"), any unresolved concern, and any split opinion.
   Include who raised it.

If you are unsure whether something was decided, treat it as open.

Run the Tuesday transcript through it and you get something like this:

DECISIONS
  (none)

ACTION ITEMS
  • Minh — owns event store migration IF it goes ahead
    (depends on: Thursday decision)

STILL OPEN
  • Move orders service to event store?
    Objection (Lan): not convinced it holds at peak load.
    Deferred (Huy): revisit Thursday with load test numbers.

Same meeting, same facts. This time you asked the summary to track what's still open, which makes it much harder for an open question to quietly vanish. It isn't a guarantee, so keep doing the audit.

Why this compounds once agents are in the loop

In my PhD work on multi-agent systems, the failure I keep running into is the lossy handoff. Each step passes on a slightly cleaner, slightly more confident version of what it was given. Meeting recaps are now the first link in that chain: the recap becomes a ticket, and the ticket becomes the prompt for a coding agent. Once "revisit Thursday" drops out of the recap, nothing downstream knows it existed, and the agent can't ask about a question it never saw. By the third handoff, "yes, only if p95 < 200ms" has turned into "implement new search", and the agent carries it out quickly and with total confidence. Later lessons on handing work to agents cover how to carry conditions and open questions through each step. For now, take one rule away: the recap is the cheapest place to catch a false closure, because it hasn't become anyone's task yet.

Closing card: 5 questions before you act on any summary

┌───────────────────────────────────────────────────────────┐
│  BEFORE YOU ACT ON AN AI SUMMARY                          │
│                                                           │
│  1. What does this summary claim is CLOSED?               │
│  2. For each decision: WHO actually said yes?             │
│  3. Which sentences name NO ONE and take NO side?         │
│     → that's where the argument was. Check it.            │
│  4. Where are the "only if / for now / until"?            │
│     No conditions anywhere = conditions were dropped.     │
│  5. What's in "still open"? If nothing → be suspicious.   │
│                                                           │
│  Only open the transcript for what it says is DONE.       │
└───────────────────────────────────────────────────────────┘

Day 10 flips this around. It's about writing messages and docs that summarize well, so the AI recap of your own thread keeps your conditions and open questions.

Extend your knowledge

• ▹Try it this week. Take one recap of a meeting you attended, run the 5-minute audit and count the falsely closed items. Then do the same for a meeting you skipped.
• ▹Save the prompt above as a template in whatever tool you use (Zoom AI Companion, Copilot in Teams, Gemini in Meet, or Claude or ChatGPT with a pasted transcript). Run it on one meeting and compare the result with that meeting's default recap.
• ▹Read Michael Nygard's 2011 post 'Documenting Architecture Decisions', which introduced the Architecture Decision Record (ADR). Its explicit 'Status' and 'Consequences' fields are the human version of the structure you're asking the AI for.
• ▹If you lead a team, agree on one rule: nobody creates a ticket from an AI recap unless the decision has a named person who said yes.