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: