Turn AI newsletters into a daily podcast
How aimless tinkering with Claude Cowork turned into a production automation pipeline. Task: How aimless tinkering with Claude Cowork turned into a production automation pipeline Thirty-plus AI newsletters. Most of them saying the same thing. I was spending more time managing the firehose than learning from it. Same three stories, repackaged eighteen different ways. Every morning I’d skim subject lines, skip most, and still feel like I missed something important. So I built a pipeline that reads all of them, filters the noise, synthesizes the signal into one conversational audio briefing, and publishes it as a podcast episode at 5 AM. I listen on my morning walk. I didn’t plan to build any of this. I sat down to tinker. The tinkering that got out of hand I wasn’t trying to solve the newsletter problem. Not at first. I’d been using Claude Cowork for a few months, mostly for data analysis (I wrote about that in February). But Cowork had just gone GA this week, and I wanted to push into territory I hadn’t explored yet: scheduled tasks, service integrations, the automation side of the platform. So I opened Cowork on my Mac Mini, pointed it at Gmail (which was already connected through the desktop app), and asked a simple question: can you pull my AI newsletters and give me a summary? It did. Easily. Filtered by label, grabbed the recent ones, produced a clean synthesis. Then: “OK, now what?” That question is where the interesting part starts. Because the summary was good, but it was sitting in a Cowork session. I’d have to open Cowork every morning to read it. That’s just replacing one inbox with another. Five delivery options, zero good ones Cowork suggested five ways to deliver the daily briefing: Gmail draft Gmail draft Apple Note Apple Note Slack DM Slack DM Markdown file in a folder Markdown file in a folder Scheduled task with a notification Scheduled task with a notification I rejected all of them. A Gmail draft is another email in a sea of emails, which is the problem I was trying to solve. I’m transitioning away from Apple Notes. I use Slack occasionally, not daily. A markdown file is passive: you have to remember to go look at it. And a notification that says “your summary is ready” still requires me to sit down, open something, and read. The common problem: every option assumed I wanted to read. What if I didn’t want to read? “What if instead of a text-based update, you produce an audio update?” That flipped everything. The voice problem If you’re going to listen to a daily briefing, the voice has to not make you want to throw your phone. This is where the build got messy. Attempt 1: macOS say command. The built-in text-to-speech on every Mac. Cowork tried it first because it’s right there, no install required. HORRIBLE. Completely robotic and unlistenable. Like getting the news from a GPS unit. Dead on arrival. Attempt 2: edge-tts (Microsoft). This actually sounded decent. The AndrewNeural voice was natural enough to listen to for 8 minutes. One problem: Cowork’s sandbox couldn’t reach Microsoft’s TTS servers directly. Had to run it as a scheduled task outside the sandbox. It worked, but now I had a network dependency on a 5 AM automated process. One Microsoft outage and the pipeline breaks silently. For a daily system that runs while I sleep, “it usually works” isn’t good enough. The research detour. I asked Cowork to compare local TTS options. It came back with four candidates: Kokoro (fast but emotionally flat), Qwen3-TTS (broadcast quality, MLX-native on Apple Silicon), Piper (mid-tier), and Orpheus (broken on Apple Silicon). My use case was a conversational briefing with natural transitions, not a robotic reading. Qwen3-TTS was the clear choice. Attempt 3: Qwen3-TTS. About 30 minutes to install. Not frictionless: dependency conflicts, a model download that stalled once, and some trial-and-error on chunk sizing. But manageable. 1.7B parameter model, 8-bit quantized, optimized for MLX on Apple Silicon. Voice preset “ryan” (I approved after listening to samples). It chunks text into ~550 character segments, generates audio for each, concatenates the result. Peak memory: 6.5GB on my 16GB Mac Mini M4. Fully local. No network dependency. No API costs. When the first sample came through, I stopped what I was doing and listened to the whole thing. It sounded like a person talking, not a machine reading. What actually runs every morning The scheduled task fires at 5:00 AM Central. Here’s the pipeline: Gmail search. Pulls all emails with the AI-Newsletters label received since the last run.; tools: custom-built or unnamed agent. Human role: The original post does not say how a person stayed involved.; limitations: The solution requires a dedicated Mac running 24/7 or scheduled to wake at 5 AM, with sufficient RAM (peak usage 6.5GB) for local TTS processing. Initial setup involved friction, including dependency conflicts and model download issues, though these were resolved within the Cowork session. The pipeline is currently tailored to the author's specific newsletter labels and may require adjustment for different email structures. Reliance on local hardware means the system fails if the machine is offline or asleep during the scheduled run..
Tools
custom-built or unnamed agent
Published on Agent Work Atlas:
Overview
How aimless tinkering with Claude Cowork turned into a production automation pipeline
Workflow
How aimless tinkering with Claude Cowork turned into a production automation pipeline Thirty-plus AI newsletters. Most of them saying the same thing. I was spending more time managing the firehose than learning from it. Same three stories, repackaged eighteen different ways. Every morning I’d skim subject lines, skip most, and still feel like I missed something important. So I built a pipeline that reads all of them, filters the noise, synthesizes the signal into one conversational audio briefing, and publishes it as a podcast episode at 5 AM. I listen on my morning walk. I didn’t plan to build any of this. I sat down to tinker. The tinkering that got out of hand I wasn’t trying to solve the newsletter problem. Not at first. I’d been using Claude Cowork for a few months, mostly for data analysis (I wrote about that in February). But Cowork had just gone GA this week, and I wanted to push into territory I hadn’t explored yet: scheduled tasks, service integrations, the automation side of the platform. So I opened Cowork on my Mac Mini, pointed it at Gmail (which was already connected through the desktop app), and asked a simple question: can you pull my AI newsletters and give me a summary? It did. Easily. Filtered by label, grabbed the recent ones, produced a clean synthesis. Then: “OK, now what?” That question is where the interesting part starts. Because the summary was good, but it was sitting in a Cowork session. I’d have to open Cowork every morning to read it. That’s just replacing one inbox with another. Five delivery options, zero good ones Cowork suggested five ways to deliver the daily briefing: Gmail draft Gmail draft Apple Note Apple Note Slack DM Slack DM Markdown file in a folder Markdown file in a folder Scheduled task with a notification Scheduled task with a notification I rejected all of them. A Gmail draft is another email in a sea of emails, which is the problem I was trying to solve. I’m transitioning away from Apple Notes. I use Slack occasionally, not daily. A markdown file is passive: you have to remember to go look at it. And a notification that says “your summary is ready” still requires me to sit down, open something, and read. The common problem: every option assumed I wanted to read. What if I didn’t want to read? “What if instead of a text-based update, you produce an audio update?” That flipped everything. The voice problem If you’re going to listen to a daily briefing, the voice has to not make you want to throw your phone. This is where the build got messy. Attempt 1: macOS say command. The built-in text-to-speech on every Mac. Cowork tried it first because it’s right there, no install required. HORRIBLE. Completely robotic and unlistenable. Like getting the news from a GPS unit. Dead on arrival. Attempt 2: edge-tts (Microsoft). This actually sounded decent. The AndrewNeural voice was natural enough to listen to for 8 minutes. One problem: Cowork’s sandbox couldn’t reach Microsoft’s TTS servers directly. Had to run it as a scheduled task outside the sandbox. It worked, but now I had a network dependency on a 5 AM automated process. One Microsoft outage and the pipeline breaks silently. For a daily system that runs while I sleep, “it usually works” isn’t good enough. The research detour. I asked Cowork to compare local TTS options. It came back with four candidates: Kokoro (fast but emotionally flat), Qwen3-TTS (broadcast quality, MLX-native on Apple Silicon), Piper (mid-tier), and Orpheus (broken on Apple Silicon). My use case was a conversational briefing with natural transitions, not a robotic reading. Qwen3-TTS was the clear choice. Attempt 3: Qwen3-TTS. About 30 minutes to install. Not frictionless: dependency conflicts, a model download that stalled once, and some trial-and-error on chunk sizing. But manageable. 1.7B parameter model, 8-bit quantized, optimized for MLX on Apple Silicon. Voice preset “ryan” (I approved after listening to samples). It chunks text into ~550 character segments, generates audio for each, concatenates the result. Peak memory: 6.5GB on my 16GB Mac Mini M4. Fully local. No network dependency. No API costs. When the first sample came through, I stopped what I was doing and listened to the whole thing. It sounded like a person talking, not a machine reading. What actually runs every morning The scheduled task fires at 5:00 AM Central. Here’s the pipeline: Gmail search. Pulls all emails with the AI-Newsletters label received since the last run.
Reported result
The pipeline successfully runs daily, producing an 8-10 minute audio briefing that the author listens to during morning walks. The system operates fully locally on a Mac Mini M4, eliminating network dependencies and API costs for the TTS component. The author reports that the synthesis effectively filters repetitive content, delivering a concise overview of key industry stories. No quantitative metrics on time saved or engagement rates were provided in the source.
Human role
The original post does not say how a person stayed involved.
Limitations
The solution requires a dedicated Mac running 24/7 or scheduled to wake at 5 AM, with sufficient RAM (peak usage 6.5GB) for local TTS processing. Initial setup involved friction, including dependency conflicts and model download issues, though these were resolved within the Cowork session. The pipeline is currently tailored to the author's specific newsletter labels and may require adjustment for different email structures. Reliance on local hardware means the system fails if the machine is offline or asleep during the scheduled run.
Try it
I want to build a daily audio briefing from my email newsletters using Claude Cowork. My context is [replaceable: e.g., AI industry news], and I subscribe to [replaceable: number] newsletters labeled [replaceable: Gmail label name]. I use a [replaceable: hardware, e.g., Mac Mini M4] running locally. Please execute these steps: 1. Connect to my Gmail and filter emails from the last 24 hours with the label [replaceable: label]. 2. Synthesize the content into a conversational script, highlighting 3-4 key stories and filtering out repetitive noise. 3. Generate an audio file using a local TTS model (prefer Qwen3-TTS or similar) with a natural voice preset. Do not use cloud APIs. 4. Save the MP3 and a markdown transcript to [replaceable: output folder]. Before finalizing, run a dry process on a sample of 5 emails. Show me the script and a short audio clip for approval. Only proceed to full generation and scheduling after I confirm the voice quality and content accuracy. If local TTS installation fails, report the error and suggest a fallback text-only format for my review.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.