DEV Community: Zurab Shakhbanov

Your AI Meeting Assistant Is Taking Notes. Who Is Doing the Work?

Zurab Shakhbanov — Tue, 22 Sep 2026 20:57:04 +0000

The real value of meeting AI isn't the transcript. It's what happens after everyone leaves the call.

TL;DR

Transcripts and summaries now ship inside Meet, Teams and Zoom. They're table stakes.

The value of meeting AI is moving to what happens after the call: decisions, owned tasks, and context that survives from one meeting to the next.

The hard engineering problem is trust: silent failures, invented tasks, fuzzy dates and permissions. Below is a real extraction bug we hit and how we fixed it.

The call ends at 3:47.

Before you've closed the tab, the artifacts arrive. A full transcript, labeled by speaker and stamped to the second. A summary with clean headings. Five action items in bold. A link to the recording. If your tool is on the newer side, maybe a mind map.

It's genuinely impressive. Not long ago, this took a human note-taker and most of an afternoon.

Then Thursday comes.

Someone asks whether the revised proposal went to the client. Nobody is sure. The action item exists, in a document nobody reopened. The person it was assigned to remembers the conversation differently. The deadline was said out loud but never became a calendar entry. The customer complaint that surfaced in minute 31 never reached the CRM, and the "quick follow-up next week" was never scheduled.

The meeting was captured perfectly. Then it was left behind.

This is the quiet paradox of today's AI meeting assistants. They have become remarkably good at describing a conversation at exactly the point where describing stopped being the problem. The notes are done. The work isn't.

The meeting notes arms race

The market got here in recognizable phases, each solving the previous one's problem.

Phase 1: Recording. "Let's record the meeting." Useful for people who missed it, rarely rewatched. An hour of video is still an hour of video.

Phase 2: Transcription. "Let's turn speech into text." Suddenly a conversation was searchable.

Phase 3: Summarization. "Let's ask AI what happened." Language models compressed a 5,000-word transcript into a page people actually read.

Phase 4: Meeting intelligence. "Let's identify decisions, topics, risks and action items." Instead of a paragraph, you get structure: what was decided, who owns what, what's still open.

Phase 5: Agentic work. "Now let AI actually help carry out what was decided."

The first four phases produce documents. The fifth produces outcomes.

The first four phases now ship inside the tools most people already use. Google Meet's "Take notes for me" puts a summary, action items and a full transcript into a Google Doc, and since June 2026 it has been available to consumer Google AI Pro and Ultra subscribers, not just business accounts. Microsoft's Facilitator agent in Teams "summarizes key decisions and open questions." Notion added AI Meeting Notes to its workspace in 2025.

The vendors are already saying phase five out loud. Zoom described its December 2025 launch of AI Companion 3.0 as part of "our transformation from a meeting company into a pioneer of AI-first intelligent work orchestration." Otter launched a meeting agent that, in Otter's words, can answer questions from an organization's entire meeting history, "schedule follow-ups, and draft emails." Granola framed its $125 million raise in March 2026 around context, calling transcripts "the richest source of context for what's happening across your company."

Nobody is disputing the direction. The open question is what it takes to get there.

Why aren't the first four phases enough? Because every one of them ends in a document. And a document, however well structured, is a passive object. It waits to be read. It has no idea whether the thing it describes ever happened.

Why transcription became a commodity

It's worth being careful here, because "commodity" is easy to hear as "unimportant." It isn't.

Accurate transcription is hard engineering. Crosstalk, accents, domain vocabulary, bad microphones and people switching languages mid-sentence all break naive systems. Knowing who said something matters, because "we'll ship it Friday" means one thing from the engineering lead and another from a salesperson. Timestamps matter because they let you go back to the source instead of trusting a paraphrase. Multilingual support matters because more and more teams don't share a first language.

All of that is real. But a capability becomes a commodity when it's everywhere and bundled, not when it becomes easy. When the platform you already hold your meetings on writes the notes for you, a transcript stops being a reason to choose a product. It's table stakes.

And even a perfect transcript isn't a result. It's raw material.

Two distinctions are worth holding on to:

Information is not action. Knowing that a decision was made doesn't make it happen.

Capturing a conversation is not the same as managing the work that conversation created.

A meeting is, among other things, a machine for producing obligations. People promise things, set dates, raise problems and push questions to later. The transcript records those obligations being created. It does nothing to see them through.

The real problem starts after the meeting

Take an ordinary product meeting. In forty minutes:

the team agrees to move a launch by two weeks;
an engineer says she'll look into a performance issue;
someone says the pricing page "needs updating before then";
a customer problem comes up that sales hadn't heard about;
a design doc is referenced, but nobody links it;
"let's sync with legal next week" is said, and everyone nods.

Now follow those six things out of the room.

The new launch date lives in someone's head until it surfaces in a Slack thread. The performance investigation becomes a ticket, if the engineer remembers. The pricing page has no owner, because "someone" said it. The customer problem goes into an email to the account manager, or doesn't. The legal sync waits for one person to find a free slot across three calendars.

One conversation, six destinations, no shared thread.

This is fragmentation, and it isn't a failure of discipline. It's structural. The meeting produced one connected piece of understanding (these six things are related, they belong to the same launch, some depend on others) and the tools downstream can only accept it in disconnected pieces.

The research suggests this is a common complaint, not a niche one. In Microsoft's 2023 Work Trend Index survey, 55% of people said next steps after meetings were unclear. A Harvard Business Review study of 137 workers at three Fortune 500 companies found them switching between applications about 1,200 times a day, which added up to just under four hours a week spent getting reoriented. Microsoft's 2025 data found employees interrupted every two minutes during core work hours. Meetings create the work, and then the work is scattered across the same tools that keep interrupting people.

Which brings us to the question at the center of this essay:

If the AI understood the meeting, why should that understanding disappear when the meeting ends?

In most setups today, it does. The assistant builds a rich model of the conversation (who, what, when, why), flattens it into text and hands it over. Everything it understood about how those items relate to each other is lost at the export step.

From notes to decisions

The first thing that has to change is what gets extracted.

A summary answers "what was discussed?" That's the wrong question for work. The useful questions are narrower:

Decisions: what was actually agreed, as opposed to floated?
Open questions: what came up and wasn't resolved?
Commitments: who promised what, and to whom?
Owners: who is responsible, and did they accept it?
Deadlines: what dates were stated or implied?
Dependencies: what has to happen before something else can?
Risks: what could derail it?
Follow-ups: what future conversations were promised?

Here's the difference in practice.

A summary says:

Maya suggested moving the feature launch to next month. The team discussed marketing readiness.

An actionable reading says:

Decision (tentative): launch moves to next month. Proposed by Maya, no objections, not formally confirmed.

Owner: Maya, for implementation.

Dependency: marketing needs launch materials. No owner yet.

Open question: does the pricing change ship with it?

Follow-up: a review before launch was mentioned. Not scheduled.

The second version is longer and less pleasant to read. It's also the one you can act on. It separates suggested from decided, flags work nobody owns, and notices that a meeting was implied but never booked.

That first distinction, suggestion versus decision, is harder than it looks, and it's where a lot of meeting AI quietly goes wrong. Real conversations are full of hedges: "we could," "probably," "let's aim for." A system that turns every "we could" into a decision produces confident, well-formatted fiction. A system that preserves uncertainty produces something you can trust.

From decisions to actions

Once decisions and commitments have structure, a new possibility opens up. The assistant can help move them through a lifecycle:

Most meeting tools stop at the first arrow.

Most tools stop at the first arrow. The interesting work is in the other three.

Take a sentence said in thousands of meetings every day:

"Let's review the proposal on Thursday."

A summary might list "Review proposal Thursday" as an action item. An assistant that actually understands it notices several things at once:

it's a follow-up, a future meeting rather than a finished task;
Thursday is a constraint that needs resolving: which Thursday, in whose time zone;
a specific document is involved, and it lives somewhere;
the people on this call are presumably the reviewers;
a reminder beforehand would help;
all of it belongs to a particular project or client.

From that understanding, a useful assistant can propose a calendar event on Thursday with these participants and the proposal attached, filed under the client it's about.

Note the word propose.

AI should not blindly execute everything a meeting implies. People say "let's review Thursday" and then cancel. Owners decline. The next meeting changes the plan. An assistant that automatically creates every task and books every event doesn't reduce work. It creates a new kind of cleanup. Even the largest platforms design for this: Google's "suggested next steps" in Meet are something you "review and edit … and even assign", not a list that executes itself.

The right design is the one good executive assistants have always used: prepare everything, then ask. The AI extracts, resolves and drafts. The human spends a second confirming. Permissions, context and judgment stay with the person whose name is on the work.

Context is more valuable than another summary

Now zoom out beyond a single call.

On Monday, the product team discusses a launch. On Thursday, the same launch comes up in a customer call, where the customer mentions a blocker. The following week, marketing meets about the launch without the product lead in the room.

A conventional meeting assistant gives you three summaries. Each one is accurate. Together they're nearly useless, because the valuable information isn't in any one of them. It's in the differences:

The launch date moved on Monday. On Thursday, the customer raised a blocker that affects it. Marketing is still planning against the original date.

No single meeting can produce that sentence. It takes persistent context: memory that outlives the individual call and connects it to everything around it.

Persistent context, in plain terms, means the system remembers how things relate: which meetings are about the same thing, which people own what (and who hasn't been told), which project a conversation belongs to, which commitments became tasks, what's on the calendar and what was promised but never booked, which documents are involved, and which earlier decisions are being quietly reversed.

This is where the real intelligence lives. Not "what was said in this meeting," but "what changed, and what does that mean for the work already in motion?"

The rise of the AI workspace

All of this points to a different shape of product.

For most of the last decade, each kind of work lived in its own tool. The meeting tool produced transcripts. The calendar held events, the task manager held tasks, the knowledge base held documents, and the AI chatbot produced answers.

Each tool is good at its job. None knows what the others know. The human is the integration layer, copying, pasting and remembering.

An AI workspace is a system where conversations, knowledge, tasks, calendar and an AI agent share one context, so what's understood in one place is available in all the others.

From tools that each know one thing to one context the agent can reason across.

The difference isn't the number of features. Plenty of suites have plenty of features. The difference is whether the AI can reason across them: whether a commitment from a meeting can become a task, whether that task knows which project it belongs to, and whether the agent answering your question on Friday knows what was decided on Monday.

Open standards make this more practical. Anthropic introduced the Model Context Protocol (MCP) in November 2024 as "an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools." In practice, it's a common plug that lets an AI agent reach tools and data without a custom connector for each one. MCP doesn't create shared context on its own. Someone still has to decide what's worth remembering and how it connects. But it lowers the cost of letting an agent reach the places where work actually happens.

The AI workspace isn't one company's idea or a finished category. Large platforms are approaching it from the suite side, smaller tools from the meeting side. Both have concluded that a smart transcript is not a destination.

Six questions to ask of any meeting AI

If the goal is continuity between conversations and work, here's the stack, with a question to ask of any tool, including the one you use now.

1. Capture

Does it hear the conversation accurately: who spoke, when, and in what language?
Everything downstream inherits the errors made here.

2. Understand

Can it tell a decision from a suggestion, and a commitment from a comment?
This is where summaries become structure, and where overconfident extraction does the most damage.

3. Connect

Does it know which project, client or earlier conversation this meeting belongs to?
A decision without context is just a sentence.

4. Act

Can it turn a commitment into a task, a reminder or a calendar event, with your confirmation?
Acting without confirmation is a liability. Confirmation without the ability to act is a to-do list you still have to type.

5. Remember

Next month, will it still know what was agreed today, and notice if that changes?
Memory is what turns a series of meetings into a history.

6. Assist

Before your next conversation, can it tell you what's open, what's due and what's changed?
The loop closes when the output of one meeting becomes the preparation for the next.

Most tools on the market are strong at the first two. The competition that matters now is over the last four.

Where Whisperer fits

Whisperer was built around a simple observation: work doesn't happen inside isolated applications. It happens across them, and a lot of it starts in a conversation. So instead of building a better notetaker, we set out to build the workspace the notes flow into.

Capture, without a bot in the room. The desktop apps for macOS and Windows record the microphone and system audio on your own machine, so they work with Zoom, Google Meet, Teams and other call apps without a bot joining. The transcript is live and timestamped. You can screenshot a slide or an error message and have the AI read it, and real-time translation helps when the meeting isn't in everyone's first language.

Understanding that shows its sources. After the call, Whisperer extracts decisions, commitments, risks and open questions, and each decision and commitment keeps its source: which meeting, which moment, who said it.

A transcript becomes more useful when it can become a task. A commitment can go onto a kanban board with a due date, and two-way sync with Google, Microsoft and CalDAV calendars turns a follow-up into an actual event.

A task becomes more useful when it belongs to a project. Work is organized into hubs, such as a client, a project or a hiring round. Meetings are routed to them by signals like the calendar series and participants, and when the match is unclear, Whisperer asks instead of guessing. A hub shows what's slipping: obligations coming due, open decisions, work nobody owns.

A project becomes more useful when its context survives across meetings. Leo, Whisperer's AI agent, can trace a topic across meetings, find past decisions and search the knowledge base, and it keeps a long-term memory you can review and edit.

And an AI assistant becomes more useful when it can reason across all of them. Leo drafts the task, the event or the reminder, and you confirm it before anything changes. An MCP server lets Claude, ChatGPT or Cursor work with the same context, under permissions you approve.

None of this makes the hard problems go away. Which brings us to them.

The hard part isn't building another AI notetaker

It's worth being honest about where the difficulty is, because it's not where most product demos suggest.

Connecting a speech-to-text model to a large language model and printing a summary is, by now, a weekend project. The problems that separate a demo from something people rely on are less photogenic:

Hallucinated tasks. A model that invents an action item nobody agreed to is worse than no model, because now someone has to notice it and delete it. False positives erode trust faster than misses do.
Identity and ownership. Is "I'll take a look" a commitment? Whose, if three people were talking over each other? Assigning an owner depends on knowing who's who, and names in transcripts are messy.
Temporal reasoning. "Next Thursday," said on a Wednesday. "End of quarter," at a company whose fiscal year doesn't match the calendar. "After the launch," when the launch has moved twice. Dates in speech are relative, ambiguous and often revised.
Cross-meeting memory. Remembering is easy. Remembering the right things, noticing when a later meeting overrides an earlier decision, and letting stale facts fade is hard.
Permissions. Not everyone in a workspace should see every meeting. An agent that reasons across your conversations has to respect the boundaries implied by who was invited.
Reliable actions. Every write is a place where the system can be wrong in public. The confirmation step has to be fast enough that people use it and clear enough that they actually read it.
Privacy. Meetings hold some of the most sensitive information a company produces. Users deserve plain answers about what's stored, for how long, and who processes it, including when the answer is "an external model provider."
Integrations. Context is only as good as its reach, and every connection to another tool is a new place for things to fail and a new permission to manage.

The failure that looks like a quiet meeting

Here's one we learned the hard way.

Whisperer reads a long transcript in chunks and asks a language model to pull decisions, commitments and risks out of each one. Every so often, the model provider answered with a perfectly normal success response and an empty body. Our pipeline parsed nothing, recorded that the chunk contained nothing, and reported success.

From the outside, "nobody decided anything in that stretch of the meeting" and "the extraction silently broke" looked exactly the same.

We caught it by replaying real recorded meetings through the extractor and comparing runs. The empty answers turned out to be random: two runs of the same meeting lost different chunks. That meant a single retry would fix most of the damage, and it did. On three of our own meetings, the number of extracted items went from 20 to 45 once each empty answer got one retry. In one meeting of 149 speaker turns, it went from 4 to 22. Now a chunk that still comes back empty is counted and reported, not passed off as silence.

A related bug had our agent answering "no decisions in that period" against a full archive, because the decisions were stored without the date the search filtered on. Nothing crashed, and every answer sounded confident.

The lesson carries beyond our product. For an assistant that acts on meetings, the most dangerous error isn't a wrong answer. It's a missing answer that looks like a real one. "Nothing was decided" is a claim too, and the system has to earn it.

What ties these together is trust. An assistant that summarizes can afford to be roughly right. An assistant that acts has to be right, or visibly unsure, every time. That's a different engineering discipline, and it's where the next generation of these products will be won or lost.

What AI meeting assistants may become

It's tempting to make big predictions here. It's more useful to describe a direction.

Meeting assistants appear to be moving from passive recorders toward AI work companions. The difference is easy to state.

Passive:

Here is what happened.

Active:

Here is what happened, what changed since last time, what matters, what you committed to, and what needs your attention next.

The passive assistant looks backward at one conversation. The active one looks forward across all of them: it brings the three open items from the last meeting to the next one, and it reminds you of a promise before it's late, not after.

None of this requires the AI to take over. The best version is closer to a chief of staff than an autopilot: it prepares, connects and reminds, and people decide.

The meeting is only one moment

For a few years, the story of meeting AI was about capture: record everything, transcribe everything, summarize everything. That story has mostly been told. The notes are good now.

The future of meeting intelligence isn't better notes. It's better continuity between conversations and work, so that what gets decided in a room doesn't have to be carried out of it by hand.

The meeting is only one moment.

The real value begins after it ends.

Whisperer is an AI workspace where conversations, context and work are connected: whisperer.one.

Sources & Further Reading

"Gemini can now take notes in Google Meet for Google AI Pro and Ultra subscribers", Google (The Keyword), June 29, 2026. https://blog.google/products-and-platforms/products/workspace/take-notes-for-me/
"'Take notes for me' in Google Meet now captures next steps", Google Workspace Updates, February 18, 2025. https://workspaceupdates.googleblog.com/2025/02/google-meet-take-notes-for-me-next-steps.html
"Facilitator in Microsoft Teams meetings", Microsoft Support (product documentation). https://support.microsoft.com/en-us/teams/copilot/facilitator-in-microsoft-teams-meetings
"Zoom launches AI Companion 3.0 with agentic workflows, transforming conversations into action", Zoom Newsroom, December 15, 2025. https://news.zoom.com/zoom-launches-ai-companion-3-0/
"Otter.ai Breaks $100M ARR Barrier and Transforms Business Meetings Launching Industry-First AI Meeting Agent Suite", Otter.ai, March 25, 2025. https://otter.ai/blog/otter-ai-breaks-100m-arr-barrier-and-transforms-business-meetings-launching-industry-first-ai-meeting-agent-suite
"Granola raises $125M to put your company's context to work", Granola, March 25, 2026. https://www.granola.ai/blog/series-c
"Will AI Fix Work?" (Work Trend Index 2023), Microsoft WorkLab, May 2023. https://www.microsoft.com/en-us/worklab/work-trend-index/will-ai-fix-work
"Breaking down the infinite workday" (Work Trend Index special report), Microsoft WorkLab, June 17, 2025. https://www.microsoft.com/en-us/worklab/work-trend-index/breaking-down-infinite-workday
"How Much Time and Energy Do We Waste Toggling Between Applications?", Rohan Narayana Murty, Sandeep Dadlani and Rajath B. Das, Harvard Business Review, August 29, 2022. https://hbr.org/2022/08/how-much-time-and-energy-do-we-waste-toggling-between-applications

10. "Introducing the Model Context Protocol", Anthropic, November 25, 2024. https://www.anthropic.com/news/model-context-protocol

One and a Half Hours on a Call — Four Lines in My Notebook. That’s How Whisperer Started

Zurab Shakhbanov — Sat, 05 Sep 2026 14:18:58 +0000

On Monday, we spent two hours discussing architecture. On Thursday, someone asked in the chat:

“Wait, didn’t we decide not to move this into a separate service?”

And honestly, I didn’t remember.

I remembered the feeling. I remembered that the argument had been convincing. I remembered who disagreed.

But the decision itself — the one thing five people had gathered for and burned ten person-hours on — was gone.

In my notebook, there were four lines. Two of them were:

“!!”

and

“Ask Dima.”

We all love meetings. Especially the ones that could have been a Slack message.

But that’s not even the real problem.

The problem is that conversation is probably the most expensive way humanity has invented to transfer information — and at the same time, one of the worst ways to preserve it.

The Observation That Started It All

Pretty much everyone can record meetings these days. Transcription is nothing new either. The “AI meeting notes” market is so crowded it’s getting embarrassing.

But I realized pretty quickly that transcription itself is useless.

A two-hour meeting transcript can easily be 18,000 words that nobody will ever read.

You’ve simply replaced:

“I don’t remember what we decided.”

with:

“I don’t remember where exactly in these 18,000 words we decided it.”

Not exactly progress.

The value isn’t in the text.

The value is being able to ask, two weeks later:

“What did we decide about billing?”

—and get an answer instead of opening Ctrl+F.

That thought became the starting point for Whisperer.

Not a “transcription service,” but an attempt to give conversations a memory.

A Conversation With a Memory

A meeting ends, and what remains isn’t just a file.

It becomes an object you can actually work with.

Who was there. What they discussed. What they decided. What someone promised to do. And exactly where in the recording it was said.

The surprising part was that the most important thing wasn’t the summary.

It was being able to jump back to the exact second.

Because summaries almost inevitably smooth out details. They smooth out the moment when someone hesitated — and that’s often where the real meaning is.

And speaking of “it lies just a little”…

I have a tool that connects the same topic across multiple meetings: showing how a decision evolved from “let’s try it” to “we shipped it.”

The first version honestly found zero decisions for basically any query.

It turned out the meeting topic wasn’t in the subject field at all. It lived in the parent message and in the meeting graph.

The tool didn’t crash.

It quietly returned nothing and pretended that was perfectly normal.

And if there’s one thing I’ve learned, it’s this:

The worst kind of bug in an AI product isn’t a crash. It’s plausible silence.

“Wait, Let Me Translate That”

The second use case grew out of a problem I kept seeing.

A meeting where half the participants speak Russian and the other half don’t.

Classic scenario: one person gets appointed as the translator, the conversation slows down to 30% of its normal speed, and three minutes later everyone has forgotten what they were talking about.

It gets especially fun when the translator also happens to be the only person who understands the subject matter.

That’s why Whisperer’s real-time translator isn’t about:

“Translate this recording for me later.”

It’s for live conversations.

Someone speaks, and almost immediately you hear the translation.

Emphasis on almost.

This is where engineering begins, because latency isn’t just a metric on a dashboard.

It determines whether people are having a conversation or suffering through one.

In one of my translation pipeline audits, there was a line that read:

“0.9s hangover — paid silence.”

We were keeping the microphone open for almost a second after the end of a phrase, “just in case.”

One second on every sentence.

In a live conversation, that’s the difference between talking to another human and establishing a connection with Mars.

Another honest one: one of the speech recognition engines, when running in multilingual mode, silently transliterated the output.

It didn’t crash.

It didn’t return an empty result.

It confidently produced Latin characters instead of Japanese.

Every test that simply checks “did we get an answer?” happily passes something like that.

AI Should Be Where You Already Work

This is my favorite use case, because it’s personal.

A technical meeting.

Someone shows you a query that is “mysteriously slow.” Or asks what’s going to happen during a production migration.

And then the ritual begins:

Listen.
Remember.
Open a new tab.
Copy the context.
Explain to the AI who all these people are and what is actually happening.
Get an answer.
Go back to the meeting, where everyone is already discussing something completely different.

The problem isn’t that the model is bad.

The model is great.

The problem is that the human is doing all the context loading.

They manually move meaning from one window to another because those windows have no idea the other one exists.

AI should help you where you already are, not make you jump between ten tabs with a clipboard in your teeth.

That’s why Whisperer has desktop clients — native Swift on macOS and WPF on Windows — that live on top of your meeting and understand its context.

The assistant can see what the conversation is about and help in real time.

There’s another problem, though:

Teaching it when to shut up.

The first version of the “when should I intervene?” rule was a list of about fifty Russian and English words hardcoded into two clients.

In other words, it worked for exactly two out of the sixteen languages supported by the platform.

A Japanese user got a perfectly silent assistant and could reasonably conclude that the feature simply didn’t exist.

Now it’s a single server-side, language-independent rule, tested without a network connection.

And it lives directly in the socket’s memory rather than Redis, because a trip to Redis costs about 41 ms — and this is the most frequently executed path in the entire pipeline.

Students Trying to Do Four Things at Once

There’s another audience I didn’t think about at first.

A lecture lasts an hour and a half.

During that time, a student is trying to do four things simultaneously:

listen to the professor, take notes, understand the material, and stay awake.

Anyone who has ever been a student knows that you can realistically manage maybe two out of four.

And “understand the material” rarely makes the cut.

Mechanical note-taking is basically converting sound into handwriting.

It consumes exactly the attention you need for understanding.

Whisperer doesn’t “study instead of the student.”

That would be both useless and rather depressing.

It removes the mechanical work: the lecture is saved, turned into notes, searchable, and available for questions.

You can go back to the exact moment you missed and figure out what you failed to understand at minute fifteen — before spending the next hour and a half nodding along as if everything made sense.

The difference is roughly the difference between:

“copy what’s on the board”

and

“understand what’s written on it.”

Leo — and the Difference Between a Chatbot and a Colleague

And this is where Whisperer started becoming something more than a collection of tools.

Because once you have hundreds of conversations, meetings, documents, tasks, and notes, a very natural question appears:

Why save all of this if you can’t actually talk to it later?

That’s how Leo was born.

Leo is Whisperer’s AI agent.

I try not to call him simply an “AI assistant.”

The word “assistant” has been worn down so much that you can use it for everything — from a chatbot to a Wi-Fi coffee machine.

I’m more interested in a different idea.

A regular chatbot knows exactly what you told it in your last message.

It’s brilliant and amnesiac at the same time.

Every conversation starts from scratch, and every time you have to explain who you are, what you’re working on, and why it matters.

A work agent should understand something else:

what happened before, what you’re working on now, and what you actually need.

Here’s a real example from my day:

“What did we promise Romashka last week, and what hasn’t been done yet?”

There isn’t a single word in that question that can be answered from general knowledge.

You need the meetings with that client, the tasks that came out of them, and their current status.

Under the hood, Leo uses LangGraph, long-term memory with vector search through Qdrant, and a set of tools connected to the platform’s data.

Technically, you could call it:

RAG + tools + memory.

Practically, the difference is between:

“a smart conversational partner”

and

“a colleague who’s actually in the loop.”

The Hub: Where Context Stops Falling Apart

Over the course of a day, a person accumulates meetings, conversations, files, notes, tasks, decisions, and ideas.

And then everything immediately starts falling apart.

The meeting is in Zoom.

The agreement is in Telegram.

The file is in Google Docs.

The task is in a project tracker.

The note is in Obsidian.

The idea is sitting in a browser tab you’ll keep open for another month.

None of these tools are doing anything wrong.

They simply don’t know about one another.

The Hub is an attempt to organize context around the work, rather than around the tool.

“Romashka — implementation.”

“Hire a designer.”

“2.0 release.”

The meeting automatically belongs to the relevant piece of work, and an agreement gets an address — the tracker board where that work is actually waiting.

It sounds obvious.

The first version sent tasks to the first project it happened to find because there was literally nothing to tell it which project was correct.

There was no entity that knew what the meeting belonged to.

So we had to build one.

What Works Worse Than I’d Like

Since we’re among friends here…

When you build a product alone, you have a wonderful one-person team.

That person is the CTO, backend engineer, frontend engineer, DevOps, designer, support, and the guy who asks himself at 1 a.m. why he started this in the first place.

One of the team’s recent achievements:

The fonts on the landing page broke and stayed broken for a month because a relative url() in CSS survived a file move, while Vite quite reasonably left the string exactly as it was.

Someone once opened a room with basically no styling at all — the second entry point simply didn’t know about the CSS for that section.

AI makes mistakes.

Sometimes beautifully and convincingly, which is worse.

I’ve rebuilt some ideas three times, and not because the code was bad.

Because the first version was solving the wrong problem.

Technically, the whole thing is fully asynchronous Python: FastAPI, SQLAlchemy 2.x with asyncpg, PostgreSQL, Qdrant, Redis, LangGraph, TaskIQ, and NATS JetStream.

The frontend is React with TypeScript, feature-first, with the import graph checked by a machine rather than by sheer force of will.

Sixteen interface languages, because:

“Let’s start with Russian and English, and add the rest later”

is a surprisingly effective way to make sure you never add the rest.

But none of that matters if, after the meeting, you still don’t remember what you decided.

Why Build This?

I’m not building an AI product.

I’m building a thing that tries to give people their attention back.

After a meeting, you shouldn’t have to reconstruct what happened from memory.

After a lecture, you shouldn’t have to piece the material back together from scraps.

During an international conversation, you shouldn’t have to be your own translator.

And during a technical meeting, you shouldn’t have to simultaneously be the developer, stenographer, secretary, and human context-transfer layer between browser tabs.

AI is the tool here, not the point.

The point is that all the mechanical work surrounding communication consumes an absurd amount of the resource that should have gone into the actual work.

And I Still Don’t Know If It Will Work

This is probably not the most appropriate ending for an article about my own product.

But it’s the only honest one I have.

I don’t know whether Whisperer will become a big product.

I don’t know whether millions of people will need it.

I don’t know which of today’s ideas will look brilliant a year from now — and which ones will look ridiculous.

But I do know one thing.

I started building it as a tool for myself.

And now I have a slightly disturbing habit:

I join a meeting and immediately check whether the recording is running.

Because without it, I’m back to being that guy who gets four lines out of a two-hour meeting.

Two of them still say:

“!!”

If this made you curious, take a look at Whisperer.

whisperer.one