In partnership with

Hi, I’m media innovation journalist Ulrike Langer and you’re reading News Machines. Today’s edition is a little different - I’m turning my newsletter subscription workflow into a case study (something that many of you have asked me to do for a while). In a nutshell: I subscribe to somewhere between 170 and 230 newsletters' worth of daily email. Of course, I can’t actually read that many newsletters (but I do have about a dozen faves which I always read from beginning to end.) I played around with some existing systems for summarizing inboxes but none of them reliably did what I wanted: Find the nuggets in vast streams of information that are most valuable for my beat and my personal workflow and turn them into a daily briefing. 

So, since January I have been working on my own system. The initial technical problems are all solved. But - until yesterday - I still didn’t get a reliable daily briefing out of my own system although it ran flawlessly for months. 

The weak link was always me. 

This edition is about learning from failure, what it reveals about where newsroom automation breaks – it's almost never where the pitch decks say – and how I rebuilt the whole pipeline in one day, without writing a single line of code. Paid subscribers get the complete kit at the bottom: every step, my triage rules as a template, and the daily prompt that now runs my mornings.

The machine layer worked perfectly. I didn’t.

Version 1, built in January, was a local Python script on my MacBook. It ran at 6 a.m., dropped a Word file on my desktop, and depended on my laptop being awake, at home, and un-updated. Google's credentials silently expired every seven days until I found the setting that stopped it. A macOS upgrade killed the script without a sound; I noticed days later. So I had a system but couldn’t rely on it.

Since June, a cloud script has scanned my inbox every day, identified every newsletter by its mail headers, and emailed me a digest – covering 170 to 230 newsletters on a typical weekday. It survived an operating system upgrade, an expiring-credentials regime, and a platform deprecation deadline. In engineering terms, it is the most reliable thing I have ever vibe-coded.

Sponsored

For product teams moving at AI speed.

AI makes it easier to ship anything, even bad ideas. The hard part is knowing which ideas are worth building.

Jira Product Discovery brings your ideas, customer insights, and priorities into one place, so your team can decide what to ship and move forward with confidence.

Capture ideas, prioritize with evidence, and build living roadmaps your team can rally around—all while staying connected to delivery in Jira, so everyone can see what’s being built and why.

Better product decisions in the AI era.

Since April, I’ve spent more days on the road than at home (I am writing these words in an AirBnB in Brooklyn). Two days ago, I checked when I had last opened one of those newsletter reports. Two weeks earlier. Every daily digest since September 10 sat unread, in an inbox that holds 73,000 unread threads.

That is the weak point: Automating collection did not remove my bottleneck. It only relocated it – from gathering information to the handoff between machine output and human attention. The digest still required me to open it, judge 200 items, and decide what mattered for which outlet, every day, forever. Judgment was the crucial part all along, and I had automated everything except this part.

Two builds and eight months of failures 

I did not arrive at this insight cheaply. 

Version 2 in June moved everything into the cloud. It fixed all the problems I was having and was perfectly reliable. But it changed almost nothing about my workflow, because reliability was never the problem. (There is an even older data point in my Gmail: a set of newsletter folders I created years ago for manual sorting. They contain three labeled emails, total, and then I gave up.)

Several times since June I have missed two or three or four weeks of valuable nuggets because I stopped opening the briefing reports. Too much travel in too many different time zones. Too many more immediate tasks than spending 30 minutes a day filtering and strategizing newsletter content. That’s where the system failed. I just didn’t have those 30 minutes the system still required of me per day and the backlog kept growing. 

This is how my new daily newsletter briefing looks like. It lives in the Claude chat. Every entry has a proposed level of relevance and file location. If I have no time to sign off or change anything, Claude files the entries for me unchanged in Notion.

Version 3 is an editorial policy written in prose as software 

The latest rebuild, version 3, took a few hours, this Tuesday, in a Brooklyn AirBnB, in between other work. Here is what it consists of, and note what is missing: There is no code.

The core is a triage doctrine – one page of plain English that encodes my editorial judgment as standing policy. Which senders always get opened (Digiday, Press Gazette, WAN-IFRA, Nieman Lab, Journalism UK, Simon Owens’ and Dan Oshinsky’s newsletters and about two dozen more across both languages). Which never do (local news, political commentary, every promo). Which get a judgment call based on the subject line. What counts as a story for the newsletter versus a pitch for my German trade-magazine client Kress Pro versus background I merely need to have seen. Every editorial rule I used to apply by hand, 200 times a day, written down once.

My AI assistant Claude executes that doctrine every morning as a scheduled task: It opens the scanner's daily index, shortlists 10 to 15 items, pulls the full text of those from my mailbox, and produces a briefing – each item with what happened, why it matters for my beat, and a proposed action. The briefing waits for me as a dated chat. My part now takes 10 minutes: approve, kill or redirect each item. Approved stories land in my Notion ideas database automatically. (I’m not a big fan of the Notion interface, so I let Claude handle all the storing, fetching and organizing.)

And because I have now proven that I am the least reliable component in this system, there is a rule for my absence: Proposals I don't get to within 48 hours are filed anyway automatically, marked so I can distinguish the machine's decisions from my own.

Day one produced the case for the design. The first briefing surfaced, among ten items: newly unsealed documents in the New York Times' case against OpenAI, with Microsoft employees internally describing the training-data practices in terms harsher than most publishers dare to use publicly; and the Financial Times' new detection tool logging 1.23 million access requests from a single £1 trial account in under eight hours. It skipped 155 items. Reading the briefing took four minutes.

If this architecture sounds familiar, it should. When I reported on Reuters' AI buildout from the ONA conference in April, political editor Andy Sullivan described his Federal Register Bot: It checks about 200 regulatory filings three times a day, filters them by beat, and delivers a digest to 25 to 30 journalists each morning. His hard-won estimate – a prototype takes hours, a trustworthy tool takes months – matches my eight months exactly. What I have built is the solo-practitioner version of Sullivan's bot, with one difference the intervening months made possible: The filtering logic no longer lives in code that has to be tuned. It lives in language that can simply be edited.

One more important thing had to change, now that Claude has automated access to my inbox. The newsletters that I subscribe to no longer live in my personal inbox. A single mail filter routes all of them into their own labeled space, which is the only space the AI reads. My correspondence and sensitive data stays outside the system’s reach. 

Left: The continuation of my own newsletter briefing. Right: The generic Morning Brief from Claude (from the new section: scheduled tasks) which I didn’t build. I’m showing it just for comparison. This briefing is much less relevant for me and full of personal details that don’t belong there.

The question to ask every automation pitch: Where does its output meet a human?

My two unread weeks are not a personal quirk. They are the standard failure mode of newsroom automation, usually hidden inside someone else's dashboard. Jonathan Leff, Reuters' global editor for newsroom AI, diagnosed the problem plainly in that same ONA session: A tool that requires journalists to change their behavior gets used by the few who seek novelty; a tool embedded where people already work gets used by everyone. 

My scanner required a behavior – open the file, do the triage – that I demonstrably would not sustain. The rebuild moved the meeting point: The system now does the judgment-shaped work up front and asks me for ten minutes of decisions, in the place where my workday already starts. And if I can’t even show up for that there still is no daunting ever-growing backlog.

That’s the story. The setup that works is in the kit below the paywall break. You can build this in any of the major AI ecosystems because the pattern, not the vendor, is the point. I built mine with Claude, whose scheduled tasks run on any paid plan according to Anthropic's documentation – with one caveat: I have been on the highest consumer tier (the Max plan for $200 per month) since November 2025, so I cannot tell you from experience whether the entry-level plan's usage limits absorb a daily run on top of normal work. 

ChatGPT offers the same ingredients on its paid tiers: scheduled tasks that, since a mid-2026 update, can reach connected apps including Gmail. Gemini's scheduled actions connect to Gmail most natively of all, on Google's paid AI plans, with a cap of 10 active scheduled tasks and a Google Doc or Sheet standing in for the story database.

Five Learnings

  1. Automation relocates bottlenecks more often than it removes them. Find where the output meets human attention before you build, because that handoff is where your system will die.

  2. Codify editorial judgment once instead of exercising it repeatedly. A written triage policy turns the most expensive daily task into an editable document.

  3. Design for your own absence. A system that assumes a disciplined human every day is a system with a known defect.

  4. Reliability and usefulness are different achievements. My most reliable build changed my work the least.

  5. Give AI a fenced-off space before giving it access. A mail filter that separates newsletters from correspondence takes three minutes and settles the source-protection question before it arises.

The scanner still runs every day. So does the briefing. The difference is that the system no longer waits for me to be better than I am – and the part of it doing the editorial work is a page of prose I can rewrite over coffee. How I did it, step by step - that part is below.

logo

Want more operational details?

You've read the free part. Below is the operational layer that makes it usable in your own newsroom or journalistic workflow – the templates, steps, numbers, and decisions behind it, for paying subscribers.

Upgrade now