Agent node destroys item lineage → best practice for enriching original items with LLM output?

Questions
1

Describe the problem/error/question

Hi everyone,

I’ve built an agentic customer service workflow in n8n that processes incoming customer messages from multiple platforms.

Setup

  • Each item represents one customer conversation (with many attributes like conversation_id, message text, metadata, etc.)

  • Some messages require a response, others don’t

Problem 1: Lineage break due to filtering

I filter out messages that don’t need a response early in the flow.

This causes:

  • Item count to change (N → M)

  • Loss of item lineage / mapping

  • Downstream nodes can no longer reliably reference the original item

Problem 2: Agent node destroys original data

The filtered items then pass through multiple Agent nodes:

  • intent classification

  • context enrichment via MCP

  • etc.

However:

  • The Agent node output only contains { output: "..." }

  • All original fields (e.g. conversation_id, metadata) are lost

What I need

I want to enrich the original input item with:

  • intent

  • context

  • decisions

  • etc.

Current workaround (problematic)

I tried:

  • passing conversation_id through the LLM prompt

  • then merging LLM output back with original items via conversation_id

Problems:

  • LLM sometimes slightly alters the ID → merge fails

  • requires multiple Merge nodes → fragile

  • breaks easily with branching / async execution

  • not production-safe

Core challenge

After:

  • filtering (lineage break)

  • agent nodes (data loss)

:backhand_index_pointing_right: I no longer have a reliable way to map LLM output back to the original item

Question

What is the best practice in n8n to:

  1. Preserve item identity through Agent nodes?

  2. Enrich original items with LLM output reliably?

  3. Handle cases where some items are filtered out (i.e. lineage is broken)?

Constraints

  • Agent node does not pass through input data

  • LLM output cannot be trusted for IDs

  • Workflow includes branching, MCP calls, multiple LLM steps

What I’m considering

  • Avoid filtering (tag instead?)

  • Wrapping original data before Agent nodes

  • Avoiding Merge completely

But I’d love to understand what the recommended pattern is for this kind of pipeline.

Goal

A production-safe pattern where:

  • no data loss occurs

  • no reliance on LLM for identifiers

  • minimal fragile merges

Thanks a lot — this feels like a fundamental pattern issue with n8n + LLM workflows, so any guidance would be hugely appreciated :folded_hands:

What is the error message (if any)?

None, subsequent merges faisl silently if the llm does not pass the unique ID correctly.

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

No output, fails silently.

Information on your n8n setup

  • n8n version: 2.15.0
  • Database (default: SQLite): SQLite
  • n8n EXECUTIONS_PROCESS setting (default: own, main): own
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Linux
2

This is a really thoughtful breakdown! The core issue is that Agent nodes are designed to encapsulate behavior, not pass-through context. Here’s what I’d recommend:

  1. Avoid filtering early: Instead of filtering out “no-response” messages, tag them with a boolean field (needs_response: false). Keep the item intact, then branch based on the tag.

  2. Wrap original data before the Agent node: Create a JSON object that bundles the original item with a stable ref_id (UUID, not derived from LLM). The Agent outputs { output: “…”, ref_id: “…” }.

  3. No post-merge needed: In downstream nodes, use ref_id to look up cached originals via Store nodes or a simple key-value Merge.

Key insight: keep lineage at the data structure level, not the n8n item system. The Agent becomes a pure transformer.

If you’re doing multi-step refinement (classify → enrich → decide), wrap the whole chain in a sub-workflow that outputs { original_data, decisions }. Much cleaner.

2 Likes
3

Hi @luxmediq you should be able to solve pretty much all the context leak and output matching problems just by upgrading your SYSTEM prompt and the AI model being used, but for the output structure consider using an Output Parser so that the AI agent knows exactly how to output and also in the output parser sample JSON give it kind of real world explanations of their own fields this works all the time, and if you have some kind of vector database where you store all the enrichment guidelines so consider using that instead of an MCP, also for the data you provide to the AI agent try to clearly classify it instead of actually dumping it down, basically curate your AI prompt and System prompt very precisely so that the AI agent knows what to follow, and things should be working fine after that.

2 Likes
4

Hey Benjamin, thank you for your response and great perspective! The core issue remains the “enrichment”, so bringing the tranformed information back to the originial input. The ref_id or any other value the LLM should return because subsequent logic (merge, lookup, etc..) builds upon it is not reliable enough for production use. Trigger for this thread is exactly this error happening, where the LLM has a “typo” in the ID and thus siltently fails the merge with the original message.

Looping (Split Items) would solve the “mapping issue” since there is only one item in the loop at a given time, but combined with a human in the loop step generate new challenges :smiley:

1 Like
5

Hi Anschul, the prompt is super tight, output format is reliable, even defining the exact value to output, but the LLM still generates “typos” from time to time which is inacceptable in production automation.

6

@luxmediq can you show us the part i mean the flow where it causes errors, also the problem can be related to the AI model you are using so make sure you are using a capable model which could work with all that context.

2 Likes
8

I hope this visualizes the problem. The red circled node on the left is a Set Node that defines all field I need (incl. ID of the conversation with the customer). On the right the enhancement of the information from the set node with the additional fields from the Agent nodes via merge on Conversation ID.. The lineage is broken prior to the set node through a filter..

image
image2199×878 173 KB

9

This is a really common pain point when building agentic workflows in production. I hit the same issue building a multi-platform customer service chatbot.

The pattern I use: “Context Envelope” via Set node before each Agent

Before each Agent node, use a Set node to wrap/preserve the original fields:

// Set node - add these fields:
original_conversation_id: {{ $json.conversation_id }}
original_metadata: {{ $json.metadata }}
original_platform: {{ $json.platform }}
// ... any fields you need downstream

Then after the Agent node output, use another Set node to merge:

conversation_id: {{ $('Set - Preserve Context').item.json.original_conversation_id }}
llm_output: {{ $json.output }}
metadata: {{ $('Set - Preserve Context').item.json.original_metadata }}

This works because $('NodeName').item still references the paired input item even through Agent nodes - as long as you’re processing one item at a time (which is usually the case with Loop Over Items).

For filtering (Problem 1): Instead of filtering items out, use an IF node but keep both branches alive. On the “no response needed” branch, just use a No-op (Set node that passes through), then merge both branches at the end. This preserves lineage without dropping items.

Key rule I follow: Never rely on the LLM to return IDs. Always store context before the Agent in a referenced node, then retrieve via $('nodeName').item.json.