The same key, hand-written 15 times, broke an agent

In staging, one of my workflows stopped responding mid-test. No visible error in n8n, no exception in the logs — the agent just went silent. The cause: a timeout lock that was supposed to be removed once the conversation moved on, and wasn’t.

I went after the key that controls that lock: Helena_{{ ... }}_timeout. I found the node that creates the lock (set, with a 24h TTL) and the node that was supposed to delete it (delete). Two different constructions of the same key:

• create:Helena_{{ contact_inbox.source_id }}_timeout
• delete:Helena_{{ message.phone.replace('+','') }}_timeout

When source_id and the phone number without + aren’t the same value, the delete never matches the key the set created. The lock just sits there until the TTL expires on its own. I found the problem by searching for _timeout inside the JSON — nobody had compared those two strings side by side before.

I went to check how many other places in the workflow built that same key family (Helena_{{ phone }}, used as the session identifier for memory, message buffer, and history) and it wasn’t 2. It was more than 15 different nodes, each with its own interpolation, each depending on me remembering to keep the same formula across all of them.

Why this isn’t a lapse in attention

The workflow had prompt injection guardrails, CNPJ validation, handoff reason classification — plenty of care went into what the AI does. But the key that ties all of that to the same conversation was loose text, copied and pasted into every node that needed it. There was no single place defining “this customer’s session is X” — there were 15 places that agreed, until the day one of them didn’t anymore.

It’s the same problem as duplicated credentials that I already solved with Credential Align, just with a variable instead of a credential: a value that should have a single source of truth ends up hardcoded in every node that needs it, and drifting is expensive — in this case, a silent agent. Found in staging, before it reached the customer, but only because I happened to be testing that specific part of the flow at that moment. In a less-observed part of the flow, the same bug would have slipped through.

What the tool does

I built the Variable Normalizer to catch this pattern before it becomes an incident, right in the browser.

• 1.Paste the exported workflow JSON.
• 2.The tool scans every node looking for the same value (string, number, n8n expression) repeated across different parameters — not just identical values, but also constructions that should be identical and aren’t (e.g. two expressions that build the same logical key from different data sources).
• 3.It shows each repetition group: the value, how many nodes use it, and — when the interpolation drifts between occurrences of the “same” value — flags it as suspicious instead of staying quiet.
• 4.It suggests where to centralize: a Set node right after the flow’s entry point, holding the value once, with the rest of the workflow reading from there.

None of this leaves the browser. Parsing and scanning both run on the client.

I ran the tool against the very workflow that produced this post: 36 groups of identical values repeated across 2+ nodes, and 4 formula drifts — with, in first place, exactly the source_id vs. phone pair from the incident.

What actually matters

Repeating a value across two nodes is harmless until it stops being the same value. The tool doesn’t stop anyone from writing the same formula twice — it stops the second copy from drifting away from the first without anyone noticing.