From what was said to what you know

These resources split in two. One half is about the calendar: prioritisation, blocking, deep work, how many meetings a week can hold before it stops producing anything. The other half is about notes: slip boxes, folders, links and maps, and the attempts to make what you learned outlast the week you learned it.

They are usually read separately, which misses the point where they meet. Time management produces the meetings; knowledge management is what survives them. Harvard Business Review's 2017 piece on meeting overload put executives at close to 23 hours a week, against under 10 in the 1960s. Even a hard-audited calendar produces hours of speech a week, and by default almost none of it is written down anywhere findable.

So the first half is about having fewer and better meetings (meeting overload) and the second about what to do with the ones you keep. This article is the join: five stages, each making one decision and failing in one characteristic way.

These are not a product architecture. They describe what has to happen between someone saying a sentence out loud and you answering a question about it eighteen months later.

Two properties of the chain matter. Each stage is capped by the one before it, so a brilliant retrieval layer over an empty capture layer answers nothing. And every stage except the first can be redone later. How you extract, file and query stays revisable for a decade, while a conversation that was never captured is gone.

The decision here is what starts the recording. Three answers, differing mostly in what they miss.

A person taking notes. The oldest answer and still the most common. It captures what one participant thought was important while they were also trying to participate. The note-taker is the person least able to argue a point, and nothing they wrote can be checked.

A bot in the call. This works for scheduled video calls and nothing else: not the unscheduled follow-up, the at-desk conversation between two people on one laptop, or the second half that ran past its booking. It is also socially loud, since inviting a recorder changes the first two minutes.

The device itself. Capture at the level of the machine, not the call, running whether or not anything is scheduled, with the boundaries of a meeting drawn afterwards. This misses the least and asks the most in trust, because recording continuously while transmitting continuously is a different proposition from recording continuously and never transmitting.

Earkeep is one way to fill this stage. It runs continuously on your device, so there is nothing to start and no bot to invite, and a meeting is defined afterwards by selecting its span on a timeline. Transcription happens locally, and the audio is processed in memory and never written to disk. What ends up stored is text, in plain files in a folder you choose, which is the detail that matters for every stage below.

Capture is also where consent lives. Legal requirements vary by jurisdiction and social ones do not: say that you keep a transcript, and say where it goes. The second half is easier when the honest answer is that it stays on the machine in front of you.

The decision here is where the audio is allowed to go. Running speech recognition locally stopped being exotic around 2023: open models in the Whisper family turn an hour of meeting audio into text in minutes on a laptop, with no network involved. Uploading instead buys a little accuracy and costs you the ability to answer the consent question in one sentence.

The second decision is what the text carries. Insist on timestamps on every segment, because time is how you navigate back into an hour of talk, and a note pointing at a moment is checkable. Insist on speaker attribution where you can get it, because who committed to a thing is half the content of a commitment. Accept in exchange that the text will be wrong in places, particularly around names and jargon, which is why every later stage keeps a pointer back to the source instead of treating the transcript as scripture.

What matters most is what this stage does not do. Speech runs at something like 120 to 150 words a minute, so an hour of conversation becomes several thousand words: a recording in a different medium. Searchable, which is a real gain, but not a note, and a folder of them is not a knowledge base.

Extraction is the compression step: several thousand words in, between zero and three durable items out. Tiago Forte gives it the D in CODE (capture, organize, distill, express), the part that turns a collection into something usable. Four kinds of thing are worth pulling out of a meeting:

• Decisions, with their reasoning. The decision alone ages badly: six months later the only question anyone asks is why, and a decision line without a because is an invitation to relitigate it. One line per decision, naming the alternative that was rejected and why, is enough. Kept as an append-only series, not a page you edit, this is a decision log.
• Commitments, with a named owner. An action item with no owner is an observation. This is the one meeting output that belongs in a task system, which is the boundary David Allen's GTD draws: it organises actions, not knowledge.
• Constraints and facts stated in passing. The contract renews in March, the database cannot take another index, the regulator reads it this way. Often the most valuable thing said all hour and the least likely to be written down.
• Open questions, with an owner. The thing you agreed you did not know yet, otherwise rediscovered from scratch by someone else in a later meeting.

Most meetings yield one of these, or none. Forcing an extraction out of every meeting fills a knowledge base with restatements of what everyone already knew.

Then the honest part. This is the stage that breaks, because nobody does it by hand for long. Done properly it costs ten to fifteen minutes per meeting, falling due exactly when the next meeting starts.

So the only version of this stage that survives a real week is a cheap one: a model drafts and a human confirms. An agent reads the transcript, proposes the four categories, flags what is ambiguous, and you spend two minutes accepting, correcting or deleting. Two minutes that happen beat fifteen that do not. The framing to keep is the one running through most current work on AI and notes, covered in AI-enhanced PKM: the model is a curator, not an author. It does not get to file an unread claim into the record, because a wrong decision line is read later with the same confidence as a correct one. Which is why every extracted item keeps a pointer back to the transcript and the timestamp it came from.

Now there are items, and they need somewhere to live. The two dominant traditions answer different questions, and the mistake is picking one for everything.

PARA files by actionability: Projects, Areas, Resources, Archives. A note goes where it will be used, not where it belongs by subject. That is the home for everything a meeting produces that is for something. A decision belongs to the project it constrains, a commitment to the project it advances, and a constraint that outlives every project it touches to an Area. Filing by subject instead produces a folder called Pricing holding eleven notes from three years and answering no question anyone has.

The Zettelkasten tradition files by connection. Niklas Luhmann's slip box held roughly 90,000 cards organised by links, not categories, and Andy Matuschak's evergreen notes are the modern restatement: atomicity, dense linking, writing in your own words. That is the home for the other kind of output: the concept you had to think about, the pattern showing up across customers, the distinction that took the team an hour to draw. Not for a project, and found by what they connect to.

The third layer, once there is enough material, is a map of content. Nick Milo's rule for when to write one is the useful part. At the mental squeeze point, when you have more notes on a theme than you can hold in your head. One map per project makes a year of meetings legible in an hour, and it survives handover, which nothing else here does.

Underneath sits a format decision that looks boring and outlives every other choice here. A knowledge base's value is a function of its age, since the transcript from two years ago is the one that settles the argument, so the container has to survive you changing tools and a vendor changing its business model. Plain text or JSONL in a folder you chose clears that bar; almost nothing else does. Which tool you point at the folder is then reversible, and the candidates are compared in Obsidian, Logseq and SiYuan.

The last stage is the one people design first. The three answers do not compete. They serve different question shapes at wildly different setup costs.

Plain search. grep, ripgrep, or your editor's find-in-files. It answers the lookup: which meeting mentioned the Postgres migration, when the renewal date first came up. No infrastructure, no index, no maintenance, the exact line returned with its file and timestamp, and it will still work in fifteen years. The unglamorous truth is that most questions people ask their own archive are lookups.

Local retrieval. When you do not know the words, keyword search cannot help and semantic retrieval can: an embedding model, a vector database such as Chroma or Qdrant, and a local model through Ollama or llama.cpp answering over the passages it pulls back. The right tool for a question like what customers have said about onboarding friction, where the phrasing differs every time. It costs an index to maintain and hardware enough to make embedding tolerable; the stack is in local RAG.

A compiled knowledge base. The third shape is synthesis: what our current position on something is, and how it changed. Retrieval handles that badly, because the answer is not in any one passage. Andrej Karpathy's LLM Wiki pattern, a gist published in September 2024, inverts the order: instead of retrieving from raw sources at query time, an agent compiles them ahead of time into a maintained wiki. Three layers (immutable raw sources, a generated wiki, a schema file telling the agent how to maintain it) and three operations (ingest, query, lint). Applied to meetings, that is LLM Wiki.

Be clear-eyed about the third. Most people never need it. It earns its keep when the corpus is a year deep or shared across a team, when the same synthesis question is asked repeatedly, and when someone owns the maintenance, because a compiled wiki nobody lints goes stale in a way a raw transcript cannot. Below that, it is a lot of machinery pointed at a folder you could read.

One rule spans all three: every answer keeps a link back to the transcript it came from. A knowledge base you cannot check is a rumour mill with better formatting.