Series A SalesTech Built an On-Device AI Meeting Intelligence Platform

AnyTeam is an AI meeting-intelligence stack for account executives. It runs as a desktop app inside the rep's workspace, captures calls, transcribes them locally, and feeds the transcript into language models for pre-call prep, live guidance, and post-call summaries — all on ordinary hardware the rep already owns.

Watch what an account executive actually does during a customer call. They listen. They take notes, which means they are not fully listening. They try to hold the account history in their head, because it lives in a CRM they are not looking at. And then, afterwards — often several calls later — they rebuild the conversation from memory and fragments, and type it into the CRM.

Every one of those tasks competes with the one thing the rep is there to do, which is pay attention to the customer. The reconstruction step is the worst of them: it is expensive, it happens when the details have already faded, and it is the step that quietly gets skipped when the day runs long. Which is how CRMs end up full of one-line summaries of calls that mattered.

The obvious fix — a meeting assistant — came with a condition attached that many teams could not accept. It meant shipping every customer conversation to somebody else's cloud to be transcribed. For teams with data-residency obligations, or customers who ask pointed questions about where recordings go, that is not a trade-off. It is a disqualification.

Doing it locally instead removed the objection and created four hard engineering problems in its place. The hardest of them was also the least obvious: reliably noticing that a meeting has started. At the time only a handful of applications anywhere had solved it, and none of them had published how. Everything else in the product depends on it — if the app misses the start of a call, it does nothing at all for that call — so it had to be worked out from first principles rather than adapted from someone else's answer.

• Transcribe on the rep's own laptop, fast enough to keep pace with a live conversation

• Capture clean audio across every combination of conferencing app, headset and speaker reps actually use

• Produce a transcript downstream systems can trust, clean enough to write into a CRM unedited

• Notice reliably that a meeting has started, a capability almost nobody had solved and nobody had documented

We built a desktop pipeline that runs the whole thing on the rep's machine, then tuned it until it kept pace with a live call.

Before the call, the app reads the calendar invite and resolves the companies and people involved into a structured brief, so the rep walks in prepared and the model has real context rather than a name. During the call it captures and transcribes locally, and streams guidance while the conversation is still happening. When the call ends it produces a structured summary — entities, risks, next steps — in a form the CRM can accept directly.

The constraint that shaped every decision was the CPU budget. All of this had to fit on an ordinary laptop that was already running a video call. That is the part most AI teams do not attempt, and it is the reason the product could be sold to buyers who had ruled out the cloud alternatives.

The second decision was about trust. Raw speech-to-text output is far too noisy to automate against — filler words, repeated disfluencies, the occasional invented phrase — and a noisy transcript does not just produce a worse summary. It breaks CRM syncing outright and poisons every prompt downstream. So the transcript quality was treated as the product surface, not as a preprocessing step.

Design decision: the device is the privacy boundary, not a policy. There is no upload path for customer audio, which means "no audio leaves the laptop" is something an architecture review can verify rather than something a vendor promises.

The app prepares the meeting

It reads the calendar invite, resolves the companies and participants, and builds a structured brief before anyone joins.

It notices the call has started

No button to press and nothing to remember. This is the single hardest capability in the product, and it is the one that determines whether any of the rest of it ever runs.

It captures and transcribes locally

Both sides of the conversation, on the rep's own machine, cleanly enough that the output is usable rather than merely present.

It guides the rep during the call

Cleaned transcript and account context stream into the model together, so what comes back is prompted by the actual conversation rather than a generic script.

It hands the CRM a finished record

Entities, risks and next steps, structured — so the post-call reconstruction step that used to get skipped is simply gone.

Where the data lives

The device is the boundary. Customer audio is captured and transcribed on the laptop and does not become input to a cloud service. Structured CRM output is kept deliberately separate from raw audio and free-form transcript, so what is written into a business system is a defined record rather than a transcript dump.

What runs, in what order

Resolve the meeting context, detect the live call, capture microphone and system audio, synchronise the two streams, transcribe locally, stream guidance, extract the post-call facts, hand off to CRM. All of it concurrent, all of it inside the CPU budget of a laptop already carrying a video call.

What you can see afterwards

The pipeline reports its own state at each stage: detection, audio routing, capture interruptions, transcription timing, resource use, guidance latency, extraction, and CRM handoff. That is what lets the team find the subsystem that actually failed, instead of treating every user complaint as "the AI got it wrong".

The result is a co-pilot that runs where the call happens — fast enough to keep up, and clean enough to trust with an automated CRM write.

Across nine rounds of optimisation we brought the pipeline comfortably under real-time on commodity laptops, and the transcription error rate fell from roughly 18% to 10%. The gains concentrated on exactly the things that used to break automation downstream: filler words and industry vocabulary.

• On-device live-meeting detection shipped inside a signed and notarized desktop app

• Transcription error rate cut from ~18% to 10%, clean enough to flow straight into CRM updates

• No customer audio ever leaves the laptop, which is what made the product viable for teams with data-residency constraints

What is directly demonstrable in the shipped product: live-meeting detection, local transcription, the embedded model, the signed and notarized desktop application, and the absence of any path by which customer audio reaches a cloud service.

The error-rate improvement from roughly 18% to 10% is an internal measurement taken during the tuning work. It is a real result from real runs and it has not been re-confirmed on current production traffic, so we present it as our own measurement rather than a client-verified figure.

For your own estimate, the model is calls per seller × sellers × current post-call admin time × loaded hourly cost, minus the time still spent reviewing and correcting what the system produces. The second term matters more than teams expect: a transcript that needs correcting returns far less than one that does not, which is why the error rate was worth nine rounds of work.