Hi everyone!
I am a beginner with n8n and I would really appreciate some help. I have an AI Agent workflow that handles table reservations via Google Calendar.
The Context: Yesterday, my AI Agent was working perfectly. Today, it completely fails at deleting events. The only change I made was duplicating the workflow to test some things, but I made sure that ONLY the original workflow is active/published. All duplicates are inactive.
The Problem:
-
When I ask the AI to book a table, it works flawlessly. It creates the event in Google Calendar and sends a confirmation email via Gmail.
-
When I ask the AI to delete that exact same booking later, it replies in the chat that it “cannot find the event in the calendar.”
What I found in the Executions log: The weirdest part is that the connection works. In the Executions tab, I can see that the Create an event node successfully creates the booking and generates an event ID. Later, when I ask for deletion, the AI correctly triggers the Get many events node. The Output of this search node clearly shows that it found the exact same ID that was just created! However, despite having the correct ID in the output, the AI Agent just stops. It doesn’t pass the ID to the Delete an event node at all.
My questions:
-
Could having inactive duplicate workflows mess up the AI’s memory or tool routing?
-
Is this a known Tool Chaining issue where the AI Agent stops after the first tool (Get many) and fails to execute the second (Delete)?
Any advice on how to force the Agent to pass the found ID to the delete node would be a lifesaver! Thank you!
1 Like
Hi @szanyifbence Welcome!
What i would recommend is that remove the deletion of event entirely from one agent, and let any sub AI agent handle that with very strict prompt, most of the times this occurs with free handed prompts, so consider tightening your system prompt.
Hi @szanyifbence , welcome to the n8n community!
From my point of view, this isn’t really a Google Calendar problem, but more about how the Agent decides whether another action is needed. If I wanted to guarantee that the deletion always runs, I’d make that step more deterministic in the workflow instead of relying entirely on the Agent’s internal decision-making. And no, inactive duplicate workflows don’t interfere with the Agent’s memory or routing
Hi
Thank you so much for your insightful responses!
@Anshul_Namdev, I will definitely look into tightening my system prompt. I hadn’t considered that free-handed prompts might be causing the Agent to lose track of the tool chain.
@tamy.santos, your point about making the process more deterministic really hit the mark. I want to ensure the workflows run reliably every single time.
To give you more context, this was a perfectly functioning agent that met all my needs, but then for some reason, the delete function just broke down. Here is exactly how I want the system to work:
-
Booking: The Agent collects 4 details from the user (Name, Date/Time, Guest count, Phone number). Using these, it creates a Google Calendar event and then sends a confirmation email to the pub.
-
Cancellation: The Agent asks for the necessary details to identify the booking. It then searches for the event, deletes it from the Calendar, and sends a cancellation email to the pub.
I’ve attached a screenshot of my current workflow logic. As you can see, right now I just have all the separate tools (Calendar Create, Get Many, Delete, and Gmail Send) connected directly to the AI Agent.
I have two quick follow-up questions:
-
Based on my goals, would you recommend building separate Subworkflows for the booking process and the cancellation process (e.g., tying Search → Delete → Email strictly together) to make it deterministic, instead of letting the Agent pick the tools one by one?
-
What could be the reason behind the “intermittent” failure? It’s baffling that the exact same setup works perfectly one day and fails to pass the ID to the delete node the next, without any changes to the workflow.
I would really appreciate any further advice on how to optimize this!
Best regards,
@szanyifbence, happy to help 
1- Yes, for your use case, I would recommend separating booking and cancellation into structured subworkflows.
2- This kind of intermittent behavior is normal with LLM-based Agents, since their decisions aren’t fully deterministic and can vary even if your workflow hasn’t changed. If reliability is important here, the safest approach is to make the cancellation flow deterministic instead of relying entirely on the Agent’s reasoning.