How to Build a Weekly AI Article Recommendation Workflow

A good weekly AI article recommendation workflow does six things: it collects new links from a small source list, cleans up their metadata, drops old and duplicate items, scores what's left against your interests, checks that the URLs still work, and sends a short digest. The AI ranks and explains. It never invents the reading list.

The simplest reliable version runs on n8n: RSS feeds, an n8n Data Table, one language-model call, and Gmail or Slack for delivery. Run it once a week, look over what it recommends, and let your clicks or ratings sharpen the next digest.

If the recommendations are headed for a public email, hand the approved items to a separate newsletter production workflow. This guide only covers the research and recommendation layer.

The workflow architecture

Here's the production path:

Weekly schedule
  -> Source list
  -> Read feeds
  -> Normalize article fields
  -> Reject old and previously seen URLs
  -> Score remaining articles with AI
  -> Apply quality threshold
  -> Sort and keep the top items
  -> Verify URLs
  -> Build digest
  -> Send email or Slack message
  -> Record delivered URLs and feedback fields

The order matters. Deterministic checks are cheaper and more reliable than model judgment. A date filter can tell you an article is seven days old. A database lookup can tell you its canonical URL already went out. Neither one needs AI.

Step 1: Define what deserves a recommendation

Don't start with nodes. Start with an editorial policy that fits on one screen.

Use five fields:

1. Topics: what you actually want to learn about.
2. Audience: who the reading list serves.
3. Freshness window: normally seven to ten days for a weekly digest.
4. Evidence standard: primary sources, technical documentation, research, or operator analysis.
5. Exclusions: press-release rewrites, thin listicles, duplicate announcements, gated pages, or topics you don't cover.

Here's a practical policy for an AI operator:

Recommend articles about AI agents, workflow automation, model releases,
enterprise adoption, and measurable small-business use cases.

Prefer primary sources, technical implementation detail, original data,
and credible operator lessons. Reject generic trend summaries, copied
launch announcements, unsupported predictions, and articles older than
10 days. The reader should learn something they can apply this month.

The word "best" means nothing without this policy. A viral article can be a bad recommendation for your audience, while a quiet product changelog can change a workflow you run every day.

Step 2: Create a small, high-signal source registry

Start with 10 to 20 sources. Give each one these fields:

• source name
• feed or endpoint URL
• topic lane
• source type
• trust tier
• active status

A Google Sheet works well for editors. An n8n Data Table keeps the workflow self-contained. Use one row per source, so you can turn off a noisy feed without touching the automation.

Prefer first-party feeds: AI labs, product changelogs, research groups, standards bodies, and practitioners publishing original work. Add broader news sources only when they consistently catch stories your primary-source list misses.

RSS is still the cleanest input when a publisher offers it. n8n has an official RSS Read node for pulling a feed. When there's no feed, use an official API instead. Treat page scraping as a last resort. Layout changes can break extraction without warning.

Step 3: Run on a deliberate weekly schedule

Use the n8n Schedule Trigger and set the workflow timezone explicitly. Thursday morning is a good default: the digest lands before the end-of-week reading window and skips the Monday inbox pile-up.

Name the workflow by what it does, something like Send weekly AI reading recommendations. Name nodes by their job too, not "HTTP Request 3": try Load active sources, Reject previously sent URLs, Score editorial value. Clear names are documentation. You'll need them when a feed breaks three months from now.

Run once a week rather than polling every hour, unless speed actually matters here. The goal is a thoughtful recommendation set, not a breaking-news terminal.

Step 4: Normalize every article into one schema

Feeds disagree about field names and date formats. Convert every item to one common record before you filter anything:

{
  "title": "Article title",
  "url": "https://publisher.example/article",
  "canonicalUrl": "https://publisher.example/article",
  "publishedAt": "2026-08-10T09:00:00Z",
  "source": "Publisher",
  "sourceTier": "primary",
  "topicLane": "ai-agents",
  "excerpt": "Feed-provided description",
  "collectedAt": "2026-08-12T02:00:00Z"
}

Strip tracking parameters like utm_source, utm_medium, and utm_campaign before you compute the canonical URL. Normalize host casing, drop fragments, and apply one trailing-slash rule everywhere. This catches the same article shared across several campaigns.

Don't use AI to repair missing dates or URLs. If a required field is missing, route the item to a review list or reject it outright. A fabricated publication date makes the freshness filter meaningless.

Step 5: Remove old, repeated, and low-quality candidates

Apply the cheap gates first:

1. URL uses HTTP or HTTPS.
2. Publication date is inside the freshness window.
3. Title and excerpt aren't empty.
4. Canonical URL hasn't appeared in the current batch.
5. Canonical URL doesn't exist in delivery history.
6. Source is active.

Store delivery history in a Data Table with canonicalUrl, firstSeenAt, sentAt, digestId, score, and an optional feedback field. n8n documents Data Tables as persistent structured storage available to workflows. A spreadsheet or database works too, but the rule stays the same: history has to survive the execution.

Exact URL matching won't catch syndicated copies or two articles covering the same announcement. Add a second duplicate check after scoring: compare normalized titles, or ask the model for a short storyKey like openai-new-agents-sdk-release. Keep the best source for each story key. Primary sources win ties.

Step 6: Score relevance with structured AI output

Pass only the surviving metadata to the model. Full-page content adds cost, latency, copyright exposure, and prompt-injection risk. For most feeds, title, source, excerpt, publication date, and your editorial policy are enough for a first-pass ranking.

Ask for one JSON object per candidate:

{
  "relevance": 0,
  "originality": 0,
  "actionability": 0,
  "credibility": 0,
  "overallScore": 0,
  "topic": "",
  "storyKey": "",
  "summary": "",
  "whyRead": "",
  "confidence": 0,
  "rejectReason": ""
}

Use a 0-to-100 scale and define the weights yourself:

overallScore =
  relevance * 0.35 +
  actionability * 0.30 +
  credibility * 0.20 +
  originality * 0.15

Then enforce a deterministic threshold after the model responds. For example, require an overall score of at least 72, confidence of at least 0.7, and no reject reason.

The model must not touch the title, source, URL, or publication date. Carry those fields straight through from the feed record and join the AI-generated fields onto them. This is the main anti-hallucination control.

A prompt that produces useful recommendations

Use a prompt shaped like this:

You are ranking a candidate article for a weekly reading digest.

Editorial policy:
[insert the saved policy]

Candidate metadata:
[insert title, source, source tier, date, topic lane, and excerpt]

Score relevance, actionability, credibility, and originality from 0 to 100.
Recommend only material that teaches the audience something usable or
changes an important decision. Penalize generic summaries, promotional
copy, duplicated announcements, and claims unsupported by the supplied
metadata.

Return only the required structured fields. Do not create, rewrite, or
infer a URL. If the metadata is insufficient, lower confidence and explain
the rejection briefly.

Include two or three examples from past weeks: one clear recommendation, one rejection, one borderline case. Examples hold the editorial line better than adjectives like "excellent" or "insightful" ever will.

Step 7: Keep diversity in the final list

Sorting by score alone often produces five versions of the same announcement. Add editorial constraints after scoring:

• maximum two articles per topic lane
• maximum one article per story key
• maximum two articles per publisher
• at least one technical or primary source
• five to ten recommendations total

If only three candidates clear the bar, send three. A short, trustworthy digest trains the reader to open it. A padded one trains them to ignore it.

For each recommendation, show:

• linked original title
• publisher and date
• two-sentence factual summary
• one sentence explaining why it matters to this reader
• topic label
• optional estimated reading time only when the source supplies it

Step 8: Verify links immediately before delivery

Run a lightweight request against each selected URL. Accept successful responses and intentional redirects. Reject client and server errors, redirect loops, and pages that resolve to a parked domain.

Don't replace a failed link with a URL the model suggests. Either swap in a verified alternate you already collected, or drop the item.

This last check catches articles pulled after collection, broken tracking links, and source migrations. It's also what separates a real recommendation engine from an AI-written list of plausible-looking citations.

Step 9: Deliver the digest and store its history

Email is the best default for a personal weekly review. Slack works for a team. Notion or Google Docs work when people annotate the list before a meeting.

Use a subject line that makes the promise measurable:

Your 7 AI reads for August 10-16

After a successful send, write every delivered canonical URL to history. Don't write sentAt before delivery succeeds. A failed email would otherwise suppress those articles forever.

Add a simple feedback mechanism:

• useful
• not relevant
• already knew this
• source quality issue

Review feedback monthly and update topic weights, source tiers, and exclusions by hand. Don't let the model quietly rewrite its own policy after every click. Rules a human set should change on purpose, not by drift.

Reliability controls for an unattended workflow

A scheduled workflow that fails silently is worse than a manual reading list. You stop noticing what you're missing.

Use these controls:

• retry network and model calls up to three times with a short backoff
• configure a workflow-level error workflow that sends the failed workflow name, execution ID, and error
• store the current digest ID so a retried run cannot send the same email twice
• cap the number of candidates entering the model step
• record counts at every gate: collected, fresh, unseen, scored, accepted, verified, delivered
• alert when collected items fall to zero or change unusually from the normal range

n8n's error-handling documentation covers error workflows and the Error Trigger. The rule is simple: every unattended failure should be visible, and every retry should be safe.

Cost and scale

The workflow stays cheap because rules cut the candidate set before AI scoring ever runs. Say 20 feeds produce 300 items a week: freshness and URL history might cut that to 80. Source rules and basic quality checks might cut it again to 30. The model scores 30 short metadata records, not 300 full articles.

At larger scale, split collection from recommendation:

1. a daily ingestion workflow collects, normalizes, and deduplicates
2. a weekly recommendation workflow reads unseen candidates, scores them, and sends the digest

This isolates feed failures from delivery and makes each stage easier to test on its own. Keep reusable sub-workflows stateless: pass the candidate in, return the enriched candidate, and don't rely on hidden execution state.

Common mistakes

Searching the whole web on every run

This creates noisy, unstable inputs. Start with a source registry, then add discovery as a separate lane with a lower trust tier.

Letting AI invent or rewrite links

URLs are collected data, not generated prose. Keep the source URL intact and verify it before delivery.

Deduplicating only inside the current batch

The same evergreen article will show up again next week. Persist delivery history across executions.

Summarizing before filtering

You end up paying to summarize items a date or history lookup would have rejected for free. Filter first, score second, summarize only the finalists, and only when you need to.

Publishing without human review

For a private digest, automatic delivery is usually fine. For a public newsletter or a client brief, add an approval step between selection and publication. The reputation risk isn't the same.

No error notification

A broken feed, an expired credential, or a model rate limit can all make the workflow look fine from the outside, because nothing arrives and nothing complains. An error alert turns silence into an incident you can act on.

Implementation checklist

• Write the editorial policy and exclusions
• Create a 10-to-20-source registry
• Set an explicit workflow timezone
• Normalize title, canonical URL, source, excerpt, and date
• Create persistent URL history
• Filter freshness and exact duplicates before AI
• Require structured scoring output
• Preserve source URLs outside the model output
• Enforce diversity and quality thresholds
• Verify finalist URLs
• Make delivery idempotent
• Add retries and a workflow-level error alert
• Test with a good feed item, an old item, a duplicate, a missing date, and a dead URL
• Review feedback monthly

Final recommendation

Build the narrow version first: trusted RSS feeds, a seven-day window, URL history, one scoring call, five recommendations, email delivery. That version is useful, explainable, and easy to maintain.

Add broad web discovery, embeddings, personalized recipient profiles, or multi-channel delivery only after the weekly digest consistently surfaces articles you actually read. The source registry and the editorial policy will matter more than how sophisticated the model is.

FAQ

Related Guides

• How to Build a Lead Generation Workflow in n8n Step by Step
• Build an n8n Ticket-Triage Workflow and Test Its Failure Paths
• How to Create an AI Video Production Workflow