AI-Powered Newsletter Agent with n8n

This guide documents a production-grade n8n workflow that automates the creation of an AI-focused newsletter. The workflow ingests markdown content and social posts, filters and ranks stories with LLMs, generates Axios-style sections, and packages a ready-to-send markdown newsletter, while keeping humans in the loop for approvals and final editorial judgment.

1. Workflow Overview

The newsletter agent is an n8n workflow template that:

• Ingests content from markdown files and social posts (tweets/X) for a specific date
• Filters and prepares items with identifiers, source URLs, and metadata
• Uses LLM-based selection to identify the top four stories and generate a shortlist
• Writes structured newsletter sections with strict formatting and linking rules
• Generates intro, subject lines, preheaders, and a Shortlist section
• Implements an approval loop in Slack before final packaging
• Outputs a markdown file that can be sent via Slack or a CMS

The template is designed for teams that want repeatable AI newsletter production with strong editorial control, traceability, and clear data provenance.

2. Architecture & Data Flow

At a high level, the workflow is organized into the following stages:

1. Trigger & Input – A form trigger collects the target date and optional previous newsletter content.
2. Content Ingestion – Markdown content is loaded from object storage, and tweets are pulled for the same date.
3. Filtering & Preparation – Non-relevant files are excluded, text is extracted, and metadata is normalized.
4. Story Selection (LLM-assisted) – LLM chain nodes select the top stories and generate editorial reasoning.
5. Section Generation – Each selected story is expanded into a structured newsletter section using LLM prompts.
6. Intro & Subject Line Generation – Additional LLM calls produce the intro, subject lines, preheaders, and Shortlist.
7. Approval Loop – Slack nodes gather editor approvals or feedback on reasoning, subjects, and content.
8. Final Assembly & Delivery – The finished newsletter is compiled into markdown, converted to a file, and uploaded.

The workflow uses standard n8n nodes, LangChain-style LLM chain nodes, and integrations with S3/R2, HTTP APIs, and Slack. It is structured to support production usage with careful rate limiting, retries, and guardrails in prompts.

3. Node-by-Node Breakdown

3.1 Trigger & Input Handling

• formTrigger
  Acts as the entry point for the workflow. It typically exposes:
  • date – Target newsletter date used to query content sources
  • previous_newsletter_content (optional) – Used to avoid duplicating stories that recently appeared
• set_input
  Normalizes and stores the form input as workflow-level data. This node may:
  • Standardize date formats
  • Initialize variables or default values when previous_newsletter_content is not provided

3.2 Content Ingestion

The workflow ingests content from two primary sources: markdown files in object storage and social posts for the same date.

• search_markdown_objects
  Queries the storage bucket (for example an S3-compatible or R2 bucket) that holds ingested content. It searches the data-ingestion bucket, typically using a date-based prefix or metadata filter to locate relevant objects.
• S3 / R2 download nodes
  For each object returned by search_markdown_objects, a download node retrieves the binary content. These nodes:
  • Download markdown files and related artifacts
  • Return file content and basic metadata (key, bucket, size, etc.)
• search_tweets
  Queries a tweet or X archive for the target date. This may connect to internal APIs or an external service, returning a set of social posts related to AI topics within the selected time frame.
• extract_tweets
  Processes raw tweet data into a normalized structure, extracting:
  • Tweet text
  • Author handle
  • Permalink or tweet URL
  • Timestamps and identifiers

3.3 Filtering & Preparation

Once content is ingested, the workflow filters out non-relevant items and prepares each piece with consistent metadata.

• Filter
  This node enforces the content selection rules before LLM processing:
  • Exclude non-markdown objects
  • Exclude items that are already newsletters
  • Exclude non-target content types that should not appear in this AI newsletter

  Filtering at this stage reduces LLM cost and avoids noise in the selection process.

• extractFromFile
  Converts downloaded file binaries into plain text. For each markdown file:
  • Extracts the text body that will be passed to the LLM
  • Preserves a mapping between identifiers and text content
• HTTPRequest
  When metadata or additional file information is stored behind an internal API, this node:
  • Fetches identifiers, authors, and external source URLs
  • Retrieves supplemental metadata used later for traceability and linking

After this stage, each content item typically includes:

• A stable identifier
• Source type (markdown, tweet, scraped page, etc.)
• Author information
• One or more external source URLs
• Plain-text content used as LLM input

3.4 Story Selection (LLM Chain Nodes)

The workflow uses LangChain-style LLM chain nodes to perform editorial selection over the aggregated content.

• LangChain / LLM chain nodes (story selection)
  These nodes:
  • Take the set of candidate stories (markdown text, tweets, and metadata)
  • Apply a prompt that asks the model to select the best four stories for the newsletter
  • Generate two key outputs:
    • top_selected_stories – A structured object containing the chosen stories and their identifiers
    • top_selected_stories_chain_of_thought – A narrative explanation of why each story was selected

  The chain-of-thought is not exposed to end readers but is critical for internal transparency and editorial review.

The top_selected_stories_chain_of_thought output is shared with editors through Slack to provide visibility into the model’s reasoning before writing begins.

3.5 Batch Processing of Selected Stories

Once the top stories are chosen, each one is processed individually in a loop.

• splitInBatches
  Iterates over the top_selected_stories collection. This node:
  • Splits the list of stories into manageable batches
  • Ensures controlled processing for each story to avoid timeouts or rate limits
• iterate
  For each batch, the workflow:
  • Resolves identifiers back to full source content
  • Downloads or fetches additional text if needed (for example via S3/R2 or HTTP APIs)
  • Aggregates external URLs and any related scraped pages
• LangChain / LLM chain nodes (section writing)
  For every selected story, an LLM node generates a newsletter segment that adheres to a strict template:
  • The Recap – A concise narrative summary
  • Unpacked – Three bullet points that break down the story
  • Bottom line – Two sentences that synthesize implications or takeaways

  The output is returned in a structured format so it can be easily aggregated into the final newsletter layout.

All generated sections are collected into a single data structure representing the main body of the newsletter.

3.6 Intro, Subject Lines, and Shortlist

Additional LLM prompts are used to create supporting sections and email metadata.

• LangChain / LLM chain nodes (intro)
  Produces the opening section of the newsletter, including:
  • A greeting
  • Two short paragraphs that set context for the edition
  • A transition phrase that leads into the main stories
  • A brief list of topics covered in the issue
• LangChain / LLM chain nodes (subject lines & preheaders)
  Generates:
  • Multiple subject line options
  • Pre-header text for email clients
  • A reasoning block explaining why each subject/preheader combination was chosen

  This reasoning is shared with editors to support fast decision-making and A/B testing.

• LangChain / LLM chain nodes (Shortlist)
  Creates a Shortlist section that summarizes additional notable stories that did not make the top four. These are:
  • Short, punchy summaries
  • Linked back to their source URLs, respecting the linking rules described below

3.7 Approvals & Editorial Review

The workflow includes an explicit human-in-the-loop step via Slack.

• Slack sendAndWait
  Sends messages to a Slack channel or DM that contain:
  • The chain-of-thought for story selection
  • Subject line and preheader options with reasoning
  • Optionally, previews of story sections or the assembled newsletter

  The node is configured with inline response buttons (for example Approve / Request changes) and waits for a response before continuing.

If editors request changes, the workflow can route to an edit path where only the requested elements (such as a particular subject line or a specific story section) are regenerated. Other metadata and sections remain intact, which helps preserve consistency and avoid unnecessary LLM calls.

3.8 Final Assembly & Output

After approval, the workflow compiles all generated pieces into a single markdown file.

• convertToFile
  Takes the final markdown string and converts it into a .md file that can be uploaded or archived.
• upload file
  Sends the generated file to Slack or a CMS. Typical usage:
  • Upload the markdown file to a Slack channel for the editorial or marketing team
  • Optionally post a message with a permalink to where the file is stored

The workflow then posts a final Slack message indicating that the newsletter is ready, including a link to the uploaded markdown or CMS entry.

4. Content Rules & Editorial Guardrails

The template encodes strict editorial policies directly into LLM prompts to maintain consistency and reduce risk.

• Fixed section structure
  Each main story follows the same pattern:
  • The Recap – High-level summary
  • Unpacked – Exactly three bullet points
  • Bottom line – Exactly two sentences
• Linking rules
  To ensure traceability and legal safety:
  • Only URLs that appear in the provided sources may be used
  • URLs must be copied verbatim from the source material
  • If a URL in the source is incomplete, it is still copied as-is, and the problem is surfaced to editors
• Language blacklists
  Prompts incorporate lists of banned words or phrases to avoid:
  • Overly hyped or sensational language
  • Excessive jargon that reduces readability
• Traceability requirements
  LLM outputs must:
  • Include identifiers for each referenced story
  • Honor source URLs for every linked claim
  • Generate chain-of-thought reasoning that can be inspected internally

5. Configuration Notes & Production Best Practices

5.1 LLM Cost Management

• Batch LLM calls where possible using splitInBatches and careful prompt design.
• Cache outputs for stable inputs, particularly for repeated metadata or unchanged stories.
• Use smaller or cheaper models for routine tasks (for example Shortlist summaries or simple transformations).
• Reserve larger or more capable models for creative tasks like subject line ideation or nuanced recap writing.

5.2 Data Provenance & Compliance

• Attach identifiers and source URLs to every generated segment and store them alongside final outputs.
• Persist the full set of inputs and LLM outputs for audits, debugging, or dispute resolution.
• If you work with PII or copyrighted snippets, ensure legal review and implement redaction or filtering rules before sending data to LLMs.

5.3 Security & Secrets Management

• Use n8n credential nodes and environment variables for:
  • S3/R2 access keys
  • Internal admin API tokens
  • LLM provider API keys
  • Slack bot tokens
• Apply least-privilege permissions to all keys, restricting them to only the required buckets, endpoints, and scopes.
• Rotate credentials regularly and avoid hardcoding secrets in nodes or expressions.

5.4 Rate Limiting & Retries

• Enable exponential backoff on HTTPRequest nodes that call external APIs (for example scraping services or internal admin APIs).
• Configure node-level retries for transient errors like timeouts or 5xx responses.
• Filter out empty or malformed content early in the pipeline to avoid unnecessary LLM calls.

5.5 Editorial Workflow & Approvals

• Always surface:
  • The chain-of-thought for story selection
  • Subject line and preheader reasoning

  in Slack via Slack sendAndWait nodes.

• Use a dedicated edit path or node to ensure that:
  • Only the requested portion (for example a specific story, intro, or subject line) is modified on re-run
  • Other sections and metadata remain unchanged to preserve consistency

6. Scaling & Monitoring

To operate this workflow at scale, add instrumentation and concurrency controls.

• Instrumentation
  • Add logging or custom nodes to record:
    • End-to-end run times
    • LLM token usage per run
    • API latency