From meeting to knowledge base: a complete pipeline

Six stages, each consuming the previous one's output. The useful discipline is that every stage after the first is replaceable, and the first is not — you can change how you extract, organize or query at any time, but a meeting that was never captured is gone permanently.

Two models exist. Calendar-triggered capture starts when a scheduled meeting starts — tidy, and it misses the corridor call, the meeting that ran into an unscheduled second half, and the ad-hoc conversation where the real decision got made. Always-on capture records continuously and lets you define meetings afterwards, which catches all of it at the cost of requiring you to trust where the audio goes.

That trust is the whole design question, and it is why local processing and always-on capture belong together: a tool that continuously records and continuously uploads is a different proposition from one that continuously records and never transmits. Earkeep takes the second position — mic and system audio recorded continuously while it runs, transcribed on your device, with audio processed only in memory and never written to disk. Meetings are defined afterwards by selecting a span on a timeline, or automatically from a connected calendar, which means the two models are not exclusive: the calendar names the spans it knows about and the timeline covers everything it doesn't. See meetings after the fact and calendar.

Whichever you choose, this is where consent lives. Recording other people has legal requirements that vary by jurisdiction and social requirements that do not vary at all — say that you keep a transcript, and say where it goes. "It stays on my laptop" is a much easier sentence than the alternative.

Local transcription is a solved problem as of the last two years. Whisper — via whisper.cpp, which runs on Metal on Apple Silicon — is the default, with Parakeet a faster English-only alternative. On a recent Mac, a one-hour meeting transcribes in minutes without touching a network.

What to insist on at this stage: timestamps on every segment, because time is how you will navigate later; speaker attribution if you can get it, since "who committed to that" is unanswerable without it; and an output format that is plain text rather than a proprietary container. What to accept: the text will contain errors, particularly around names and jargon, which is the reason every later stage keeps a link back to the source rather than treating the transcript as gospel.

The privacy argument for doing it here rather than in a cloud service is covered in private by design and, more broadly, in local-first AI at work.

This is the compression stage: an hour of speech becomes between zero and three durable items. Four kinds are worth extracting, and they behave differently — decisions with their reasoning, action items with a named owner, constraints someone stated in passing, and open questions with whoever owns them. Most meetings yield one or none, and forcing an extraction from every meeting is how a knowledge base fills with noise.

An agent does a good first pass: read the transcript, propose the four categories, flag anything ambiguous. What it should not do is file its output unreviewed. A wrong decision line is worse than no decision line, because it will be read later with the same confidence as a correct one and nothing marks it as unverified. The workable division is that the agent drafts and you confirm — two minutes per meeting instead of fifteen. The format for the decisions themselves is in the meeting decision log, and the discipline of doing it at all is never leave a meeting empty-handed.

Two traditions, and they answer different questions. PARA — Projects, Areas, Resources, Archives — sorts by actionability and handles the operational output: this decision belongs to that project, this constraint belongs to an area because it outlives every project it touches. Zettelkasten and its descendants sort by connection: one idea per note, linked densely, with structure emerging from the material rather than imposed on it.

Use both, on different material. Action items and project decisions go in PARA, where they are found by what they are for. Concepts, constraints and recurring patterns go in the linked layer, where they are found by what they relate to — and a Map of Content per project retrospective is the artifact that makes a year of meetings legible in an hour. The detail is in building a personal knowledge base from meeting notes.

The rule that saves the most time: do not design the hierarchy first. Let it follow the material, and make a map when you have enough notes on a theme that you cannot hold them in mind.

The storage decision looks boring and outlives every other choice on this page. A knowledge base's value is a function of its age — the transcript from two years ago is the one that settles the argument — so the format has to be one that survives you changing tools, changing employers, and the vendor changing its business model.

Which in practice means: plain text or JSONL, one file per day, in a folder you chose, on a disk you control, ideally in version control. Every tool you might ever want — grep, an editor, a script, a model that does not exist yet — can read that. Nothing else clears the same bar. The full argument is plain files beat platform lock-in; the shape Earkeep writes is one .jsonl per day with spans marked inline, which is deliberately the least clever option available.

Three ways to ask, in increasing order of setup cost, and the right answer is usually all three.

• Search. grep, or your editor's find. Answers "which meeting mentioned Postgres" instantly, needs no infrastructure, and will still work in a decade. Underrated: most questions are lookups.
• An agent with file access. A local coding agent reading the folder answers "summarize what we said about pricing this quarter" with no index to maintain. Earkeep exposes an MCP server for exactly this — see agents and MCP and feeding meeting context to AI agents.
• Retrieval or a compiled wiki. At the scale of a year or a team, semantic retrieval finds what keyword search misses (local RAG), and a compiled knowledge base answers the synthesis questions retrieval handles badly (LLM Wiki from meeting transcripts).

One rule across all three: every answer keeps a link to the transcript it came from. A knowledge base you cannot check is a rumour mill with better formatting, and the link is what makes the difference between the two.

Not at stage six. The common failure is designing the query layer — choosing a vector database, writing a schema — against a corpus of eleven transcripts, which is a lot of infrastructure for a folder you could read.

Start at stage one and let it run for a month. Capture everything, transcribe locally, write one decision line per meeting that had one, and keep the files in a folder. That is stages 1, 2, 3 and 5 with no tooling beyond a text editor, and it is already more than most teams have. Stages 4 and 6 become obvious once there is enough material to make them necessary — and they can be added at any time, because the raw layer never had to anticipate them. That is the entire reason for keeping it plain.

For the meeting practices this pipeline feeds on, see meeting workflows; for defending the time it saves you, time management for meeting-heavy roles.

Download Earkeep free for macOS and begin accumulating the raw layer everything else is built on.