Blog

Most people find the Summarization Chain node the same way – they’re building an AI workflow, they see it in the node panel, and they have no idea what it actually does or how it connects to anything.

The official docs tell you what the parameters are. They don’t tell you when to use Map Reduce vs Stuff, what the output looks like when it comes out, or why your text isn’t getting summarized even though the node ran without errors.

That’s what this covers.

What is Summarization Chain

A Summarization Chain is a pre-built sequence of operations from Langchain – a popular AI framework – where each step passes its output to the next, all wired together to accomplish one specific task. In this case, that task is taking long text, breaking it into manageable pieces, sending those pieces to a language model, and returning a condensed summary.

What the Summarization Chain Node Actually Does

The Summarization Chain is an AI node – part of n8n’s LangChain integration. It takes text as input, sends it to a language model, and returns a natural language summary.

Before anything else, get clear on what it is not: there’s also a core node in n8n simply called “Summarize”. That one has nothing to do with AI. It aggregates data like a pivot table, counting rows, summing values, grouping fields. Completely different tool.

The Summarization Chain is also not an Agent. Chains in n8n have no memory. Each execution is stateless – the node takes text in, returns a summary out, and forgets everything. If you need the model to remember previous messages or carry on a conversation, you need an AI Agentic workflow instead.

For one-shot summarization tasks – “take this article and give me a 3-sentence summary” – the chain is exactly the right tool.

The Three Ways to Feed It Data

When you open the Summarization Chain node, the first setting you’ll see is Data to Summarize. This dropdown has three options, and everything else in the node changes based on which one you pick. This is where most people get confused.

Node Input (JSON) – Use this when the text you want to summarize is already flowing through your workflow as a JSON field. If you pulled content from an HTTP Request, read rows from Google Sheets, or received data from a webhook, this is your option. You point the node at the field that contains the text, and it handles the rest.

Node Input (Binary) – Use this when the previous node passed along a binary file – a PDF, a Word document, an uploaded file. The node reads the binary data directly. You don’t need to extract the text first.

Document Loader – Use this when you want to connect a sub-node (like the Default Data Loader) that pulls in documents from an external source. This option unlocks the sub-node connection point at the bottom of the Summarization Chain node.

Here’s a quick reference for common situations:

Once you pick Node Input (JSON), you’ll see a Chunking Strategy setting appear. This controls how the node splits your text before sending it to the model. Simple is fine for most cases. set Character per chunks to around 3000 and Chunk Overlap to 200. The overlap means consecutive chunks share some content at the boundaries, which helps the model produce coherent summaries across chunks.

Map Reduce, Stuff, or Refine – Which One to Use

By default, the Summarization Chain uses Map Reduce. To see or change the method, click Add Option and select Summarization Method and prompts.

Here’s what each method actually does and when to use it:

Map Reduce is the right default for anything longer than a few hundred words. It’s what n8n recommends and what handles chunking most reliably.

Use Stuff when you’re certain the text is short enough to fit in one LLM call – a single email, a short review, a product description. It’s faster and cheaper.

Use Refine only when you’ve tried Map Reduce and the output feels disconnected. It’s the most token-intensive option.

One Known UI issue with Map Reduce: When you enable Summarization Method and Prompts in Map Reduce mode, the two prompt fields shown in the UI are displayed in the wrong order. The first field you see is actually the Final Prompt to Combine (the prompt used to merge all chuk summaries into the final output), and the second is the Individual Summary Prompt (the prompt used on each chunk). The labels say the opposite. If you’re customizing these prompts, double-check which field you’re editing – It’s the reverse of what the UI shows.

Let’s Build It: Summarize Articles from an RSS Feed

This workflow reads the latest articles from an RSS feed, summarizes each one, and gives you the output you can route into Slack, Notion, or anywhere else. It uses Node Input (JSON) – the most common setup.

You’ll need an AI credentials connected in n8n. If you haven’t set that up yet, then make sure to check the credentials and service guide here.

Step 1: Add a Manual or Schedule Trigger

If you’re setting up a schedule trigger, Set it to run once daily. This keeps API costs predictable during the testing, you’re not burning tokens every time you manually trigger the workflow.

Step 2: Add an RSS Read Node

Connect it to the trigger. Set the URL to any feed you want – for testing, https://hnrss.org/frontpage (Hacker News) works well.

Configure it as:

• Feed URL: your RSS source
• Limit: leave at default for now

This outputs one item per article, each with fields like title, link, and content.

Step 3: Add a Limit Node

Connect it after the RSS Read node. Set keep items to 2

During testing, don’t summarize 50 articles at once. Test with 2, confirm everything works, then remove the limit when you’re ready to go live.

Step 4: Add the Summarization Chain Node

This is the main node. Connect it after the Limit node.

Configuration:

• Data to Summarize: Node Input (JSON)
• Input: Click the expression editor and map it to the content field from the RSS node. for Hacker News this is {{ $json.content }}. For other feeds it might be {{ $json.description }} or {{ $json['content:encoded'] }} – check your RSS node output to confirm the field name.
• Chunking Strategy: Simple
  • Character Per Chunk: 3000
  • Chunk Overlap: 200
• Click Add Option – Summarization Method and Prompts
• Summarization Method: Map Reduce
• Leave the prompt fields at their default to start. Once it’s working you can customize them. Just remember the UI Swaps the label order – the top field is the Final Prompt, the bottom is the Individual Summary Prompt.

Step 5: Connect the Chat Model Sub-Node

Click the + icon on the Model connection point at the bottom of the Summarization Chain node. Search for Gemini and add Gemini Chat Model.

In the Gemini Chat Model settings:

• Credential: select your gemini credential
• Model: 2.5 flash works well here – it’s fast, cheap, and more than capable for summarization.

Step 6: Run it and Check the Output

Execute the workflow. Click the Summarization Chain node after it runs.

The output will look like this:

The summary lives inside response.text. This trips people up the first time – the output isn’t just a plain string, it’s nested inside the response object.

To use the summary in the next node, reference it with

{{ $json.response.text }}

So if you’re sending to Slack, you message field would be

{{ $json.title }}: {{ $json.response.text }}

That’s the complete workflow. Manual trigger > RSS Read > Limit > Summarization Chain > Wherever you want the summaries to go.

To understand more about how data flows between nodes like this, the n8n workflow nodes and data flow guide has a solid breakdown.

When to Use This Instead of AI Agent

The rule is simple. If the task is “text goes in, summary comes out” use the Summarization Chain. It’s purpose-built for that, it’s straightforward to configure, and it costs fewer tokens than routing through an agent.

Use an AI Agent when you need any of the following like memory across multiple interactions, the ability to call external tools or APIs during the tasks, or multi-step reasoning where the model decides what to do next. Agents handle complexity. Chains handle one defined task.

For batch summarization, processing a list of articles, emails, or documents in a workflow – The Summarization chain is the right choice every time.

You built your first AI Agent in n8n. It responded well, sounds smart, and handles questions exactly how you configured it.

Then you type “What did I just tell you?“

And it says “I don’t have information about that“

That’s not a prompt problem. Your agent has no memory of it. Every single message it receives feels like the first one, a completely fresh conversation with no context of what came before.

The Simple Memory fixes this. Here’s how to set it up correctly, what the settings actually mean, and the two mistakes that will silently break your workflow if you skip this post.

What the Simple Memory Actually Does?

When you send a message to an AI Agent in n8n, the request goes to an LLM like Claude or Gemini.

The LLM processes that one message and sends back a response. That’s it. No memory of previous turns each API call is completely independent by design.

The Simple Memory sites between your chat trigger and your AI Agent and solves this by keeping a rolling of log of recent conversation exchanges.

Before each new message goes to the LLM, n8n injects the recent chat history into the request automatically. The LLM now has context.

One important thing to understand upfront is, This memory lives inside your n8n instance’s process. It’s not saved to a database. If your n8n instance restarts, all conversation history clears. For prototyping and internal tools, that’s usually fine. For production chatbots with real uses, I’ll cover that at the end.

How to Add Simple Memory to an AI Agent

If you already have a workflow with an AI Agent node set up, adding memory takes less than 5 seconds.

Step 1

Open your workflow on the canvas. Find your AI Agent node.

Step 2

At the bottom of the AI Agent node, you’ll see a connector labeled Memory. Click it.

Step 3

A panel opens with available memory nodes. Select Simple Memory

A new node appears connected to your AI Agent via the memory connector.

Step 4

Click into the Simple Memory node to configure it. You’ll see two things

• Session Key: The identifier that groups messages into a conversation. When you’re using the On Chat Message trigger, n8n fills this automatically from the sessionId passed in the request. You don’t need to touch it.
• Context Window Length: How many recent exchanges to keep in memory. The default is 5.

Step 5

Save your workflow and test it. Open the chat, tell the agent your name, send a few more messages, then ask it to recall something you said earlier.

It will remember.

If you don’t have an AI Agent workflow yet. Start here: How to Build an AI Agent in n8n

What “Context Window Length” Actually Means?

This setting trips up almost everyone at the first time.

Context Window Length counts exchanges, not individual messages. One exchange = one message from you + one reply from the AI. That’s two messages stored.

If you set it to 5, the agent keeps the last 5 exchanges – 10 messages total in the memory.

Why does this matter? Because every message in the context window gets sent to the LLM on each new request. A window of 10 means 20 messages worth of tokens on every call. At scale, that adds up fast in both cost and response latency.

For most use cases, the default of 5 works well. If your conversations are short and task-focused (book an appointment, answer a product related questions), you can drop it to 3. If you’re building something more conversational where users reference things from much earlier, bump it up to 8 or 10 – just know you’re trading off token cost for context depth.

2 Common Errors and How to Fix Them

“No sessionId” error

This one shows up when you’re triggering your AI Agent from something other than On Chat Message trigger, a Webhook, a Scheduled trigger, or a manual test run.

This Simple Memory node expects a session identifier to know which conversation it’s working with. The On Chat Message trigger provides this automatically. Everything else doesn’t.

How to fix it for testing? Open the Simple Memory node and manually type a static value into the Session Key field – something like my_test_session. This tells the node to treat all requests as part of one conversation. It works fine for building and debugging.

How to fix it for production? If you’re triggering your agent from a webhook, you need to pass session identifier in the request and map it to the Session Key field. For a customer support bot, that might be the user’s email address or account ID. For a telegram bot, It’s the chat ID. Whatever uniquely identifies a conversation for your use case.

{{ $('Webhook').item.json.body.userId }}

Map that expression to the Session Key field and every user gets their own isolated memory. See how to handle errors in n8n if you want to add proper error handling around sessions that fail to resolve.

Two memory nodes reading from the same session

If you add more than one Simple Memory node to the same workflow without changing their Session Keys, they both read from and write to the exact same memory. This causes weird behavior, one part of your workflow may overwrite context that another part needs.

The fix is simple, give each Simple Memory node its own unique Session Key. Something like workflow_a_session and workflow_b_session keeps them separate.

One Limitation You Must Know Before Going Live

Simple Memory does not work if your n8n instance runs in queue mode.

Queue mode is a self-hosted setup where multiple worker processes share the load. When a workflow executes, n8n routes it to whichever worker is free. The Simple Memory node stores data inside the worker’s process memory, not in a shared database. If two consecutive messages from the same user land on different workers, the second worker has no idea what the first one stored.

The result isn’t an error. The agent just loses memory mid-conversation, silently with no warning.

Who this affects: If you’re running self-hosted n8n with Redis and multiple workers enabled, this is your setup. If you’re on n8n Cloud or a Single-instance self-hosted setup, you’re fine.

What to do instead: Switch to the Postgres Chat Memory node. It stores conversation history in a database that every worker can access.

When to Replace The Simple Memory

Simple Memory is the right starting point. Zero configs, nothing to provision, works immediately.

But there are two situations where you’ll need to replace it.

You’re going to production with real users. Simple Memory clears on restart. If your n8n instance ever updates, redeploys, or crashes, every active conversation loses it’s history. Users will notice. For anything facing real users, migrate to the Postgres Chat Memory node before you launch.

You’re running in queue mode. As covered above, Simple Memory and queue mode don’t work together. Postgres is the standard replacement here too (or Redis Chat Memory).

The migration is straightforward. Set up a Postgres database, add your credentials to n8n, and swap the Simple Memory node for the Postgres Chat Memory node. n8n creates the required table structure automatically on first run.

Redis Chat Memory is also an option if you need very fast read/write performance for high-traffic real-time applications. For most teams, Postgres is the simpler and durable choice though.

Once you have memory working correctly, the next thing worth exploring is what happens when you need the agent to manage that memory – Injecting system context, clearing history on demand, or inspecting what’s currently stored. That’s what the Chat Memory Manager node is for, and it connects to whichever memory node you’re already using.

Check it out here: Building a Rate Limiter in n8n with Upstash Redis

Final Thoughts

None of this requires being an expert. It requires being willing to build something, break it, understand why, and built it better.

The developers who create genuinely useful AI agents aren’t the ones who read the most about AI. They’re the one who ship something working, notice where it falls short, and keep iterating.

You now know how memory works in n8n. You know the tradeoffs, the failure modes, and when to upgrade. That puts you ahead of most people who just drop a node and assume it works.

Go build something worth remembering