Record a call or meeting, then let AI turn the raw audio into a transcript and a short summary: what was decided, who owns each next step, and what is still open. Picasso IA hosts 488 models, so transcription and summarizing both happen in one place.
A one-hour call rarely turns into a five-minute summary on its own. Someone has to listen back, or trust a shaky memory of who agreed to what. AI can do the listening: turn the recording into a full transcript, then pull out the decisions, the owners and the open questions, so the notes reach the team in minutes instead of after someone finally finds time to rewatch the whole thing.
There is no single button that turns a raw recording into finished meeting notes, and a tool that claims otherwise is skipping a step you should see. The honest process has two distinct stages. First, a speech-to-text model listens to the full audio and produces a transcript, every word, in order, timestamped. Second, a language model reads that transcript and distills it: which statements were decisions, who made them, what actions follow, and what was left unresolved. Treating these as one step hides where errors creep in, and treating them as two lets you check the work in between.
On Picasso IA both stages live in the same Toolkit. Upload the recording to a speech-to-text model to get the transcript, read it once for anything that looks wrong, then feed that transcript to a text model with a prompt asking for decisions, action items with owners, and open questions. Because both steps sit in one catalog of 488 models, you are not exporting a file between two different apps to get from audio to notes, and the same two-step logic applies to a related job, turning a recorded interview into a written transcript you can quote from directly.
A summary that says "the team discussed the roadmap and agreed to move forward" is not useful, because nobody can act on it. A useful summary is specific in three ways. It names the decisions as decisions, with who made the call, not just the topic that was raised. It lists action items as commitments with an owner attached, not a diffuse "the team will look into it." And it keeps a separate line for open questions, the things the group could not resolve and pushed to a follow-up, so they do not silently disappear.
The difference shows up clearly side by side. Vague: "Discussed pricing." Useful: "Maria approved the ten percent discount for the annual plan; Diego owns updating the pricing page by Friday; still open is whether the discount also applies to renewals." The second version is longer, but it is the only one someone can act on without asking a follow-up question first. When you prompt a model to extract notes, ask for exactly this shape, decisions with an owner, action items with an owner, open questions with no owner yet, rather than a generic recap.
Recording other people without telling them is not just a courtesy question, it is a real legal issue in many places, and the rules are not the same everywhere. Some jurisdictions only require one participant, meaning you, to consent to a recording. Others require every participant on the call to agree before you press record. Company policy can add another layer on top of whatever the law requires. None of this is legal advice, and the specifics depend on where you and the other participants are, so when in doubt, ask.
The simple, low-friction habit that covers most cases is to say out loud, at the start of the call, that you are recording it for notes and to give anyone a chance to object. This protects you, and it has a practical side benefit: that spoken announcement gets transcribed too, so the summary opens with an unambiguous record of consent instead of leaving it to memory.
Pro tip: ask each participant to state their name once near the start of the call, right after the recording notice. Speech-to-text models struggle to label who is speaking in a group recording, and a clean audio sample of each voice early on gives both you and the model something to match against for the rest of the transcript.
Not every meeting needs the same kind of summary. A client call and an internal standup produce very different transcripts, and asking for the same generic notes from both wastes the useful parts of each one. Tell the model what kind of meeting it is listening to, and ask it to emphasize accordingly.
| Meeting Type | What the Notes Should Emphasize | What to Downplay |
|---|---|---|
| Client or sales call | commitments made to the client, pricing agreed, next contact date | internal small talk, tangents |
| Internal team standup | blockers raised, who owns fixing them, today's stated priorities | status recaps already known to the team |
| Project planning session | scope decisions, deadlines set, who owns which deliverable | brainstorming that did not lead anywhere |
| One-on-one review | feedback given, goals agreed, follow-up date | general conversation not tied to a decision |
The pattern across all four rows is the same: the notes should mirror what that meeting is actually for, not a flat transcript summary that treats every sentence as equally important.
An honest tool page says where the tool breaks, and a generated summary has real limits worth knowing before you rely on one.
The process below takes about as long as the meeting itself the first time, and considerably less once it is a habit. Credits are only spent on the transcription and summary steps, and you can check the cost of a run on the pricing page before committing, or see the Descript comparison for a dedicated transcription app instead.
Yes, but it happens in two steps rather than one. A speech-to-text model first turns the audio into a full transcript, then a text model reads that transcript and pulls out the decisions, action items and open questions. Skipping straight from audio to a finished summary in one pass tends to produce vaguer results, since the model has less structured text to reason over. Two visible steps also mean you can catch a transcription error before it becomes a wrong line in the notes.
Audio alone is enough. Speech-to-text models work from the sound of the recording, and video adds nothing to the transcript itself. Recording audio only also keeps file sizes small and uploads fast, which matters if the meeting ran long. The one case where video helps is if you personally want to review body language or a shared screen later, but for the notes workflow itself, audio is the whole input.
It depends heavily on audio quality and how many people are talking. A single clear voice on a good microphone in a quiet room transcribes with very few errors. A group call with cross-talk, background noise or a bad phone connection will produce more mistakes, particularly around names and numbers. Because the summary is built entirely from the transcript, always treat the transcript as the thing to verify first; if it looks clean, the summary built from it usually is too.
It depends on where you and the other participants are, and the rules genuinely differ between places, some require only your own consent, others require every participant to agree. This is not legal advice; check the rules that apply to you. The safe habit regardless of jurisdiction is to say out loud at the start of the call that you are recording, which covers consent and gets captured in the transcript as a record that you did.
Overlapping speech is the hardest thing for a transcript to handle cleanly. The model may merge both speakers into one garbled line, attribute the words to the wrong person, or drop one voice for that stretch. This is the single biggest source of errors in group call transcripts, more than accents or background noise. If a decision was made during cross-talk, treat that part of the transcript as unreliable and verify it against the recording directly.
Not reliably on its own, which is why the prompt you use for extraction matters. Ask the model explicitly to only list something as a decision if the transcript shows clear agreement, and to flag anything uncertain as an open question instead. Left to a generic prompt, a summarizing model can turn a tentative suggestion into a stated decision, which is exactly the kind of error that causes real confusion later if nobody double-checks it.
For a typical thirty to sixty minute meeting, transcription usually finishes in a few minutes, and generating the decisions and action items from that transcript takes well under a minute more. The slowest part of the whole process is usually the human step, reading the transcript once to spot-check it and reading the draft notes before sharing them, and that time is worth spending rather than skipping.
Often yes. Once you have a transcript, you can ask the summarizing model to write the decisions, action items and open questions in a different language than the meeting was held in, which is useful when the team that needs the notes does not share the language the call happened in. The transcript itself should stay in the original language so it remains checkable against the recording.
New accounts receive free credits, enough to transcribe and summarize a real meeting and see whether the workflow fits how your team actually works. After that, both the transcription and the summarizing step spend credits, and current plans are listed on the pricing page. There is no separate meeting notes tier; the same credits work across every model in the catalog.
For most working meetings, yes, once you build in the spot-check and group review steps described above. It is not a reason to stop paying attention during the call, since a person present catches tone and context a transcript cannot. Think of it less as a replacement for listening and more as a replacement for the tedious part, writing everything down afterward, which nobody actually enjoyed doing anyway.
Your next call is probably already on the calendar. Record it with consent, run the audio through the Toolkit, and send out decisions and owners before anyone has time to forget what they agreed to.
