How I built my personal newsletter with AI agents

I subscribe to a lot of newsletters.

And very often I get the same feeling.

I open the email. I scroll. I see a stack of links. I tell myself “I’ll read that later.” And of course, I never do.

The problem is not the topic. The problem is the work being pushed onto the reader.

People call that monitoring. In reality, it is often just a list.

So I wanted to build a different kind of format. Not a “smarter” newsletter. Not an “AI-powered” newsletter. Just one that actually does the work of filtering, condensing, and reformulating.

And more importantly, I wanted to see whether that system could run cleanly every week without turning into a maintenance project.

The brief

I wanted something pretty simple:

• 3 to 4 stories max
• AI, mobile, product, and distribution topics
• clean source links
• one clear lesson behind each story
• a human tone
• an email short enough to read in one sitting

So the goal was not really “build a newsletter.” The goal was more like this:

build a small editorial pipeline that turns web noise into useful signal.

The general principle

The system relies on a very simple idea:

1. a cron starts the routine
2. an agent searches for stories from the last 7 days
3. it keeps only 3 or 4 strong signals
4. it reformulates each one with a useful takeaway
5. it produces the HTML email
6. it also prepares LinkedIn post ideas
7. then the sending stack delivers the digest

That sounds a bit technical. In practice, it is mostly just a clean checklist.

Layer 1: the cron

The routine runs on a weekly cron.

Its role is not to “think.” Its role is simply to trigger the right sequence at the right time.

In practice, the cron loads a Markdown brief that acts as the source of truth. That brief defines:

• the kind of stories to search for
• the time window
• the expected email structure
• the voice guardrails
• the format of the post ideas to store
• the sending logic

I like this approach because it stays readable. You can open the file and understand what the system is supposed to do without reading 300 lines of code.

Layer 2: web research

Then the agent goes out and finds the information.

I do not ask it to “find tech news.” I constrain it much more than that.

I ask it to look for signals that matter for people building apps:

• AI applied to building
• mobile development
• App Store / Play Store shifts
• monetization
• tools useful for builders

And most importantly, I ask it to come back with dated sources and clean URLs.

That sounds basic, but it matters a lot. If you do not force that discipline, you quickly get a digest full of hype, recycled summaries, or things everybody has already seen 40 times.

Layer 3: the editorial filter

This is where the system gets interesting.

The real job is not finding 4 links. The real job is answering these questions:

• what does this change for someone building?
• does it say something about distribution?
• monetization?
• velocity?
• real mobile?

For example, in a recent issue, the system kept:

• Claude Sonnet 5
• RevenueCat’s Shipaton 2026
• Google Play’s fund for indie studios in Africa
• the return of Apple Account card payments in India

Raw, that looks like 4 stories with very little in common.

But once you run them through the right filter, you get something else:

• a signal about coding agents
• a signal about public distribution
• a signal about new ecosystem openings
• a signal about payment friction in mobile

At that point, it is no longer just monitoring. It is already a reading of the market.

Layer 4: reformulation

Once the stories are selected, the system does not just spit out summaries. It follows a small stable structure:

• a short title
• the fact in 1 or 2 sentences
• one actionable lesson
• the source link

It is intentionally simple.

I am not trying to write an academic essay. And I am not trying to write a Twitter thread inside an email either. I just want a readable format that helps people open the links with context instead of rebuilding everything from scratch themselves.

Layer 5: skills

The word can sound intimidating, but here a skill is just a reusable, well-described procedure.

Instead of re-explaining to the agent on every run:

• how to search
• what to avoid
• what tone to use
• what structure to follow

I store that logic in reusable building blocks.

For this newsletter, skills mainly do three things:

1. Load the right context

The system reads the relevant files before writing:

• voice
• positioning
• proof
• content pipeline

That keeps the email aligned with how I actually write.

2. Keep the structure stable

The skill prevents every run from reinventing:

• the digest format
• the level of detail
• the guardrails
• the expected outputs

3. Reuse the effort elsewhere

The same source material can then feed:

• the newsletter
• post ideas
• articles
• and sometimes longer content

That is what I like about the system. Once the source material is filtered correctly, you can expose it in several formats.

Layer 6: concrete outputs

The routine does not just output an email. It also produces post-idea files.

In practice, for each selected story, the system writes a JSON entry into the social pipeline with:

• the angle
• the source
• the post idea
• the status

So one run feeds two things:

• the email digest
• the content idea inventory

That avoids doing the same monitoring work twice.

Layer 7: sending

Once the email is ready, the system calls the sending layer.

I did not want the agent to manage every deliverability concern by itself. I prefer separating:

• the editorial side
• and the sending side

So the result is:

• the agent prepares the content
• the sending stack takes care of subscribers, sender name, footer, and the rest

It is less sexy than a “fully autonomous full-stack agent.” But it is much cleaner.

What is worth replicating if you want your own version

If you want to build this kind of system in your own way, I think these are the key points:

1. Frame the inputs better than the outputs

The most important thing is not saying “write me a good email.” It is saying:

• what to search for
• over what time period
• in what sources
• with what editorial filter

2. Force a simple structure

If every item follows the same small structure, the output becomes much more robust.

3. Separate research, synthesis, and sending

If you mix everything together, the system gets fuzzy. If you separate the roles, it becomes easier to understand, fix, and evolve.

4. Store reusable procedures in skills

Not to sound technical. Just to avoid re-explaining the same thing every time.

5. Do not let the AI speak into the void

Require:

• sources
• URLs
• a clear time window
• a limited number of items

Otherwise you are just automating noise.

What I like about this stack

It is not the “wow, I automated a newsletter” part.

What I like is that the system removes the annoying part:

• scattered research
• filtering
• reformatting
• consistency
• repurposing into other formats

And I keep the part I actually care about:

• choosing the angle
• adjusting the level of quality
• deciding what is worth pushing forward

In other words, AI acts as the editorial assistant. Not the brain.

The real lesson

The most interesting part of this story is not the newsletter itself.

It is the pattern.

When you take a chaotic information stream and add:

• a trigger
• a research frame
• an editorial filter
• an output structure
• reusable building blocks

then you can produce something consistent without drowning in it.

And to me, that is probably the healthiest use of AI agents:

absorb friction without dissolving intention.

To wrap up

I did not just want a “cool” newsletter. I wanted a simple, replicable system that is concrete enough to be useful, but not heavy enough to become a project I have to maintain full time.

For now, that is exactly what I like about this stack.

It does not replace taste. It does not replace judgment. It does not replace voice.

But it removes a big part of the repetitive work that usually prevents this kind of format from existing over time.

If I evolve it later, it will be in that direction. Not more automation for the sake of aesthetics. More clarity, more signal, and smarter reuse of the same source material.

If you want to see what it looks like in practice, you can check the newsletter here:

App World Weekly