A familiar scene. A call is underway, and ten minutes in somebody says, "Hold on, we have already discussed this." We have. Same people, a few weeks ago. We even made a decision. Nobody can recall what exactly was decided, who was supposed to do it, or why it never got done. There are no minutes. There are several people, each with their own version of that conversation.
So the call is held a second time. It arrives at the same decision, because the inputs have not changed. The project has not moved in the meantime.
This happened at GPTunneL more than once, and for a long time I treated it as a discipline problem. Then I worked out why it happens and, in a few days, built a meeting transcriber: it records the call, transcribes it and sends a summary with the decisions. After that, several partners saw it at work and asked for the same thing. Below is the breakdown: where the problem comes from, what exactly was built, where I tripped, and where to start if your team looks the same.
What people are actually tired of
The common line is that everyone is tired of calls. I think that is imprecise. An hour of talking with capable people does not wear anyone out. What wears people out is that the hour is spent and the task sits exactly where it was. Call fatigue is fatigue from low return on the time. People feel the hours going while the project stands still, and they blame the calendar.
The cause is not the people or the way they run meetings. It is in the nature of video calls. A commitment made on a call is forgotten more easily than one made in person, and there are at least five reasons.
Memory has nothing to hold on to. An in-person meeting is tied to a place, the trip there, the room, the other person's face, even what you were drinking. The brain stores an event together with its context, and those details later work as hooks for pulling the memory back. Calls all happen from the same chair in front of the same screen, and they blur into one another. A week later it is hard to tell what was agreed on Tuesday and what on Thursday.
Attention is split. On a call almost everyone is also looking at email, a messenger or the next tab. A commitment heard with half an ear is barely written to memory. In person that behaviour is rude, so attention is fuller.
A promise costs less. When you promise something while looking a person in the eye, very old mechanisms kick in: reciprocity, reputation, awkwardness in front of a specific face. Breaking a promise made in person is psychologically expensive. A promise made to a voice in your headphones or a small square on a screen weighs less. The more disembodied the other person, the weaker the sense of obligation.
A call costs nothing. People spend travel, time and preparation on an in-person meeting, and that investment raises the value of whatever was agreed there. A call slots into the gap between two others. Its outcome is perceived as "we discussed it", not "we decided it".
There is no closing ritual. In person there is a handshake, a "so, we are agreed", a walk to the door. That marks the moment when talk became a commitment. A call ends on "okay, talk soon", and it stays unclear which of the things said were decisions and which were thinking out loud.
In short, a video call is built as a conversation that is easy to hold and easy to forget. It does not create the weight that an in-person meeting provides on its own.
Everyone knows the recipe. Nobody follows it
What to do about it has been known for a long time. At the end of the call, say the outcome out loud: who does what by when. Within an hour, send a written summary and ask for confirmation. Create the tasks right away while the conversation is fresh. Of all these, the written summary works best: text gives memory the hooks it is missing and makes the promise public. A call has to be made heavier artificially, by writing it down.
Everyone knows this recipe and almost nobody follows it. The reason is simple: the next call starts in five minutes. The person who should write the summary was a participant, thinking and arguing, not taking notes. By evening they have four meetings fused into one in their head. "I will write it up later" never works.
That led to the conclusion the project started from. If a person reliably fails to do this job, it should not be done by a person.
Why off-the-shelf tools did not fit
There are plenty of services that record meetings and write notes. None of them fit us, for three reasons.
The first is platforms. Our meetings happen in Zoom, Discord, Google Meet and a few other tools, depending on who sent the invite. Ready-made services are usually good at one of them.
The second is language. We speak a working language densely mixed with English terms: deployment slang, model names, provider names. On speech like that, recognition that handles a news anchor perfectly starts dropping words, and the most important ones at that.
The third is data. Internal calls cover money, people and contract terms. I did not want to hand those recordings to an unvetted cloud.
What came out of it
I message a bot in Telegram with "record" or drop a meeting link. Everything after that happens without me.
- The recorder joins the meeting as a participant and leaves on its own when it ends. Nobody has to stop the recording by hand.
- The recording is transcribed on a Mac mini that sits in our office and is always on. An hour of meeting takes about eight minutes to process. The audio never leaves our hardware.
- Lines are attributed to speakers. When the conversation makes it clear who is who, the text carries names.
- A few minutes after the meeting ends, a summary of up to fifteen lines arrives in Telegram: what was discussed, which decisions were made, which tasks went to whom, which commitments and deadlines were set.
- The full transcript lands in our notes base and on a cloud drive. Ordinary search works across it.
- If the Mac mini stays silent for fifteen minutes for any reason, a backup model on a server transcribes the recording, so the summary arrives in that case too.
- For meetings where a bot cannot be invited, there is a command on the laptop: it captures system audio plus the microphone and sends the file down the same pipeline.
This is that written summary within the hour, except nobody writes it. It arrives while participants still remember the conversation, and it can be forwarded to the work chat straight away with "please confirm this is what we agreed".
A few days and a few surprises
I built all of this in a few days, alone, with an AI coding agent. I described in words what should come out; the agent wrote the code, ran the tests and fixed what it broke. My part was the decisions and the checks on live meetings. Almost all the interesting problems turned up where I did not expect them.
Capturing audio. The standard audio capture utility on a fresh macOS silently lost more than 80% of the sound. The file had a normal length, and recognition returned zero words. A second utility simply hung. In the end the agent wrote a small recorder of its own in Swift, and it captured the test phrase in full, thirty words out of thirty.
Choosing the model. At first recognition ran on a server, on the fastest model. Then I ran the models against each other on identical recordings, and the fast one lost exactly where it matters most to us: on a test meeting full of English terms it got 16% of the words wrong, against 6.6% for the winner. I moved recognition to the Mac mini and rebuilt half of the pipeline. A rebuild like that used to mean "let's not touch what works". This time it took a couple of days.
The glossary. A model can be given the words it is going to meet: product names, surnames, jargon. In our test that cut the error rate from 6.6% to 2.9%. The hint had a side effect: on silence the model began to "hear" the glossary and output it in a row, as if someone had read it aloud in the meeting. The pipeline had to learn to skip quiet segments and discard answers that look suspiciously like the glossary itself. The glossary is now extended with one phrase to the bot: "add to the meeting glossary".
Encryption. One of the platforms switched on mandatory end-to-end encryption for voice during those days. After that the public library heard some participants and not others, intermittently. The fix already existed in the source code but not in the published build. We built the library from source ourselves.
My own test. I cut one live recording short myself. I was checking sound settings on the same machine, switched the audio output, and the recording filled with flat zeros. A few minutes later the recorder decided the meeting was over and left. Now it restores the devices every half a minute and detects the end of a meeting by the app's network activity; silence remains only as a fallback. And there is a rule: while a recording is running, nobody touches sound on that machine, me included.
None of these problems could have been predicted at the planning stage. All of them surfaced on live meetings, and each one took hours to fix, not a sprint. A few years ago a tool like this would have been a quarter-long project for a team, and nobody would have started it, because "we will just buy something". Now it is a few days of one person who knows what they want.
What changed
I have no measurements, only a few weeks of observation.
The summary arrives before participants have had time to forget the conversation. Forward it to the work chat and the commitment becomes public: that is the closing ritual a call lacks.
The "that is not what we agreed" argument is settled by searching the transcript, and it takes a minute. It used to be settled by another call.
One such argument stuck with me. On a call the talk turned to data for partners, and one participant said someone had already mentioned that this data had been handed over. The others did not confirm it. Nobody was lying: one person remembered the phrase, the rest did not, and both sides were sure of themselves. It was not an idle question either, because the answer decides whether the data gets sent again or not. Without a recording, an argument like that is won by whoever speaks more confidently or ranks higher. The only objective arbiter turned out to be the transcriber, because it holds not just the summary but the full text of the conversation. So that is where we went: opened the transcript, found the spot, and the argument was over. A transcript has no version of events of its own, and that is its value.
Calls about questions that were already decided have, as far as I can tell, become noticeably rarer. Once a decision is written down with an owner and a deadline, it is much harder to quietly not do it.
"Can we have that too?"
I never planned to make a product out of this. It is an internal tool built around our own pain. But partners saw it at work, and several of them have already come with the same question: can they have the same thing.
For me this is the most interesting part of the story. I was solving my own problem and did not think it was anyone else's. It turned out to be common: lots of calls, commitments get lost, questions come back for a second round. It grows out of the nature of video calls, so it will not go away by itself.
What will go wrong if you repeat this
- A summary without names and dates. A retelling of "we discussed such and such" changes nothing: a week later it is as useless as the participants' memory. The summary prompt has to name decisions, tasks with owners and deadlines explicitly, or the model will write an essay.
- The summary goes to the wrong place. Nobody opens a separate portal with meeting minutes. The outcome has to land where the team already talks, within an hour of the meeting.
- Recording in secret. The recorder should be a visible participant, and the recording should be announced at the start of the conversation. A hidden recording destroys trust faster than transcripts build it, and in external negotiations it adds legal questions.
- No glossary. Without a list of surnames, product names and internal jargon, the transcript gets wrong precisely the words people will later search for.
- Testing on the production machine. Anything tested on the computer that is recording a meeting right now will sooner or later end up in the recording or cut it short. Both happened to us.
What to do on Monday
You do not need your own pipeline to start. One week of experimenting with what you already have is enough.
Record the next working call with the platform's built-in recording, after telling the participants. Upload the file to Audio & Video to Text and get the transcript. Give it to any strong model in the chat with a short brief: decisions made, tasks with owners, commitments and deadlines, no more than fifteen lines. Send the result to the work chat within the hour and ask participants to confirm.
After a week the main thing becomes visible: whether questions come back for a second round less often. If they do, the manual steps are worth automating around your own platforms, storage rules and glossary. More about the transcription tool is on its page, terms for teams are in the business section, and model prices are on the pricing page.
If the opening scene of this article looks like your team and you need a pipeline like ours, write to us through implementation consulting. We are working out how to turn the internal tool into something others can use, and we need to understand what this problem looks like on your side.