Key takeaways
- A meeting agent produces five artifacts, not one: the recording, the transcript, the summary, the extracted commitments and any generated documents. Each carries a different value and a different exposure, so a single retention rule cannot fit them.
- The transcript is the highest-exposure artifact and the least read. It holds the half-formed position, the number floated before anyone checked it and the objection withdrawn thirty seconds later.
- The commitments are the smallest artifact and usually the most valuable, because they are the part that changes what people do next week.
- Recordings and transcripts stay in the recording tool under its own retention setting. Summaries, commitments and documents come into your working system. Do not copy what you do not need to hold.
- Four situations override the whole policy: regulated work, live negotiations, anything with a legal tail, and the discovery months later that a summary dropped a qualifier that mattered. The first three are foreseeable and belong in the policy as named carve-outs. The fourth is why access to the original has to survive even under the strictest default.
In this article
Connect an AI agent to your meetings and you have set a retention policy. You may not have written one, chosen one, or told anyone what it is, but the tool now has defaults and those defaults are your policy until you replace them.
This is the replacement. What follows is what to keep, where each piece should live, how long it stays, who owns the policy, and the cases where the default is wrong. It is meant to be adopted in an afternoon and argued with afterwards.
I set this up for my own practice earlier this year, before the tooling made it urgent. The rules below are the ones I actually run.
First: a meeting agent produces five things, not one
Almost every discussion of meeting AI treats “the recording” as a single object. It is not, and the whole policy depends on separating it, because these five artifacts have different useful lifespans and different risk profiles.
The recording. Audio or video of the conversation. Highest fidelity, largest storage, and the artifact most likely to contain something said casually by someone who forgot it was on.
The transcript. Text with speaker attribution. This is the unedited working state of the conversation: the half-formed position, the number floated before anyone checked it, the objection withdrawn thirty seconds later. High evidentiary value, high exposure, almost never read.
The summary. The model’s compression of what happened. Useful, lossy, and generated rather than observed, which means it carries model judgment that nobody reviewed.
The extracted commitments. Decisions, owners, due dates. The smallest artifact and usually the most valuable, because this is the part that changes what people do next week.
The generated documents. Anything produced during or from the meeting: a brief, a proposal draft, a spec. These are work products that happen to have originated in a conversation, and they belong wherever your other work products live.
Treating these as one blob is what produces the default policy of keeping everything forever, because the moment you decide the commitments are worth keeping, the recording rides along with them.
The policy, artifact by artifact
Recording. Do not copy. Stays in the recording tool, under that tool’s retention setting, reviewed annually.
Transcript. Do not copy. Stays in the recording tool, retrieved on request when you actually need it.
Summary. Keep, in your working system, for as long as the relationship is live.
Commitments. Keep, in your working system and in whatever tracker your team already uses, until closed, then archived alongside the relationship.
Documents. Keep, wherever your other work products live, on their normal lifecycle.
The shape of that list is the whole argument: the two artifacts with the highest exposure are the two you do not copy. They still exist. They simply stay in one place, under one set of controls, rather than propagating into a second system that was never designed to hold them.
Three gates
A policy that only says what to keep is half a policy. These are the three decision points where the policy is actually enforced.
Gate 1: Entry. What enters your system at all.
Default off. Nothing moves from the recording tool into your working system automatically.
At my scale that means I name each meeting I want. At a company with hundreds of weekly meetings that is not a policy, it is a bottleneck, and the honest implementation is light automation with a real gate: a review queue, or an approval step tied to the room. What transfers between the two situations is not the keystroke, it is the fact that a human decided.
The reason to hold this line is that an agent filing everything by default builds a corpus nobody chose. You cannot audit a pile you never decided to create, and nobody goes looking for a problem in an archive they did not know was accumulating. This is the same failure pattern as shadow AI inside an executive team: the issue is not the tool, it is that its footprint grew without a decision anyone remembers making.
Gate 2: Persistence. What survives once it is in.
Summaries and commitments persist. Recordings and transcripts do not get copied.
This is the gate people push back on hardest, and the pushback is often right. See the exceptions below before adopting it.
Gate 3: Structure. How it is filed.
One room per relationship, not per date. A client, a project, an account. Mirror the structure your recording tool already uses rather than inventing a parallel one, because two divergent filing systems will drift and the drift is silent.
The reason is that nobody asks “what happened on April 14.” They ask “where did this client land on pricing,” and a date-based archive cannot answer that without a search that assumes you already know the words used. Filing by relationship means the unit of memory matches the unit of the question.
This is where the memory layer starts behaving like an asset rather than residue, which is the argument in the harness compounds, not the model. A structured, curated context layer is the part of an AI stack that actually belongs to you. An unstructured pile is just storage cost with a retrieval problem attached.
The four exceptions that override all of it
The persistence gate is a default, not an absolute. There are situations where the raw record is the source of truth and a summary is not an acceptable substitute.
Regulated work. If your sector requires records of client interactions, the requirement governs and this policy does not. Check what you are actually obligated to keep before you decide what to let go, and get that answer from someone qualified to give it rather than from an article.
Live negotiations. During an active negotiation the exact wording matters, and it matters asymmetrically: the party with the record has the advantage. A summary that says “agreed to revisit pricing” is not the same asset as the sentence that was said.
Anything with a legal tail. Disputes, terminations, incidents. The moment a matter is reasonably foreseeable, retention decisions stop being an operational preference and become a legal question with its own rules.
When the summary turns out to be wrong. This is the one people forget, and it is the most common in practice. Summaries are model output. You often discover months later that a compression dropped a qualifier that mattered, and by then the only way to check is the raw record. This is the strongest single argument for keeping the original accessible somewhere, even when you have decided not to hold it yourself.
Three of these four are foreseeable in advance and belong in the policy as named carve-outs by room. The fourth is why access to the original matters even under the strictest default.
What a connector changes, and what it does not
The reason the persistence gate became easy rather than costly is that retrieval got cheap.
A connector links an AI assistant directly to the source system, so a transcript can be pulled on request instead of stored in advance. Timeless shipped one for Claude that retrieves a document created in a meeting, a specific recording, or a full transcript. Anthropic reported in July 2026 that its connector directory lists over 950 MCP servers, used by millions of people daily, so this is a category shift rather than one vendor’s feature.
Retrieval on demand replaces storage. That is the sentence that makes the whole policy affordable. The strict version stops requiring a sacrifice once you can reach the original in seconds on the rare occasion you need it.
On the security question, which is the first thing most executives ask: a connector grants no new access. Anthropic’s documentation states that Claude inherits each person’s permissions from the connected service, and that if someone cannot access a specific file, channel or record in the source system, the connector cannot reach it from Claude either. On Team and Enterprise plans an Owner enables the connector for the organization, and each person still authenticates individually.
So the exposure is not the connector. The exposure is whatever your meeting tool’s sharing defaults already said, set back when the archive was too large for anyone to read and therefore protected by its own size. Those defaults are now load-bearing for the first time.
The audit for the archive you already have
Most readers are not starting clean. Five steps, in this order, and the order matters.
- Find out who can reach it. Open the sharing settings on your meeting tool and read them as though someone will now query everything they cover. Look specifically for workspace-wide visibility, recordings shared by link, and access that outlived someone’s role.
- Classify what is in there against the five artifact types. Most organizations find they have been keeping all five without ever deciding to keep any of them.
- Set the policy going forward before touching the backlog. New inflow under a rule is worth more than a cleaned-up history with no rule.
- Name an owner. Not a department. A person who is accountable for what the corpus contains and reviews it on a set cadence.
- Then decide about the backlog, with counsel if any of the exception classes apply to your sector.
Writing this down is most of the value, which is worth saying plainly because it sounds too simple. Codifying a working practice into an explicit, reviewable rule is the same move as turning skills into SOPs: the practice may already exist informally, but until it is written it cannot be delegated, audited, or argued with.
The pattern underneath
None of this is really about meetings.
Every archive your company keeps “just in case” reflects a storage decision made when reaching into it was expensive. Keeping everything was rational when retrieval cost weeks of someone’s attention, because the cost of keeping was low and the cost of looking was prohibitive.
That ratio has inverted. Retrieval is now cheap, which means the value of an archive no longer depends on its size but on whether anyone decided what belongs in it. The same arithmetic is sitting in your Slack history, your ticket system, your CRM notes and five years of email.
The organizations that will get the most out of AI memory are not the ones that captured the most. They are the ones that decided what deserved to persist, wrote it down, and gave it to someone to own.
Questions this article gets
Is deleting transcripts risky?
It would be, which is why the policy does not delete them. The distinction is between deleting a transcript and declining to copy it into a second system. The original stays in the recording tool under that tool's retention settings, and a connector can retrieve it on request. What you avoid is a duplicate copy in a system with weaker controls and no owner. If your situation requires custody of the raw record rather than access to it, that is one of the exception classes, and the default does not apply to you.
We already have two years of recordings. Where do we start?
Not with deletion. Start by finding out who can currently reach that archive, because those permissions were almost certainly set when nobody could realistically read it. Then classify what is in there by the five artifact types, decide the policy going forward, and only then decide what to do with the backlog. Most organizations discover the access question is more urgent than the storage question.
Does connecting an AI assistant to our meeting tool expose more data?
Not by itself. Anthropic's documentation is explicit that Claude inherits each person's permissions from the connected service, and that if someone cannot access a record in the source system, the connector cannot reach it either. What changes is not who has access but how usable that access becomes. An archive nobody could read was governed by its own size. Once it is queryable, it is governed by whatever the sharing settings actually say.
Who should own the retention policy?
A named person, not a function. In practice it usually sits with whoever owns the meeting stack rather than with legal or IT, because the operational decisions (which rooms exist, what enters, what persists) are made daily by that person regardless of what any policy document says. The point of writing it down is to make those decisions visible and reviewable instead of accidental.