The call and its result, by identity. Completion order is just a scheduling accident. If the bridge appends results to a list and zips that list with the model's original calls, the first completed result gets attached to the first requested call. Identical tool names and identical result schemas make this especially easy to miss. OpenAI's function-calling guide includes an ID on each tool call to submit the corresponding result. The MCP JSON-RPC request and response contract likewise uses request IDs for protocol-level correlation. An application with a separate model call ID and downstream RPC ID has to preserve their mapping explicitly.

I would retain an immutable record for each logical call: run, turn, model call ID, tool identity, validated arguments and accepted attempt. When a response arrives, look up that call ID and verify it is still pending for this run and attempt. Attach the result under that ID, regardless of arrival order. If invoice 7 times out and is retried, a late first attempt must not overwrite the accepted retry. A duplicate callback should be a no-op with an audit record, not a second result inserted into context.

The test is small: reverse completion order, add one error, duplicate a callback and let a timed-out first attempt arrive after the retry. The model must see the right invoice ID beside each amount, and a missing call must remain missing. If your application turns tool output into a natural-language observation, include the call's requested invoice ID from trusted runtime metadata, not only an invoice ID echoed by the external service.

The bridge loses the call-to-response mapping before the next model turn begins. Once the model has seen invoice 9's amount under invoice 7's call, a later citation check cannot reconstruct what it should have seen.