Building an always-on briefing or newsletter with AI

A daily or weekly AI briefing can reduce repeated scanning when it retrieves the right material and preserves links back to the sources. The benefit and reading time depend on the audience, coverage, and error rate; measure them instead of promising saved hours.

Done badly, it becomes another email you skip. The difference is in the architecture and, more importantly, the iteration.

This article presents a candidate architecture, acceptance criteria, and maintenance loop. Whether the briefing is worth reading must be measured with its actual audience.

Use the current n8n Schedule Trigger documentation for scheduling details. Before email delivery or tracking, map the actual audience and jurisdiction against official rules such as the UK’s electronic-mail marketing guidance; do not copy one jurisdiction’s consent or soft-opt-in rule into another.

The four jobs of a briefing

A useful AI briefing does four things, in order:

1. Gather — pull content from many sources.
2. Filter — keep only what matters to your specific audience.
3. Synthesise — distill into a structured, scannable output.
4. Distribute — deliver to the right place at the right time.

Each is a distinct concern. We’ll walk through each.

Job 1: Gathering

The sources are the foundation. A briefing fed by mediocre sources will be mediocre regardless of how clever the AI step is.

Common source types:

RSS feeds. When a publisher supplies a maintained feed, an RSS reader can retrieve structured updates without scraping. Validate completeness, update timestamps, redirects, and publisher terms; RSS availability and quality vary.

Approved news or search APIs. Shortlist providers against source coverage, licensing, attribution, redistribution terms, retention, rate limits, data location, and structured metadata. Product names and entitlements change; do not treat a vendor list in an article as approval.

Specific websites scraped. Sites without RSS or APIs can be scraped, but be careful about TOS and robots.txt. Tools like ScrapingBee, Bright Data, or Playwright handle the technical side.

Social media. Some platforms expose official APIs with access and usage restrictions. Do not assume an interface may be scraped; check current API documentation, site terms, privacy obligations, and redistribution rights.

Newsletters. Forward subscriptions to a dedicated email, then process them. The AI can extract content from email HTML.

Internal sources. Slack channels, internal docs, customer support tickets. For internal briefings, these often matter more than external sources.

Research databases. Semantic Scholar, arXiv, PubMed — for academic-leaning briefings.

Choose the initial source set from the topic’s coverage needs and the team’s review capacity. Track unique useful items, false inclusions, important omissions, duplication, cost, and source failures before expanding it.

An illustrative source tiering pattern—replace the counts after measuring coverage—is:

• Tier 1 (review every item): a small set whose full output the reviewer can inspect.
• Tier 2 (frequently relevant): sources that require transparent filtering.
• Tier 3 (occasional): sources retained for defined topics or events, not generic volume.

The filter (Job 2) treats each tier differently.

Job 2: Filtering

Filtering determines what can be omitted as well as included. Measure both false inclusions and important omissions; a shorter briefing is not necessarily a better one.

Three approaches, often combined:

Approach 1: Keyword and metadata filtering

Cheap, fast, transparent. Filter by:

• Keywords in title or body.
• Publication date (last 24 hours, last week).
• Source tier.
• Categories or tags from the source.

This catches the obvious. It also misses subtle relevance.

Approach 2: Embedding-based filtering

For each item, compute a vector embedding. Compare to a vector representing “what I care about” (built from past interesting articles or a description of your interests). Keep items above a similarity threshold.

This catches semantic relevance — articles about your topics that don’t use your specific keywords.

Approach 3: LLM-based filtering

For each item that passed the cheap filters, run a small LLM call:

You are filtering content for a daily briefing aimed at [audience description].

Given this article title and the first 300 words, score it 1-10 on relevance to the audience, and produce one sentence on why it might (or might not) interest them.

Output JSON: {"score": <1-10>, "reason": "<one sentence>"}

Article:
[title and excerpt]

Keep items above a threshold calibrated on representative human labels. Do not assume an LLM filter is the most accurate or that a score of 7 has stable meaning across models, prompts, sources, or languages.

A candidate cascade is a transparent metadata/keyword filter, then an embedding or model-based classifier for unresolved items. Compare it with simpler alternatives on the same labelled set; extra stages can add latency, cost, correlated errors, and missed items.

Job 3: Synthesis

Once you have a reviewed candidate set, the synthesis step can produce a draft. Limit item count from the model context, reader needs, and measured omission risk rather than a universal daily range.

A strong synthesis prompt:

You are producing a daily briefing for [your audience description].

You have been given [N] articles that passed our relevance filter. Produce a briefing with this structure:

**Top 3 stories.** The three articles a reader must know about. For each:
- One-line title (your headline, not the source's)
- Two-sentence summary
- The source link
- One sentence on "why this matters" for our audience

**Quick reads.** 5-8 other items worth mentioning briefly:
- One sentence each
- Source link

**Skim or skip.** Items in the borderline zone, just titles + links. Reader decides if interesting.

**Patterns this week.** (Weekly briefing only) Any themes connecting the week's stories.

Tone: direct, no preamble, no "here's your briefing today." Get straight into content.

Use [my inference] for anything you're extrapolating beyond the source material.

Do not invent quotes or numbers. If you reference a statistic, cite which article.

Articles:
[full content of all filtered articles]

This prompt requests a structured draft; it does not guarantee accurate summaries, complete coverage, or useful ranking. Preserve source links and require review of claims, quotations, numbers, and material omissions before distribution.

A few variations worth knowing:

• Audience-aware framing. Different briefings need different angles. A briefing for engineers should emphasise technical implications; for executives, business implications; for journalists, news value. The “audience description” line shapes the synthesis significantly.

• Themed sections. For a specific-topic briefing (e.g., “AI safety news”), organise sections by sub-topic rather than top/quick/skim.

• Comparison and contradiction surfacing. “If multiple sources report on the same event, surface where they disagree.” Catches the interesting friction.

• Calibrated certainty. “Where reporting is thin or unreliable, mark with [single-source].” Prevents the briefing from blessing unsourced rumours.

Job 4: Distribution

The last step is delivery. A briefing that lands in the wrong place at the wrong time is worse than no briefing.

Practical questions:

Where? Choose an approved channel that matches access control, retention, consent, delivery evidence, accessibility, and reader preference. Email, chat, RSS, or a workspace page carry different obligations.

When? Ask readers when and where they want the briefing, account for time zones and quiet hours, and test delivery timing. There is no universal morning window.

How frequently? Set cadence from meaningful source volume and reader demand. Change or pause it when the result is repeatedly empty, duplicative, stale, or unread.

Personalisation. If you’re producing a briefing for multiple readers, consider light personalisation — different sections for different roles, different “top 3” based on their stated interests, different sources weighted differently.

The architecture

Putting it together, a typical briefing system looks like:

[Scheduled trigger: daily at 6 AM]
    ↓
[Fetch sources in parallel: RSS, APIs, scrapers]
    ↓
[Deduplicate: remove articles already covered]
    ↓
[Filter tier 1: keep all]
[Filter tier 2-3: keyword + embedding + LLM scoring]
    ↓
[Rank by score]
[Take the configured top N from reader, context, cost, and omission tests]
    ↓
[Synthesis prompt with all items as input]
    ↓
[Distribute: email / Slack / Notion / RSS]
    ↓
[Log approved operational metadata and controlled review samples]

The implementation may be an automation platform or a custom service. Decide from authentication, source connectors, state, deduplication, observability, review, delivery, and support requirements—not audience size alone.

A practical setup in n8n:

1. Schedule trigger at the approved delivery time (the current n8n node name and scheduling semantics are version-dependent).
2. RSS Read nodes for each tier-1 source.
3. HTTP Request nodes for any custom APIs.
4. Merge all items into a single list.
5. Code node for deduplication (by canonical source identity and content hash) against a retention window selected from the publishing cadence and source behavior.
6. Approved model or classifier node that processes each eligible item with the evaluated scoring contract.
7. Filter using the threshold calibrated on the labelled evaluation set; do not hard-code 7 from this example.
8. Aggregate items into one big context.
9. Approved model node for the synthesis prompt.
10. Send Email (or Slack message, or Notion) with the synthesised output.

Build and test each stage separately. Setup time depends on authentication, source formats, deduplication state, and delivery controls. A schedule firing successfully is not proof of a healthy briefing: alert on collection failures, empty inputs, model errors, duplicate volume, delivery failure, and unusual cost.

The discipline: keeping it worth reading

Building and operating the briefing are separate problems. Monitor whether readers use it and whether source coverage or synthesis quality degrades; delivery success alone is not evidence of value.

Some discipline habits that matter:

1. Review every output during the bounded pilot

For each pilot output, ask: what was accurate and useful, what was filler, and which important items were missing?

Change one controlled component at a time and rerun the labelled evaluation. Set pilot length from publication cadence and the number of representative issues needed, not a fixed month.

2. Track engagement

For email briefings, open rates and click rates tell you if the content is landing. For Slack, reactions and replies. For personal briefings, just notice — did you read it today or skip it?

When engagement drops, something has changed: sources are stale, the synthesis has gotten generic, the audience has shifted. Investigate.

3. Prune sources ruthlessly

Measure each source’s unique relevant contributions, false inclusions, duplication, timeliness, reliability, cost, and coverage of important subtopics. Do not remove a low-volume source if it is the only coverage for a material area.

A useful quarterly exercise: for each source, calculate “of items from this source that passed the filter, what fraction made it to top 3?” Sources that consistently fail to deliver top items get cut.

4. Watch the synthesis quality

LLMs sometimes drift. The synthesis prompt that produced great briefings in January may produce hedged, generic ones by March because the underlying model was updated. Re-test periodically. Refresh the prompt if quality has slipped.

5. Maintain a “skip list”

Specific patterns to suppress: a story that has been covered repeatedly, a particular source’s pattern of clickbait, content marketing dressed up as analysis. The skip list is a manually maintained set of filters that say “even if this passes scoring, don’t include it.”

6. Have a kill switch

Some days, nothing important happened in your topic. The honest move is to send nothing or to send a very short briefing. Building this in — “if fewer than 3 items score above 7, don’t send a full briefing” — preserves quality.

A worked example: an AI industry briefing

To make it concrete, here is an illustrative configuration for a daily briefing on AI industry news. It is not evidence of an executed or licensed newsletter:

Sources:

• Hacker News front page (filtered for AI content)
• a16z, Stratechery (Stratechery requires subscription, but Ben Thompson’s free posts work)
• Anthropic, OpenAI, Google AI, Meta AI blog feeds
• The Information’s AI coverage (requires a paid subscription if you want full articles; otherwise their public summaries)
• TechCrunch AI section
• arXiv cs.CL daily digest (filtered to “approachable” papers)
• @karpathy, @sama, @demishassabis, @swyx posts (via the X API; public Nitter-style viewers are brittle — treat them as optional, not primary)
• /r/MachineLearning top weekly posts
• Specific company official announcement pages

Filter audience description:

A serious AI practitioner who builds with the technology, follows model releases, and cares about practical implications. They are not interested in clickbait headlines, breathless hype, or “AI will end the world” content. They are interested in: new model releases and capabilities, technical research with practical implications, business and competitive moves, policy developments that affect builders, and unusual or contrarian takes from credible voices.

Filter scoring prompt:

Score this article 1-10 for a serious AI practitioner. Penalise:
- Hype framing without substance.
- Pure prediction pieces without evidence.
- Trade press recycling press releases.
- Content marketing dressed as analysis.
- Repeats of major stories already covered widely.

Reward:
- Specific technical findings or model details.
- Competitive moves or strategic shifts.
- Practical implications for builders.
- Contrarian or unexpected analysis from credible sources.

Output JSON: {"score": <1-10>, "reason": "<one sentence>"}

Synthesis prompt: the standard top-3 / quick-reads / skim-or-skip structure described above, with audience framing matching the filter description.

Delivery: Email at 7 AM local time.

This is an example format, not a reading-time or usefulness guarantee. Measure opens, source clicks, reader ratings, false inclusions, and important omissions; shorten or retire the briefing when it stops helping.

A few specific patterns worth borrowing

The internal briefing. A summary of approved internal sources can create a pulse-check, but it can also expose employee or customer data beyond its original audience. Preserve source ACLs, minimise personal data, restrict recipients, and complete privacy/security review before ingesting private channels or transcripts.

The competitive briefing. Tracking competitors’ product announcements, hiring, marketing, customer reviews. Useful for strategy, sales, and product teams.

The team-skill briefing. A weekly digest of new tools, articles, and findings in your team’s discipline. Less news-driven, more “stay sharp” oriented.

The personal investment briefing. Curated links on markets, companies, and trends you follow. It is a research index, not investment advice: verify filings and market data at their primary source, and use a qualified financial professional for regulated or consequential decisions.

The customer-voice briefing. All customer feedback (support tickets, reviews, social mentions) processed daily into themes, surprises, and notable individual cases.

Each follows the same architecture; only the sources, audience, and filter prompts differ.

Build it, then tune it against evidence

A briefing is an operated information product, not a permanent asset. The architecture is gather, filter, synthesise, and distribute; the production work is source permission, provenance, monitoring, privacy, delivery compliance, and ongoing evaluation.

Retain every item’s canonical URL, title, publisher, publication date, retrieval time, and usage rights/terms where relevant. Summarise rather than republishing source text, respect access controls and site/API terms, and have counsel review a commercial aggregation product. For subscriber delivery in Europe, review applicable direct-marketing, GDPR, and ePrivacy obligations; editorial review is not legal clearance.

Pick a topic, define an acceptance set and stop conditions, run the briefing initially to internal reviewers, and expand distribution only after measured usefulness and failure handling are acceptable.