Automating the Sift, Not the Judgment: Building My Newsletter Editor

This week I shipped the curation engine behind my weekly newsletter. Every week I read dozens of blog posts, product launches, research papers, and engineering write-ups trying to keep up with the industry updates and trends. The goal of the newsletter is to break down the developments that matter most through the lens of my four pillars: Brand, Content, Systems, and Outcomes.

I wanted a system that could handle the first pass for me. Not write the newsletter, but do the research. So I built another AI teammate.

I’m calling this one Austin.

Austin’s job is simple. Every Sunday evening it scans the web for the week’s most important stories across AI, engineering, marketing, and product. It researches each one, evaluates it through the lens of my four pillars, and prepares a shortlist for me to review before the newsletter goes out.

Start with the editorial strategy, not the scraper

Before I wrote a single line of code, I wrote the editorial strategy. Who the newsletter is for. The four pillars every issue has to serve. A hierarchy of sources where primary sources outrank commentary, and commentary outranks aggregation. A quality bar with explicit reasons to reject a story, not just reasons to keep one.

That editorial strategy became the specification. It is the same discipline I used to build Boston, the AI BDR behind my contact form. The written spec, not vibes, is what you build against, review against, and improve against. I built in taste to Austin.

What Austin does

Every Sunday evening Austin goes to work.

It:

• collects stories from a curated list of primary engineering blogs, AI companies, Hacker News, and targeted web search,
• removes duplicate stories so the same announcement does not appear three different ways,
• scores every article based on source quality, recency, and how well it fits my four editorial pillars,
• checks a six-week memory so it does not recommend the same companies or topics every other week,
• drafts my first reaction to each story so I am starting with a point of view instead of a blank page,
• delivers the strongest candidates to a review dashboard.

Then it stops. It never publishes anything.

Automate the sift, keep the judgment

The entire system is built around one idea.

Automate the sift. Keep the judgment.

Austin narrows a week of industry news down to a handful of strong candidates. From there, I decide what actually makes the newsletter. I choose the final three or four stories. I edit every take into my own voice. I write the introduction by hand. That human judgment is the product. This follows the same pattern as Boston, and it is becoming a recurring pattern in the systems I am building.

Zero to eighty percent automatically.

The research, filtering, and drafting are the tedious eighty percent, so the machine handles them. The final twenty percent is where the value lives. That is the thinking. That is the perspective. That is the reason someone subscribes in the first place.

That stays human.

The memory is what keeps it interesting

Anyone can find one good article. The hard part is publishing something worth reading every single week. A good editor remembers what they have already covered. They know when they have leaned too heavily on one company, one publication, or one topic. Software has to be taught to remember. Austin keeps a six-week memory of every issue by URL, company, and theme. If it sees the same story showing up again, it scores it lower and looks for something new instead. It is a small feature, but it is one of the most important parts of the system. Without memory, every newsletter slowly becomes the same newsletter.

The stack

I built Austin on infrastructure I already operate. A Cloudflare Worker wakes up every Sunday evening and runs the sourcing pipeline. D1 stores every candidate, every issue, and the editorial history. Workers AI drafts the initial takes using a primary model with an automatic fallback, while an AI gateway sits in front of web search.

The infrastructure itself is not the interesting part. The ownership is. Every issue, every subscriber, and every piece of editorial history lives in my own database. It would have been faster to hand everything over to a newsletter platform and let it own the subscriber list, templates, and archive. I chose not to.

The list and the archive are the asset. Everything else is infrastructure.

What’s next

The curation engine is live and already producing issues for review. The next step is building the delivery layer: subscriber management, sign-up, email rendering, and sending.

The hard part is not writing emails. It is deliverability, consent, and building a system people trust. Just like I rented search instead of building my own search engine, I will rent email delivery instead of running my own mail servers.

I will own the list. I will own the archive. I will own the product. I will rent the commodity. That will be the next build in public.

A pattern is starting to emerge

Building Austin reinforced something I have been noticing across every AI system I have built. The hard part is not writing prompts. The hard part is clearly defining the judgment you are trying to automate. Once that is written down, the implementation becomes much easier. That is the pattern behind Boston. It is the pattern behind Austin. And it is the same approach I bring to every client engagement. Specify the expertise. Write the specification. Automate the tedious eighty percent. Keep the final twenty percent where it belongs.