Every call to my Conversation Flow Agent fails with the same error, on every retry, across every backend deployment:
400 {“type”:“error”,“error”:{“type”:“invalid_request_error”,“message”:“tools: Tool names must be unique.”}} The agent has exactly two custom function tools, both with distinct names:
lookup_volunteer
book_consultation
Both are configured as standard Custom Function nodes, marked Global, “Wait for Result” and “Talk While Waiting” both enabled. Nothing else registered.
What rules out a config mistake on my end: I rebuilt this from scratch as a brand new agent (agent_058aa1…730) with no edit history, and it produces the identical error. So this isn’t leftover state from an older agent, it’s the same on a fresh build with just these two tools.
The call transitions from begin to the first node fine, calculates the LLM input token length, then immediately fails on all 3 retry attempts (bedrock-runtime-claude-global, vertex-anthropic-global, anthropic-default) with the same “tools: Tool names must be unique” error every time, then silently ends the call.
Two example call IDs showing this:
call_9ba48bde188ad8c3343aa2076d3
call_ca44b30a122e66b7689bd49e01e
Is there a known duplicate being injected server-side (e.g. from a default/system tool colliding with a custom tool name), or something in how Custom Function tools get registered that could cause this?
Edit: Worth noting that this exact tool configuration (same tool IDs, same structure) successfully completed real calls as recently as Aug 12 - nothing in my agent’s tool definitions has changed. Wondering if it may be due to something having changed platform-side between then and now, rather than a config issue on my end.
the same error occurs on both the original and newly created agent,
the two visible custom-function names are distinct,
it reproduces across multiple model backends, and
the same configuration was working on Aug 12,
I’d preserve the current failing agent exactly as-is while Retell investigates rather than repeatedly renaming/rebuilding things.
If possible, I’d also capture:
the approximate first date/time this began failing,
one last-known-good Call ID from before the failure,
one current failed Call ID,
and screenshots/exported configuration showing the two registered tool names.
That should give the Retell team a much cleaner before/after comparison and help determine whether an additional tool is being registered outside what the UI shows.
It’s extremely odd because I’ve created the same agent on another account that I made just to see if it was my account only and yeh, it worked fine on that account, it’s just my account that seems to have the issue on.
Agent ID for test account that works: agent_e1fdbc1f2181f1d150d32bbbff
Working call id example on that new separate account: call_1690e63e273e0b059cdd2d33ea1
On the original account:
One ‘good’ call id on original account (from 08/17/2026): call_d1040f6ccd83a88caf24b223698
That was one of the main test calls I did that worked.
The next call that had a major error was with call id (from 08/22/2026): call_b94ce9cae2720b338a88388138f
I know that there was a retell update that rolled out on the 25/08/2026, not sure if that could have anything to do with it.
That new-account comparison is a really useful isolation test.
If the same agent/tool structure works on the fresh account but fails on the original account, that makes an account/workspace-specific state or server-side registration issue much more plausible than a simple duplicate name in the visible configuration.
One timeline detail also looks important:
known-good call on original account: 8/17
major failed call on original account: 8/22
Retell update you mentioned: 8/25
So the 8/25 update likely cannot explain the initial failure if the problem was already present on 8/22.
I’d give Retell the working new-account Agent ID alongside the failing original-account Agent IDs and ask them to compare the effective registered tool set / account-level configuration between the two environments.
That A/B comparison may be more useful now than continuing to rebuild the agent.
Yes — I’d package it as one compact A/B escalation rather than sending the pieces separately.
Something like:
FAILING ORIGINAL ACCOUNT
Workspace/account identifier
Original failing Agent ID
Freshly rebuilt failing Agent ID
One known-good Call ID from before the problem
One representative failed Call ID
Approximate date/time the failures first appeared
WORKING CONTROL ACCOUNT
Working Agent ID
One successful Call ID
Confirmation that the visible tool names/configuration are materially the same
Then I’d state the actual question very explicitly:
“Can you compare the effective registered tool set and any account/workspace-level configuration or cached state between the working and failing accounts? The same visible agent/tool structure works in the new account but fails in the original.”
That gives engineering a clean control vs. failure comparison instead of making them reconstruct the timeline from the thread.
I would avoid posting anything sensitive publicly; if Retell needs full account identifiers or additional logs, send those through whatever private support channel they provide and link back to this thread.
Once Retell gets the 400 resolved, I’d be interested in independently testing the lookup_volunteer → book_consultation path end-to-end.
I’m validating MARUPA, an outside-in Voice AI QA service. The focus is not just whether the call completes, but whether the intended business action actually happened correctly downstream.
For a workflow like yours I’d test cases such as successful lookup + booking, no-match recovery, unavailable slot, tool failure/retry, and duplicate-booking prevention.
I’m running the first five scenarios free while validating the method. Happy to test this workflow once the platform issue is cleared.