We built the real-time layer before we built the recorder.

Everyone in our category built for after the call. We bet the product on the 40 minutes during it.

Here's the reasoning.

I went through 350+ real B2B sales calls before writing a line of product code. The moments that decided each deal were almost never in the words. They were in the gaps — the half-second pause before "yeah, makes sense," the tone flattening, the engagement dropping two minutes before anyone said no.

A transcript captures none of that. It tells you what was said. It can't tell you who you were saying it to, or the second they checked out.

So the first thing we shipped wasn't a recorder. It was a layer that reads behavioural signal live:

→ Voice tone — curious drifting to guarded, before the language changes.
→ Engagement — the second someone leans in, and the quieter one where they leave.
→ Talk-ratio — the moment you stopped listening and started presenting.

Detection was never the hard part. Doing it in the live moment was. Coaching that arrives late is just a nicer autopsy, so we held the whole pipeline to sub-200ms — running on Zoom, Meet and Teams, with no bot joining the call. That last constraint was a privacy and UX decision we made early and never walked back.

Recording tells you what happened. Reading behaviour tells you what's about to happen — while there's still a call left to change it in.

For anyone shipping real-time inference into a live UX: how do you think about the accuracy-vs-latency tradeoff when the output is worthless if it lands a second too late?