How to build a meeting context system in Tana

TL;DR

• Teams lose context between meetings because every call produces its own disconnected notes. The fix is a meeting context system: one record per project that each meeting updates, instead of a new summary per call.
• Build it in six moves: capture every meeting into the same place, mark decisions as they happen, pin the project record so extraction updates it, file the follow-through into your trackers, ask past meetings questions instead of re-reading notes, and walk into the next call briefed.
• Tana runs the carry-forward for you: it captures your meetings (its own and external Zoom, Teams, or Meet calls, without a bot), updates the pinned Product Track rather than spawning a parallel summary, files action items as proposals you approve, and answers "what did we decide last week" with receipts.

Every team knows the loop. A good discussion on Tuesday, a clear decision, and three weeks later the same question is back on the agenda because nobody can find where it was settled. The notes exist, spread across a dozen meeting docs, but the context does not carry. Meeting context management fixes this: one connected record per project that every meeting updates. This guide shows how to build that system, and how Tana's meeting agents do the carrying for you: they capture the call, update the project record instead of writing another summary, and answer questions about past meetings with the evidence attached.

Why context gets lost between meetings

The failure is structural, not personal. Most tools produce one notes document per meeting, so a project that meets weekly accumulates a stack of summaries nobody reconciles. The decision from week two sits in a doc nobody reopens, and a new teammate has twelve recaps to read instead of one current picture. Everything is recorded somewhere; what breaks is continuity, because nothing connects this meeting to the last one. A meeting context system inverts the model: the project record is the unit, and meetings update it. (For the thinking behind that inversion, see how to create shared meeting memory.)

How to build a meeting context system, step by step

The method works for any recurring meeting: a weekly product sync, a customer account, a project standup. Under each step is how Tana does it for you.

Step 1: capture every meeting into the same place

A context system starts with complete capture, because a meeting that leaves no record leaves a hole the team fills with memory, and it has to cover all your meetings, not only the ones on your own tool. Tana captures meetings natively and also captures external Zoom, Teams, and Meet calls without a bot joining: the desktop app records the audio and takes screenshots of anything screen-shared, in the background, so every call lands in the same shared context.

Step 2: mark decisions while they happen

The most expensive thing to lose between meetings is a decision, because a lost decision gets relitigated. Do not reconstruct decisions from the recap afterward, mark them in the moment. In Tana, the Capture control turns a stretch of discussion into a typed item during the call: a Decision, a Task, a Bug, or any custom type your team uses. If you want more structure, ask chat in plain language to create a Decision type with a rationale field, and every decision from then on carries its why.

Step 3: pin the project so every meeting updates one record

This is the step that makes it a system instead of a pile of notes. Before the meeting, pin the project doc or Product Track to it. When Tana's extraction runs after the call, it updates that record instead of creating a parallel one: outcomes land on the project, existing items get updated rather than duplicated, and re-running extraction refreshes what is there instead of spawning another summary. Week five's meeting builds on week four's record, in the same place, so the project has one current record that every meeting feeds. How you shape those records is up to you, see organize your context.

Step 4: file the follow-through where the work lives

Context also leaks between meetings when action items live in the notes instead of the tracker. After the call, Tana's extraction produces one canonical summary plus action items assigned to the person the conversation pointed at, and files the work into the trackers your team already runs on, including Linear, GitHub, Jira, Slack, HubSpot, Pipedrive, and more, with the screen-share screenshots embedded. Everything arrives as a proposal you review and approve before it is written anywhere, so nothing lands that a person did not sign off on.

Step 5: ask instead of searching

The test of a context system is retrieval: can anyone on the team answer "what did we decide about this, and why" without re-reading a month of notes? In Tana you ask chat and get an answer grounded in what was actually recorded, with receipts: "what did we decide this week", "why did we go with the phased rollout". A challenged decision is settled by evidence, not by whoever remembers loudest.

Step 6: walk into the next meeting briefed

Continuity runs in both directions: the last meeting should feed the next one. In Tana, a scheduled agent briefs you before a meeting from your connected context and leaves a prep doc: where the project stands, what was decided last time, what is still open. The first ten minutes of the call stop being reconstruction and start being work.

What this looks like in Tana

Take a weekly product sync. Week one, you pin the Product Track to the meeting. The team debates scope, and you capture the outcome as a Decision during the call. Afterward, extraction proposes updates to the track: a summary, two tasks assigned to the people the conversation pointed at, an issue filed to Linear with the screenshot of the design that was on screen. You approve them, and the track reflects the meeting.

Week three, someone asks "didn't we already settle the pricing question?" Instead of scrolling old docs, you ask chat and get the answer with the receipt: decided in week one, here is the reasoning. Week four, a new engineer joins. She does not read three recaps, she reads the track, one current record of where the project is and how it got there. No one on the team maintained any of this themselves. The meetings did.

Where a general chatbot or notetaker fits

A notetaker gives you a faithful transcript and a clean summary of each call, and if a record of each meeting is all you need, that is enough, and less to set up. A general chatbot is a fine place to paste a transcript and think through one conversation. The ceiling is continuity: each meeting stays its own record, summaries accumulate without ever updating each other, and stitching week four to week one is work you do yourself. That is meeting notes, done well. A meeting context system is a different job: every call updates the same project record, decisions stay attached to the work, and questions get answered from the whole history. That connection is what Tana automates, so choose by whether you need each meeting remembered, or the project to remember.

Frequently asked questions

How do you stop losing context between meetings?

Stop treating each meeting as its own document. Capture every call into one shared place, mark decisions during the meeting, and attach each meeting to the project record it concerns, so outcomes update one record instead of scattering across recaps. Tana does this automatically: pin a Product Track to a recurring meeting and extraction updates that track after every call, so context carries forward instead of resetting each week.

What is meeting context management?

Meeting context management is the practice of keeping what happens in meetings, the decisions, the open questions, the follow-through, connected to the ongoing work, so any meeting can build on the ones before it. It differs from notetaking in the unit of record: notes produce a document per meeting, context management maintains one record per project that meetings update. Tana is built around the second model, with capture, typed decisions, and extraction that updates the pinned record.

How do you keep track of decisions across meetings?

Capture decisions as structured items at the moment they are made, not as lines buried in a recap. In Tana the Capture control marks a Decision during the call, and you can ask chat to create a Decision type with a rationale field so every decision carries its reasoning. Later, asking chat "what did we decide about X" returns the decision with its receipt, so it does not get relitigated.

How do you avoid a new summary document for every meeting?

Give extraction a target. When meeting notes have nowhere to land, every call defaults to a fresh document, and the project's story fragments across them. In Tana you pin the project doc or Product Track to the meeting, and extraction updates that record, refreshing existing outcomes and de-duplicating rather than adding another summary. One project, one record, however many meetings feed it.

How do you bring a new team member up to speed on a project?

Point them at the project record, not the meeting archive. If every meeting has been updating one record, a new teammate reads the current state and the decisions that shaped it in one place, and can ask chat for anything deeper, with answers grounded in what was recorded. In Tana that record exists as a byproduct of running your meetings, so onboarding does not depend on someone writing a catch-up doc themselves.

Is a meeting context system the same as giving AI agents company context?

They are related layers with different audiences. A meeting context system keeps a human team's project continuity intact between calls: decisions findable, records current, follow-through filed. A company context layer makes that same knowledge available to AI agents, so an agent can act on what your team knows. In Tana the first feeds the second: the records your meetings build become the context agents draw on. For that broader layer, see how to give AI agents company context.