A meeting recap is not a follow-up

It saves writing time, which was never the problem. The write-up of an interview or a client call takes ten minutes to produce and three to read; what costs you is the follow-up that should have gone out the next day and goes out the following Thursday, when somebody reopens their notes. The notetaker stops exactly where the value starts.

That boundary is not a nuance of vocabulary, it is a governance boundary. The recap stays inside the company and commits nobody; the follow-up message goes out to a client, a candidate or a partner and commits whoever signs it. A tool that treats both as a single feature makes a human approval vanish inside a chain of steps, and nobody notices until something has gone wrong.

Who actually uses a meeting notetaker?

Almost everybody, except large enterprises, and that inversion is the most interesting fact on the subject.

The 2026 measurements put 75% of professionals on an AI notetaker, with a curve that falls as size rises: 78 to 81% among solo professionals and small teams, 61% in companies of one to five thousand people, and only 43% above five thousand. Most technology adoption does the opposite, since large organisations have the budgets and the teams to deploy.

The explanation is not price, it is the purpose of the tool itself. Recording a meeting creates processing of personal data about people who are not all employees, often on subjects nobody intended to keep. You need a legal basis, a retention period, a declared subprocessor, notice to participants. A solo professional switching the feature on has none of that to produce; a company of ten thousand has six months of work. On that point, 73% of businesses cite privacy as the number one barrier, and half of those who have not adopted the tool name security as the main reason.

That gap has a predictable and documented consequence: the tool comes in anyway, through individual accounts, and gets formalised about eighteen months later. That is the definition of clandestine use, which mostly proves no tool had been provided.

What does a bot in the room change?

It changes what gets said, which is the one thing the recap cannot make up for.

84% of participants report changing their behaviour or withholding information when they spot a bot in the call. In a recruitment interview, that means a candidate will not tell you why they really left their last job. In a client review, it means the real reason a decision slipped will stay out of the transcript, and it will be precisely the information missing three weeks later.

The paradox deserves stating plainly, because no setting resolves it. A tool that improves the fidelity of the record degrades the candour of the conversation, and both effects land on the same material. We know of no way to win on both counts; we know of ways to choose deliberately, the first being to accept that some meetings are not recorded.

Legally, the position is clearer than people assume. No jurisdiction treats a bot’s visible presence in the participant list as sufficient notice or consent, and the 2026 litigation around transcription tools is less about AI than about consent design. The practical conclusion is the one we argue for any interaction with an outside party: tell the person what they are dealing with, beforehand, and say it in the invitation rather than at the start of the call.

Where does the recap stop and the work begin?

The recap stops the moment somebody has to decide what to do with it, and that moment is what costs weeks in a placement.

We have shown elsewhere that hiring delay is played out in the waiting, not in the tasks: the useful work is counted in hours, the delay in weeks, and what separates a fast placement from a slow one is picking things back up after a wait. A meeting is precisely the start of a wait. The interview went well, the client owes you an answer, the candidate needs to think, and three nudges should have gone out on three different dates.

A recap, however good, does none of that. It produces a document and files it. Vendors report action-item completion rates of 85 to 95%, against 50 to 60% without a tool, and that figure is measured by the people selling the tool, on action items they listed themselves. It says what it says: the list is better kept. It does not say the follow-up went out.

This is the mechanism we describe about work that looks finished: the gain is measured on the producer and gets declared, the load scatters across the people who pick it up and never does. A set of minutes sent to five people moves writing work into five verification reads, and that transfer is called a gain in nearly every deck I have seen on the subject.

What we connected, and what we did not

Balt reads the calendar, joins the meeting, gets the transcript, and the arrival of that transcript triggers tasks that make something of it: a write-up, a preparation note, whatever the person asked to be tracked. All of that stays inside, in the conversation where the work happens. What Balt does not do is send the follow-up.

The reason lies in the nature of the two operations, not in the development calendar. Reading a transcript and drawing a text out of it for you commits nobody. Sending that text to a client is an outbound action, so it goes through somebody who releases it, without exception and however routine the message. Between the two sits a substantive decision that has nothing to do with the model: what do you do when the meeting went badly, when the client said something they should not have, when the obvious follow-up is the wrong follow-up.

The consequence shows up in the product rather than in an instruction. The transcript and the sending are two different permissions, granted separately, and what happens next is a recurring task you can stop. That is slower to build than a checkbox saying “send a summary automatically”, and it is the only shape that respects the rule we apply everywhere: nothing outbound leaves without a person releasing it.

What to check before deploying a notetaker

Four questions, in this order, and none of them is about transcription quality.

Who is told, and when? If the answer is “the bot appears in the participants”, you do not have notice in the regulatory sense, you have an icon. Where does the recording go, how long does it stay, and who else can reach it? The subprocessor gets declared, the retention gets decided, and both get written down before the first call rather than at the first audit.

What happens after the recap? That is the question separating a meeting tool from a work tool, and the only one whose answer changes your delay. And finally: who signs what goes out? As long as that last answer is a named person, the rest is negotiable.

That leaves the meetings you do not record, which are often the most important ones, and where what was said goes back to living in somebody’s memory. That is exactly the dependency we are trying to remove, and it is worth looking at what an agent should keep and, above all, forget.