The Meeting AI in the SOL LABS AI Playground takes a recording and returns a speaker-by-speaker transcript, a summary, and action items with priorities. On the surface it's one step — upload, see results — but behind it we had to solve quite a few problems. Here's the architecture we settled on while building and running it ourselves.
1. The overall flow
- The browser uploads the recording straight to storage (Vercel Blob)
- Speech is converted to text (STT · speech-to-text, OpenAI Whisper)
- A language model (Claude) splits the transcript by speaker and extracts a summary and action items
- Results are shown on screen, and the uploaded file is deleted right away
Serverless environments limit how large a single request can be. So the file goes to storage first, and the server only receives its address. Once processing is done, the stored file is deleted immediately, cutting both cost and retention risk.
2. Long recordings are split and processed in parallel
The Whisper API accepts files up to 25MB at a time, and an hour-long meeting easily exceeds that. Serverless functions also have execution time limits, so processing a long file in one go tends to get cut off.
So we split the path by length.
| Condition | Where it's processed |
|---|---|
| Up to 25MB and 30 minutes | Directly on the web server |
| Larger or longer files | Handed to a separate processing server (Railway), split with ffmpeg and converted in parallel |
ffmpeg (an audio/video conversion tool) is hard to run in serverless environments, so it lives on a separate server. The chunks are converted simultaneously and stitched back in order, so even long meetings process without interruption. It currently accepts files up to 200MB.
3. Speaker detection by gathering clues
With several people in one recording, figuring out "who said what" was the trickiest part. Today the language model decides based on these clues.
- Pauses between utterances — after 1.5+ seconds of silence, a different speaker is considered first
- Names mentioned in conversation — when "Mr./Ms. ○○" comes up, the next responder is confirmed
- Question-and-answer flow — the person asking and the person answering are different
- Attendee info — speakers are split only within the number of attendees provided
Long files are analyzed chunk by chunk, so the names settled in one chunk are passed to the next to keep the same person under the same name. Voice-based speaker separation (diarization models) is planned as the next step once we have GPU servers.
Trying it beats reading about itAI Playground · company analysis, meeting notes and contract review, free after a quick sign-inTry free4. Getting summary quality right
A useful summary must show at a glance "what was decided, and who does what by when." So instead of free-form summaries, we fixed the output format.
- One-line meeting summary
- Key discussion and decisions
- Action items (owner · deadline · priority)
- Things to check next time
Long meetings are processed in two stages: each chunk is analyzed first, then the chunk results are combined and organized once more. It misses less than summarizing everything in one pass.
5. Cost and reliability
Whisper costs scale with audio length, and language models with text volume. We don't blindly retry on failure, and we reuse identical instructions via prompt caching to cut cost. Daily usage limits keep the demo service from being abused.
If your meeting recordings can't leave the company, the same architecture can run on your own servers.
We review your current system and data, then outline the migration order and scope.
We build web apps, mobile apps and business systems, then add and run the AI they need. We build and operate our own meeting notes, contract and company analysis AI.
See our projects