# How to Build a Weekly AI Article Recommendation Workflow > Build a weekly AI article recommendation workflow that collects sources, removes duplicates, scores relevance, and sends a trustworthy reading list. - Source: https://www.zarifautomates.com/blog/how-to-build-weekly-ai-article-recommendation-workflow - Published: 2026-08-12 - Updated: 2026-08-12 - Pillar: AI Workflows & SOPs - Tags: weekly article recommendations, AI content curation, n8n workflow, RSS automation, research automation - Author: Zarif --- # How to Build a Weekly AI Article Recommendation Workflow A useful weekly AI article recommendation workflow does six jobs: collects new links from a small source list, normalizes their metadata, rejects old and duplicate items, scores the survivors against your interests, verifies the original URLs, and sends a short digest. The AI should rank and explain articles. It should never invent the reading list. The simplest reliable version uses **n8n, RSS feeds, an n8n Data Table, one language-model call, and Gmail or Slack**. Run it once per week, review its recommendations, and use your clicks or ratings to improve the next digest. If the final recommendations will become a public email, hand the approved items to the separate [AI newsletter production workflow](/blog/how-to-build-ai-newsletter-production-workflow). This guide focuses on the research and recommendation layer. A weekly AI article recommendation workflow is an unattended content-curation system that gathers recent articles from trusted sources, filters and ranks them against explicit criteria, then delivers a short reading list with working links and concise reasons to read each item. - Start with 10 to 20 trusted RSS feeds, not the entire web - Store every seen URL so the same article cannot be recommended twice - Use rules for freshness and duplicates before paying an LLM to score anything - Ask the model for structured fields: score, topic, summary, reason, and confidence - Recheck the original URL after scoring and before delivery - Send five to ten recommendations, not a 50-link information dump - Add retries to network nodes and a workflow-level error notification ## The workflow architecture The production path is: ```text 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 ``` This ordering matters. Deterministic checks are cheaper and more dependable than model judgment. A date filter can establish that an article is seven days old. A database lookup can establish that its canonical URL was already sent. Neither decision needs AI.
StageBest mechanismWhy
Weekly timingSchedule TriggerPredictable cadence and timezone
Source collectionRSS Read or source APIPreserves real titles, URLs, and timestamps
FreshnessDate ruleObjective and inexpensive
Exact deduplicationCanonical URL lookupPrevents repeat recommendations
Semantic relevanceLanguage modelUnderstands topic fit and usefulness
Final availabilityHTTP status checkStops dead links reaching the digest
HistoryData TableProvides memory across weekly runs
## Step 1: Define what deserves a recommendation Do not begin with nodes. Begin with an editorial policy that can fit on one screen. Use five fields: 1. **Topics:** the subjects you actively 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 do not cover. Here is a practical policy for an AI operator: ```text 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” is useless without this policy. A viral article may be a poor recommendation for your audience, while a quiet product changelog may alter a workflow you run every day. ## Step 2: Create a small, high-signal source registry Start with 10 to 20 sources. Give every source these fields: - source name; - feed or endpoint URL; - topic lane; - source type; - trust tier; - active status. A Google Sheet is convenient for editors. An n8n Data Table keeps the workflow self-contained. Use one row per source so you can disable a noisy feed without editing the automation. Prefer first-party feeds from AI labs, product changelogs, research groups, standards bodies, and practitioners who publish original work. Add broader news sources only when they consistently surface stories your primary-source list misses. RSS is still the cleanest input when a publisher offers it. n8n has an official [RSS Read node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.rssfeedread/) for retrieving a feed. When no feed exists, use an official API where possible. Treat page scraping as a last resort because layout changes can silently break extraction. ## Step 3: Run on a deliberate weekly schedule Use the [n8n Schedule Trigger](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/) and set the workflow timezone explicitly. A good personal cadence is Thursday morning: the digest arrives before the end-of-week reading window without competing with Monday inbox volume. Name the workflow by its action, such as **Send weekly AI reading recommendations**. Name nodes by their job—**Load active sources**, **Reject previously sent URLs**, **Score editorial value**—instead of leaving names like “HTTP Request 3.” Clear naming becomes operational documentation when a feed fails three months later. Run once weekly rather than polling every hour unless speed genuinely matters. The objective 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 each item to a common record before filtering: ```json { "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" } ``` Remove common tracking parameters such as `utm_source`, `utm_medium`, and `utm_campaign` before computing the canonical URL. Normalize host casing, remove fragments, and apply a consistent trailing-slash policy. This catches the same article shared through several campaigns. Do not use AI to repair missing dates or URLs. If an essential field is absent, route the item to a review list or reject it. 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 are not empty. 4. Canonical URL has not appeared in the current batch. 5. Canonical URL does not exist in delivery history. 6. Source is active. Store delivery history in a Data Table with `canonicalUrl`, `firstSeenAt`, `sentAt`, `digestId`, `score`, and optional `feedback`. n8n documents [Data Tables](https://docs.n8n.io/data/data-tables/) as persistent structured storage available to workflows. A spreadsheet or database also works, but the invariant is the same: history must survive the execution. Exact URL matching will not 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`, such as `openai-new-agents-sdk-release`. Keep the best source for each story key, with primary sources winning ties. ## Step 6: Score relevance with structured AI output Pass only the surviving metadata to the model. Full-page content increases cost, latency, copyright exposure, and prompt-injection risk. For most feeds, title, source, excerpt, publication date, and your editorial policy are enough for first-pass ranking. Ask for one JSON object per candidate: ```json { "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: ```text overallScore = relevance * 0.35 + actionability * 0.30 + credibility * 0.20 + originality * 0.15 ``` Then enforce a deterministic threshold after the model returns. For example, require an overall score of at least 72, confidence of at least 0.7, and no reject reason. The model must not alter the title, source, URL, or publication date. Carry those fields through from the feed record and join the AI-generated fields onto them. This is the central anti-hallucination control. ## A prompt that produces useful recommendations Use a prompt shaped like this: ```text 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 obvious recommendation, one rejection, and one borderline item. Examples stabilize the editorial standard better than adding adjectives such as “excellent” or “insightful.” ## Step 7: Keep diversity in the final list Pure score sorting 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 shorter trustworthy digest trains the reader to open it. Padding the list 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 obvious client or server errors, redirect loops, and pages that resolve to a domain parking screen. Do not replace a failed link with a URL suggested by the model. Either use a verified alternate already present in your collected candidates or omit the item. This final check catches articles removed after collection, broken tracking links, and source migrations. It also separates a 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 will annotate the list before a meeting. Use a subject line that makes the promise measurable: ```text Your 7 AI reads for August 10-16 ``` After a successful send, write every delivered canonical URL to history. Do not write `sentAt` before delivery succeeds; otherwise a failed email can 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. Do not let the model quietly rewrite its own policy after every click. Human-set rules should change deliberately. ## Reliability controls for an unattended workflow A scheduled workflow that fails silently is worse than a manual reading list because you stop noticing what you missed. 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](https://docs.n8n.io/flow-logic/error-handling/) covers error workflows and the Error Trigger. The operational rule is simple: every unattended failure should be visible, and retries must be safe. ## Cost and scale The workflow is inexpensive because rules reduce the candidate set before AI scoring. If 20 feeds produce 300 weekly items, freshness and URL history may cut the batch to 80. Source rules and basic quality checks may cut it 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 individual stages easier to test. Keep reusable sub-workflows stateless: pass the candidate in and return the enriched candidate without relying on hidden execution state. ## Common mistakes ### Searching the whole web on every run This creates noisy, unstable inputs. Begin 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. Preserve the source URL and verify it before delivery. ### Deduplicating only inside the current batch The same evergreen article will return next week. Persist delivery history across executions. ### Summarizing before filtering You pay to summarize items that a date or history lookup could reject. Filter first, score second, summarize only finalists when necessary. ### Publishing without human review For a private digest, automatic delivery is usually acceptable. For a public newsletter or client brief, insert approval between selection and publication. The reputation risk is different. ### No error notification A broken feed, expired credential, or model rate limit can make the workflow appear successful from the outside because no digest arrives. Error alerts turn absence into an actionable incident. ## 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, and email delivery. That version is useful, explainable, and maintainable. Only add broad web discovery, embeddings, personalized recipient profiles, or multi-channel delivery after the weekly digest consistently surfaces articles you actually read. The quality of the source registry and editorial policy will matter more than the sophistication of the model. ## Related Guides - [How to Build an AI Newsletter Production Workflow](/blog/how-to-build-ai-newsletter-production-workflow) - [The Best AI Newsletters to Subscribe To](/blog/best-ai-newsletters-to-subscribe-to) - [How to Build an AI Agent for Market Research](/blog/how-to-build-ai-agent-market-research) - [How to Create an AI Report Generation Workflow](/blog/how-to-automate-report-generation-with-ai) ## FAQ **Can AI automatically recommend recent articles every week?** Yes. Use a weekly trigger to collect feed or API items, filter by publication date and delivery history, score the remaining metadata against an editorial policy, verify the original URLs, and send the highest-ranked items. Keep URLs and dates outside the model's control. **What is the best source for an automated article recommendation workflow?** Start with first-party RSS feeds from organizations and writers you already trust. RSS provides consistent titles, links, excerpts, and dates. Add official APIs when a source has no feed, and use broad web discovery only as a separate lower-trust input. **How many articles should a weekly AI digest recommend?** Five to ten is a useful range. Send fewer when the candidates do not clear the quality threshold. A compact list with a clear reason to read each item is more valuable than a large link dump. **How do I stop the same articles appearing every week?** Normalize each canonical URL and store it in persistent delivery history after a successful send. Check new candidates against that history before AI scoring, then use a story key or title similarity to catch syndicated versions of the same announcement. **Should the workflow read the full text of every article?** Usually not. Rank first using trustworthy metadata such as title, source, date, topic, and feed excerpt. Fetch more content only for finalists when the summary quality requires it. This reduces cost, latency, prompt-injection exposure, and unnecessary copying. **Do I need a vector database for weekly article recommendations?** No. A source registry, URL history, deterministic filters, and structured AI scoring are enough for the first version. Consider embeddings only when you need personalized recommendations across a large archive and have evidence that rules plus scoring are no longer sufficient.