How I Connected Plaud to OpenClaw and Got Better Transcripts

Plaud is excellent at one thing that matters: recording is so simple that you actually do it. I put the device on the table, hit record, and I do not have to think about microphones, apps or any other kit. The weak spot for me was what happened to the recording afterwards.

The built-in transcript and summary may be enough to get your bearings. But for longer Czech meetings I wanted more accurate speaker separation, better handling of Czech, and above all my own output shaped around my workflow. I did not want important information locked inside a single app. So we connected Plaud to my OpenClaw assistant and moved transcription to Soniox.

The result is a system that checks for new recordings every 15 minutes, downloads only the unprocessed ones, and produces a transcript, meeting notes, a task list and one readable HTML file. That file arrives in Telegram and is also stored locally next to the audio.

Why I don’t just use the transcript inside Plaud

It is not that Plaud’s transcript is unusable. In my case Soniox simply performed better on Czech, on longer conversations, and when several people take turns. That matters, because a misspelled name is annoying, but a task assigned to the wrong person is a real problem.

I also prefer to pay for transcription where the quality suits me and handle the rest in my own infrastructure. That way I am not tied to a monthly allowance of transcription minutes, a fixed summary format, or whichever features the device maker happens to ship. The audio is mine, I choose the transcription, and I can change how tasks or notes are derived from it at any time.

This is not a guide to working around a paid service. It is a practical separation of layers: Plaud is my convenient recorder, Soniox is the transcription model, and OpenClaw is the automation and decision layer.

How the automatic processing works

The pipeline is actually fairly simple:

1. OpenClaw runs a check job every 15 minutes.
2. The Plaud CLI fetches the list of recordings in Plaud Cloud.
3. A script compares their IDs against local state and downloads only new files.
4. The audio goes to Soniox with diarisation, meaning speaker separation.
5. The transcript is stored both as readable text and as structured JSON.
6. OpenClaw uses GPT-5.6 Sol in High mode to write the notes from my own template.
7. The Markdown is converted to HTML and the result arrives in Telegram.

Files are stored in folders by month, for example 2026-08. Side by side sit the original audio, the Plaud metadata, the Soniox transcript, the structured data, the Markdown summary and the final HTML. Every recording has its own stable ID, so the next check will not download or transcribe it again.

The HTML contains the meeting name, a short summary, decisions, tasks, owners, deadlines, open questions and risks. The full transcript sits at the bottom, collapsed by default. With a single file I can send someone both a quick summary and the complete source the summary came from.

The transcript is not the value. What happens after it is.

A transcript on its own is just a long wall of text. The value appears when the system reliably separates:

• what was actually decided and what was merely proposed,
• who owns which task and by when,
• what was left without an owner or a deadline,
• where the participants disagreed,
• what needs reopening at the next meeting.

That is why we use our own prompt that forbids the model from inventing missing information. If no deadline was said out loud, it has to write “no deadline set”. If nobody took a task, it marks it unassigned. That is far more useful than a confident-looking summary that has quietly smoothed over half of reality.

The other benefit is portability. Today the output goes to Telegram and to disk. Tomorrow it can go to Obsidian, a CRM or a project system without changing anything about how recordings are made.

What to watch out for if you build your own

The most important thing is idempotence: a recording must be processed exactly once. Checking the filename is not enough, because filenames can change or repeat. Use the recording ID and store the state of completed steps.

The second is error state. Downloading the audio can succeed while transcription fails. The system has to tell separately whether the audio, transcript, summary or delivery is missing. On the next run it resumes from the missing step instead of paying again for work already done.

The third is security. API keys do not belong in scripts or in the repository. Transcripts often contain personal, commercial or sensitive information, so access rights, retention periods and the list of people who automatically receive the output all need watching.

The ethics of recording are not a technical detail

Being able to record a meeting discreetly does not mean I should. When I record other people, I always tell them beforehand and explain why: that the recording is there to produce notes and tasks, for instance. People have to know recording is happening, and be able to say no.

For more sensitive conversations it is fair to add where the audio and transcript will live, who has access, and when it gets deleted. The legal rules vary by country and situation, but transparency should be the minimum regardless of any statute.

Why I think it is worth it

If you already use Plaud regularly, connecting it to your own automation turns the device from a dictaphone into genuine working memory. No manual exporting after a meeting, no waiting for a transcript, no copying text into another tool, no hunting again for who promised what.

Plaud keeps doing what it is best at: capturing a recording effortlessly. Soniox handles a good transcript, and OpenClaw turns it into output shaped exactly around how I work. This is not just about saving a few minutes. It is about decisions and tasks no longer disappearing into recordings nobody ever revisits.

And that is precisely where I see the point of a personal AI assistant: not another chat window, but a system that reliably finishes the information work you never have time for after a meeting.

Want something like this in your company?

It is worth saying how this system actually came about. I did not sit down with the documentation and study APIs. My own assistant walked me through it: it told me what to set up, in what order, and what to watch out for. I made the decisions, it supplied the procedure.

That is the part that matters. You do not need to know how to code. With a bit of help, a non-technical person can put this together. That is exactly how we did it at the Building AI Agents workshop: everyone left with an agent built around their own real task, not a demo from a slide deck.

That is what we do at company workshops. We take one thing that repeats every week at your place, whether that is meeting notes, reports, proposals or anything else, and you leave with a process that still works on Monday morning. Seven people maximum, NDA as the first step, work on your real material.

Take a look at the workshops or just get in touch and we will work out what would be worth automating first.

You might also like

• 6 tools I built for Claude Code
• DropShot: a macOS app in one afternoon
• Why I never read the first plan from Claude Code