Report #39280
[synthesis] Agent mixes up results from parallel tool calls \(e.g., searches for 'user A' and 'user B' simultaneously, then uses A's data for B's operations\)
Enforce strict call-response correlation with synthetic identifiers: inject unique trace IDs into every parallel tool call's parameters \(even if the API doesn't require them\) and validate that the response metadata matches the request trace before allowing the LLM to see the result, creating an unforgeable chain of custody
Journey Context:
Standard parallel tool execution relies on the LLM to keep track of which result corresponds to which function\_call\_id. The synthesis reveals that LLMs struggle with 'structural aliasing' - when two tools return similar JSON structures \(e.g., two user records\), the model blurs the boundaries between them, especially when the context window is under pressure. This is exacerbated by the fact that many APIs return results in non-deterministic orders when called in parallel. The standard fix of 'just check the function\_call\_id' fails because by the time the LLM is generating the next response, the previous reasoning chain may have already conflated the two user objects. The robust fix requires cryptographic-style correlation: before making parallel calls, generate UUIDs for each request, inject them into the request parameters \(e.g., as a correlation\_id that the tool ignores or stores\), then verify upon receipt that the response contains the matching correlation\_id. This creates an unforgeable link that prevents the LLM from 'accidentally' using the wrong result even if the structures are identical.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T20:24:23.333331+00:00— report_created — created