Three decisions, one survivor
The meeting settled three things. Two days later nobody remembers the second one. The first is remembered because work on it already started. The third because it was last. The second was the important one: that is where you agreed to change the schema after the release rather than now, and that is the one that will be broken next week — not out of malice, but because its only storage was somebody's memory.
What follows is familiar. Someone writes in the chat, «I thought we decided otherwise». Someone pulls up a forty-minute recording and cannot find the moment. Someone says «let us just meet again» — and a call that was needed once happens twice.
This is not a discipline problem. It is a format problem: a conversation is poor storage, and a transcript is a poor index. The whole niche of AI assistants for work meetings lives between those two facts, and the difference between a useful one and a useless one is decided right there.
What specifically gets lost for a developer
Technical meetings have their own set of losses, different from the generic «we did not write the tasks down». Here it is, by type.
| What was said | What is left two days later | What it costs |
|---|---|---|
| Technical context: why the service is built this way at all | Nothing. The context lived in the conversation and died with it | Six months later a new person «simplifies» something that was there on purpose |
| Architectural decision: we take B, not A | The choice is remembered, the reason is not | The argument repeats in full, with the same points and the same outcome |
| Bug discussion: reproduces only on a cold start | A tracker line saying «sometimes crashes» | The next developer walks the same diagnostic path from scratch |
| A TODO said out loud: «I will fix the retries» | A promise with no owner and no date | It surfaces at the demo, when fixing is too late |
| A dependency: we cannot ship until billing migrates | One person remembers — the one who said it | A Friday deploy and a Saturday rollback |
| An agreement with a neighbouring team: they add the field by Thursday | A verbal agreement with no trace | On Thursday it turns out «we never promised that» |
| A question for investigation: we should see how this behaves under load | Forgotten first: it has neither an owner nor a shape | The same question resurfaces at an architecture review a month later |
| Links and names: a dashboard, a ticket, a queue name, a library version | «Send me that link again» | Twenty minutes of chat instead of ten seconds of search |
And a ninth loss, dearer than all the others combined: context switching. A developer leaves the meeting with their working memory full of somebody else's problem and spends half an hour rebuilding their own. If they also have to turn the decisions into tickets by hand afterwards, that half hour becomes an hour.
Why a transcript is not enough
The first thing nearly every tool does is record the conversation and hand you the text. That is useful and solves exactly one problem: «prove that this was said». It solves nothing else, and here is why.
- An hour-long meeting is nine or ten thousand words. Nobody re-reads them. An unannotated transcript is an archive people open only once an argument has already started.
- Decisions do not sound like decisions. In the text they look like «all right, let us do that then», «okay, after the release», «yeah, probably». Searching for the word «decided» does not find them, because the word is not there.
- The important part is spread across the conversation. An option was proposed at minute five, rejected at twenty, revisited at forty. No single fragment contains the decision — only the meeting as a whole does.
- Recognition errs most quietly on names. Service names, queues, libraries, surnames — the text stays coherent and the substitution is invisible to the eye. But later it is unfindable: you search for the service name and the transcript holds a similar-sounding word.
- A one-paragraph summary is no better. «Discussed the architecture, agreed on next steps» helps as little in two days as the transcript does, only faster to read.
What should survive instead of «we need to change the API»
Here is a usefulness test for any AI assistant for technical meetings. Take a line that sounded like this on the call: «look, we will have to change the API anyway». Then see what the tool kept.
A useless record: «Need to change the API». Formally true and, two weeks later, informative about nothing: which API, why, who, and by when.
| What should survive | In this example |
|---|---|
| What to change | Add a status field to the /orders response |
| Why | The client polls a second endpoint for the same thing — extra requests on every order |
| Who does it | The person who said it out loud, not «the team» |
| By when | Before the release on the 12th: after that the contract is frozen |
| What it depends on | Not before the neighbouring team ships their migration |
And a sixth item, without which the first five are just an elegant retelling: evidence. A link to the minute of the conversation where it was said. The difference is fundamental: a record with a quote can be verified, a record without one is indistinguishable from something the model invented. In technical meetings that decides everything — «we agreed» without a pointer to the line quickly becomes an argument about who remembers what.
No quote, no fact. Everything the assistant claims about your meeting must open in one click down to the specific line. A tool that produces a beautiful list of decisions with no links into the conversation saves you five minutes today and costs you a week of trust the day after tomorrow, when one of those «decisions» turns out to be invented.
meeting → context → decision → task
A useful assistant is not «a dictaphone with AI» but a pipeline of four transitions. They are worth distinguishing, because usually exactly one of them is broken.
MEETING ──▶ CONTEXT ──▶ DECISION ──▶ TASK
│ │ │ │
the talk what it what follows what to do
as it was means and from it now, and who
what about is on the hook
│ │ │ │
transcript topics, decisions, a diff: create
with time- speakers, promises, a task, move a
codes subject, risks, date, file a
terms questions document
│ │
each one carries a quote and is
PROPOSED to a human, not applied silently
meeting → context. Speech becomes text split by speaker with a timestamp on every line. This is also where the fork about proper names sits: either the tool is allowed to edit the text or it is not. Allowing it is dangerous — the model starts «improving» the wording, and an invented correction is worse than a misheard word.
context → decision. The hardest transition, and the one people cut corners on. Annotating a fragment is cheap: a risk, a question, a proposal and a promise are audible across a few consecutive lines. But a decision cannot be established from a fragment at all: the window contains «let us take B», and B was dropped twenty lines later. So decisions and final commitments require a pass over the whole meeting — otherwise the system will confidently report decisions nobody made.
decision → task. The last transition is the one where the assistant touches your working systems, and therefore it must be a proposal rather than an action. The correct form is a diff: «before — after», a link to the quote and a «dismiss» button next to «apply». A task is born from a promise or an assignment; a decision does not become a task — «we chose option A» is knowledge, not work, and turning it into a ticket means inventing chores for the team.
A scenario: an ordinary technical call
Fifty minutes, four people. They are discussing why the queue chokes at peaks.
- At minute seven somebody names the cause: retries without exponential backoff, so every failure multiplies itself.
- At fifteen they propose option A — more partitions. At twenty-two they reject it: it breaks message ordering.
- At twenty-eight they adopt option B — a dead letter queue plus growing backoff. That is the decision, and it cannot be established from any single chunk of the conversation.
- At thirty-five a risk appears: if the dead letter queue fills up, nobody reads the alert.
- At forty — a question for investigation: how the consumer behaves if the backoff grows to a minute.
- At forty-five — a promise: «I will put up a dashboard by Thursday».
- And a dependency at the end: ship only after the billing migration.
What should survive such a meeting: one decision with its cause and the rejected alternative (that matters more than the decision itself — otherwise option A returns in a month), one risk, one open question with its wording, one task with an owner and a date, one dependency and a link to the dashboard. Seven lines instead of nine thousand words — and every one of them addressed to the minute where it was said.
What actually survives without a tool: a chat message saying «we decided to do a DLQ», and none of the rest.
What the AI does and what the team still does
The boundary matters more than the feature list, because it decides whether the tool is useful or becomes a generator of tracker garbage.
| The AI does | The team does |
|---|---|
| Listens and remembers verbatim | Makes the decisions |
| Annotates: what is a decision, a risk, a question | Chooses what actually matters |
| Keeps evidence for every claim | Checks the evidence when the cost of error is high |
| Proposes changes in the tracker and calendar | Applies or dismisses them |
| Finds where this topic was discussed before | Understands why it was decided differently then |
And separately: an AI meeting assistant does not write code and should not. That is a different class of tool, with a different place in the working day and different quality metrics. Nobody writes code in a meeting — in a meeting people agree on why it will be written.
How this works in Whisperer
Whisperer listens to a work call without a bot participant: the audio comes from your computer, so the platform is irrelevant — Zoom, Meet, Teams, anything. Then the part it was all built for begins.
- A transcript with timecodes, split by speaker. People's names go through the meeting dictionary — assembled from participants, speaker labels a human has corrected, and the account owner's name: only a known name can be substituted, and only if what was heard resembles it. Edits «to taste» are forbidden: the model does not rewrite the text at all, so a misheard word stays visibly misheard instead of turning into a plausible invention.
- Two passes of understanding instead of one. A cheap pass over windows of the conversation extracts what a fragment can carry: claims, proposals, questions, risks, problems, ideas, assignments and participants' positions. A pass over the whole meeting extracts what a fragment cannot establish: topics, decisions, standing promises and agreements to meet again.
- Not a single object without evidence. A claim with no link to a line is not stored at all; weak extractions are dropped by a confidence threshold; duplicates collapse, and every kind of object has a ceiling — a hundred «decisions» from an hour-long meeting is worse than an empty list, because it looks rich and gets believed.
- A «what this meeting changes» screen. Proposals arrive as diffs: the previous state and the future one, a quote beside them and a «dismiss» button. There is deliberately no «apply all». Calendar events, deletions and task closures are never applied automatically under any settings: they touch people outside your account or destroy things the system did not create.
- Coming back to the context later. Search across meetings and lines, «who held which position», «what was decided on this topic», tracing one topic across the whole archive — with quotes as evidence for any of those answers. The same is available to an external assistant such as Claude Desktop or Cursor over MCP, if the archive is more convenient from there.
- Memory between meetings. Facts from a meeting are projected into a context available in later conversations — why that is a separate problem, and how it differs from the size of a model's context window, is covered in why AI forgets.
Plainly about the limits: meeting analysis and search across meetings are paid capabilities; the free plan gives 60 minutes of recognition per month and the transcript. Understanding is the most expensive stage of the pipeline — for an hour-long meeting that is tens of thousands of tokens per window — and pretending otherwise would be unfair to the people who pay. There is also a mode in which nothing is stored at all: no transcript, no analysis — for conversations that should leave no trace.
And what Whisperer does not do: it does not write your code, does not make architectural decisions and does not replace a written ADR where one is needed. It brings the conversation to a state where writing that document takes five minutes rather than an hour and a half of scrubbing through a recording.
The wider picture of this class of tools is in the pillar piece: AI meeting assistant: what it is, how it works and why you need one.
Frequently asked questions
How does an AI meeting assistant differ from plain transcription?
Transcription answers «what was said». An assistant has to answer «what follows from it»: which decision was made and why, what became a promise, which question stayed open and what now changes in the tracker. The transcript does not go anywhere — it remains the evidence base.
Do I have to let a bot into a work call?
Not if the tool takes audio from your computer. Then no extra participant appears in the list and no platform approval is needed. You still have to tell colleagues you are recording — that is a matter of respect and often of law, not of technology.
How does AI tell a decision from a proposal?
By scope. A proposal, a risk or a question is audible across a few consecutive lines, while a decision can be established only from the conversation as a whole: an option may be adopted mid-meeting and rejected by the end. So decisions are extracted in a separate pass over the entire transcript, and «decisions» found inside a fragment are discarded.
Are tasks created automatically?
By default no: changes arrive as proposals with the previous and future state and a quote from the conversation, and a human applies them. Automatic application can be allowed only for creating your own tracker tasks; calendar events, deletions and task closures stay manual under any settings.
Does it cope with technical jargon?
Yes, but do not expect flawless recognition of jargon: the meeting dictionary corrects people's names, not library names. What helps is different — the model is forbidden to rewrite the transcript, so a misheard term stays a visible distortion rather than becoming a smooth invention, and there is always a timestamped quote next to it showing how it actually sounded.
Can I work with the meeting archive from my IDE?
Yes, over MCP: an external assistant such as Claude Desktop or Cursor gets access to search across meetings, decisions and quotes. That is convenient when the context is needed where you write code rather than in a separate tab.
What next
There is a simple test for whether such a tool is worth your time. Take your last technical meeting and try to answer three questions: which decision was made, why the alternative was rejected, and who promised what. If answering requires digging through chats or asking people, you are already paying for the absence of such a tool — you are just paying in your team's time.
A good AI assistant for developers does not write code instead of the team. It helps the team remember why that code is being written at all.
The easiest way to check is on your own call: create an account — 60 minutes a month are free — and run your next technical meeting with it. Then open the analysis and look at one thing: whether the list of decisions matches what you remember, and whether each of them opens down to the line where it was said. If it does, your team has acquired a memory that no longer depends on who was in the room.