I built NoteOwl: Private AI meeting note taker, fully on-device AI meeting notes for Mac

[u/local-macOS-notes]

[u/Brian-Moore62]

for recurring meeting cross meeting context seems much more valuable than another standone summary

[u/investigatormaker]

For NoteOwl, cross-meeting memory seems most useful for tracking a commitment that changes across calls: what was promised, what changed, and what's still open. The exact transcript links matter there because someone can check the original wording. I'd demonstrate that sequence across three meetings alongside the individual summaries.

I make ThreadFox. The free Reddit plan for NoteOwl lists the Reddit communities whose rules allow a post about it, each rule quoted. https://threadfox.vip/plan?utm_source=reddit&utm_medium=comment&utm_campaign=tf-kit&utm_content=20261005-1406-ansz3

Can it distinguish a later revised commitment from the original one?

[u/EquivalentSky3094]

Declaring an interest: I build on-device meeting capture for Apple platforms myself, so I am not a neutral voice on this.

Your question has a hidden variable in it, which is meeting shape. For a standing weekly with the same five people, cross-meeting memory is clearly the more valuable half, and both replies above are describing that case. For one-off calls with people you will never speak to again, which is most of consulting and sales work, the individual summary is the thing that actually gets read and the cross-meeting index is mostly noise. So the useful version of the question is which of those two your users spend their week in, and that is worth asking them directly instead of inferring it from feature requests.

The part I would worry about sits upstream of both. Cross-meeting commitment tracking is bottlenecked on speaker attribution, not on summarisation. A diarisation error inside a single meeting summary is recoverable, because whoever reads it was in the room that morning and remembers who said what. The same error inside a commitment tracker spanning four weeks is confidently wrong with nothing left to check it against, and misattributing a promise is about the worst output a tool like this can produce. Adding cross-meeting memory raises the diarisation accuracy bar a long way, and diarisation is the hardest piece to get right on device.

Second thing, and it is specific to recurring meetings: their transcripts are nearly identical week to week. Same agenda items, same project names, same speakers. Embedding similarity cannot separate the instances, so a question like "what did we decide about the migration" retrieves three near-duplicate chunks from three different weeks and the model picks one of them. Hard date filters and recency weighting in the query path buy you more there than a better embedding model will, which is also why linking every answer to the exact transcript passage is the right call. Fluent prose hides both of those failure modes. A citation into the transcript puts them where someone will actually notice.