How to fix duplicate conversation threads with Gemini agents in n8n?

Sometimes Gemini agents in n8n create duplicate conversation threads because the workflow is generating a new “conversationId” on every run instead of reusing one, or because multiple triggers fire for the same incoming message. The fix is always the same: make sure every message in the same chat uses the same stored conversationId, and make sure your workflow only triggers once per user message. In real workflows this usually means: storing the conversationId in a database or n8n data store, checking before creating a new thread, and updating the stored value after Gemini returns its response.

 

Why the duplication happens

 

With Gemini’s “agents” or “chat sessions”, Google expects you to pass the same conversation or session ID every time you send a new user message. If you skip that step, Gemini assumes you want a brand‑new thread and spins up a duplicate conversation. In n8n this frequently occurs because:

• Your Trigger node runs twice (duplicate webhook calls, form resubmission, etc).
• A Function/HTTP Request node generates a new thread ID every time.
• You never store the conversationId anywhere persistent.
• You do store it, but your lookup conditions are wrong and the workflow doesn’t retrieve the existing one.

 

How to fix it (stable production pattern)

 

The reliable production approach is:

• Use a single unique key for the user (email, chat userId, phone number, etc).
• Store Gemini’s conversationId the first time the user starts a chat (n8n Data Store or external DB).
• On each new incoming message, look up the stored conversationId before calling Gemini.
• Only create a new agent thread if no ID exists for that user.
• Always pass that stored ID into your Gemini API request.

 

Concrete n8n pattern (100% valid)

 

Below is the typical layout of a stable n8n workflow:

• Trigger node (Webhook, Telegram Trigger, etc)
• Get User Key (Function node normalizing user identifier)
• Lookup conversationId (Data Store or DB node)
• IF node:
  • IF found → use it
  • IF not found → create new conversation via Gemini API
• Send user message to Gemini (passing the correct conversationId)
• Store updated conversationId (if Gemini returned a new one)
• Send reply back to user

 

Typical Function node example

 

// Normalizes the incoming user ID so you always use one consistent key
// This avoids accidental duplicate threads from slightly different identifiers

return [
  {
    json: {
      userKey: $json.userId || $json.email || $json.chat_id, // depends on your trigger
      message: $json.message
    }
  }
];

 

Gemini API call example (HTTP Request node)

 

// This example assumes you're calling the Gemini REST API manually.
// body.conversationId should be the stored one.

return {
  method: "POST",
  url: "https://generativelanguage.googleapis.com/v1beta/models/gemini-pro:generateContent",
  qs: {
    key: $credentials.apiKey
  },
  body: {
    // IMPORTANT: re-use the same conversationId!!
    "conversationId": $json.conversationId, 
    "contents": [
      {
        "role": "user",
        "parts": [{ "text": $json.message }]
      }
    ]
  },
  json: true
};

 

Common mistakes that cause duplicates

 

• Starting a new conversationId inside the same workflow run.
• Using $uuid() or random strings for conversationId every time.
• Not storing the ID anywhere persistent (Data Store is easiest).
• Not checking for an existing conversationId before creating one.
• Webhook triggers firing twice because the caller retries (fix with signature verification or idempotency keys).

 

Final clarification

 

If Gemini sees a new conversationId, you get a new thread. If n8n fires your workflow twice for the same message, you get duplicate threads. Fix both by storing the conversationId and ensuring the trigger is idempotent. Once the stored ID logic is correct, duplicates disappear entirely.