TL;DR

Most companies lose the knowledge from their meetings. It is spoken, half-captured in scattered notes, and never becomes anything the team can search later.
A meeting knowledge base fixes that by turning every meeting into structured, connected records, decisions, action items, and topics, that live in one searchable place instead of a folder of transcripts.
You can build one in Tana without manual documentation: meetings are captured without a bot, extraction files structured items you approve, and everything connects into one record you and your AI can query.
After setup, it maintains itself. Each meeting is processed automatically, re-running extraction updates the existing record instead of duplicating it, and the knowledge base is current because keeping it current is the system's job.

Every meeting produces knowledge, and most of it evaporates. The decision made on Tuesday, the reason behind it, the owner who took it on, all of it lives in someone's memory and a transcript nobody reopens. A meeting knowledge base is the fix: a place where every meeting becomes structured, searchable records the whole team can query. The catch is that building one by hand, writing up notes after every call, is exactly the work that never gets done. This guide shows how to build a meeting knowledge base in Tana that fills itself, so the documentation happens as a side effect of meeting. For the broader category of tools, see Best AI knowledge management software 2026.

What makes it a knowledge base, not a folder of transcripts

A pile of meeting notes is not a knowledge base. Four properties make the difference, and they are the checklist for the steps below:

Structured, not raw. Meetings come out as typed records, decisions, action items, topics, not walls of transcript text, so they can be filtered and connected.
Connected. Each record links to the meeting, people, and project it belongs to, so you can follow a decision back to the conversation that produced it.
Current. New meetings update the existing record rather than stacking another summary, so the knowledge base reflects the latest state.
Queryable. The team, and the team's AI, can ask the record a question and get a grounded answer, instead of searching transcripts by keyword.

Tana covers all four out of the box. Here is the setup.

How to build a meeting knowledge base in Tana, step by step

Five steps. The first two get a single meeting into the knowledge base; the last three make the meetings add up to a record worth querying.

Step 1: capture every meeting without a bot

The knowledge base starts at the call, because anything reconstructed afterward has already lost detail. In Tana there are two capture paths that together cover every meeting: run the call as a Tana meeting and it transcribes in real time with speaker identification, or let the desktop app capture an external call on Zoom, Teams, or Meet from your side, with no bot joining. Either way the raw material enters the system the same way, which is what makes the knowledge base uniform rather than a mix of formats. Capture is on by default, and off-the-record mode pauses it for anything sensitive.

Step 2: extract structured records, automatically

Raw transcripts are storage, not knowledge. When a call ends, Tana processes it on its own: it produces a summary and extracts the decisions and action items as structured, typed items, assigning tasks to the right person. Everything the AI produces arrives as a proposal you approve before it is written, so the knowledge base is automated and reviewed at the same time. You are not transcribing or writing up notes; you are confirming records the AI drafted.

Step 3: give the knowledge base a shape

Structure is what makes the base searchable rather than just full. Beyond the built-in decisions and action items, ask chat to create the types your team refers to repeatedly, for example a Decision type with fields for the date, owner, project, and rationale. AI instructions on the type tell the AI how to fill it consistently, so every future meeting files records in the same shape no matter who ran the call. Now the base is a dataset you can filter, not a search box over text.

Step 4: keep it current by updating, not adding

Here is where most meeting archives fail. A notes tool gives you one more summary per meeting, and the hundredth summary does not know about the first ninety-nine. Tana works the other way: re-running extraction updates existing records rather than creating duplicates, and pinning a document to a recurring meeting makes extraction update that document instead of spawning a parallel one. The knowledge base reflects the current state of a project, not a stack of point-in-time snapshots someone has to reconcile.

Step 5: query the knowledge base instead of re-reading notes

This is the payoff. Once meetings live in one connected record, ask chat "what did we decide about pricing this quarter" or "which meetings touched the onboarding redesign," and Tana answers from what was actually recorded, with the source meetings behind it. Two extensions are worth setting up once the basics run: a scheduled agent that digests new decisions weekly, and a connection to your other tools over the MCP server, so a coding or research agent can pull the relevant meeting knowledge while it works. The knowledge base stops being an archive you hope to search and becomes a memory you question.

Where a general tool falls short

Plenty of teams try to build this with a wiki plus a notetaker: the notetaker drops a transcript, and someone is supposed to write the important parts into the wiki. It fails for a structural reason, not a missing feature: the write-up step depends on discipline that erodes, and the wiki goes stale the moment it stops being updated. A general chatbot has the opposite problem, it can summarize a transcript you paste in, but the output is a reply in a thread, not a connected record the next meeting builds on. A meeting knowledge base needs capture, structure, and updating to be one automatic flow, which is the system these steps set up. For the fuller comparison, see Best organizational memory tools 2026.

What you have when it is running

After setup, documentation stops being a task. You hold the meeting; Tana captures it, extracts the decisions and action items as structured records you approve, connects them to the right projects and people, and folds them into a base that stays current on its own. The new hire searches the knowledge base instead of asking who was in the room. The PM answers "why did we decide this" from the meeting it happened in. And the record is trustworthy because it updates as meetings happen rather than depending on someone to write it up. That is the difference between recording meetings and remembering them.

Frequently asked questions

How do you build a knowledge base from meetings automatically?

Capture every meeting, extract the decisions and action items as structured records rather than raw text, and file them into one connected place that updates as new meetings happen. The key is that capture, extraction, and updating are automatic, so no one has to write up notes. In Tana, meetings are captured without a bot, extraction files typed records you approve, and re-running it updates the existing record instead of duplicating, so the knowledge base builds itself.

What is a meeting knowledge base?

It is a searchable, connected record of everything your meetings produce, decisions, action items, and the topics behind them, structured so the team can query it later instead of re-reading transcripts. Unlike a folder of notes, the records are typed and linked to the people and projects they concern. Tana builds one from your meetings automatically and keeps it current, so it functions as team memory rather than an archive.

Can Tana turn meeting transcripts into a searchable knowledge base?

Yes. Tana transcribes the meeting (its own calls, or external Zoom, Teams, and Meet calls without a bot), then extracts a summary plus decisions and action items as structured items you approve. Those records connect into one graph you query from chat, so instead of searching transcript text you ask a question and get an answer grounded in the meetings it came from, with the sources attached.

How is this different from just saving meeting notes in a wiki?

A wiki holds pages someone has to write and keep current, and it goes stale the moment that stops. A meeting knowledge base in Tana fills itself: the records are extracted from the meeting automatically, structured so they can be filtered and connected, and updated in place as new meetings happen. You get the searchable, current record a wiki promises without the manual upkeep that makes wikis rot.

Can AI agents use my meeting knowledge base?

Yes. Tana runs an MCP server, so an AI agent such as Claude Code can retrieve from your meeting knowledge base while it works, grounded in what your team actually decided, and access controls mean it only sees what its user is allowed to. That turns the knowledge base from a human reference into a source your team's agents draw on too. For the deeper pattern, see What is context engineering for AI agents.