Your Mistral tool loop 400s after tool_calls — what is wrong with the history?

## The failure mode The loop works on the first request, the model returns `finish_reason: "tool_calls"`, you run the function, you send the follow-up — and the API rejects the request with a 400 before any tokens are generated. This is a *request validation* failure, not a model failure, which is why no amount of prompt tweaking helps and why the same code shape fails deterministically every time. Mistral checks that the `messages` array you resend describes a coherent tool exchange. ## The invariant you must satisfy A conversation containing tool use has a rigid grammar: 1. An assistant message whose `tool_calls` list holds one or more calls, each with a server-issued `id`. 2. Immediately following it, one message per call with `role: "tool"`, `tool_call_id` equal to that call's `id`, and a string `content`. 3. Only then the next assistant turn (or the next user turn). Every `tool_call_id` must resolve to a call that exists earlier in the array, and every call should be answered. Break either direction and the request is malformed. ## The four ways real code breaks it **Rebuilding the assistant turn instead of echoing it.** The most common cause. Code that normalizes messages into an internal `{role, content}` shape silently discards `tool_calls`, because on a tool turn `content` is usually empty. The history then contains an empty assistant message followed by tool results that point at ids nothing declares. Fix: store and resend the assistant object as the API returned it, including `tool_calls`, and make your internal message type able to carry it. **Minting your own ids.** Some developers generate a UUID per invocation for their own tracing and put it in `tool_call_id`. The id is not yours to choose — it is the handle the server issued in the response, and any other value fails to resolve. Keep your trace id in a separate field of your own logging, not in the wire message. **Answering only the first call.** When the model returns two or three calls, `tool_calls[0]` handling leaves the remaining calls unanswered. Iterate the list, execute each (in parallel if your tools are independent), and append a tool message for each id. **Context trimming that cuts across the unit.** A sliding window that keeps the last N messages will eventually slice between an assistant tool-call turn and its results, leaving orphans on one side. The assistant tool-call message plus all of its tool results form one atomic block: evict them together or keep them together. The same applies to summarisation — a summariser that replaces old turns with prose must not swallow half a tool exchange. ## Failures that are not history-shaped Before concluding it is pairing, rule out two neighbours. A tool `content` that is not a string (a dict or a number passed straight through from your function) is a type-validation failure — serialize with `json.dumps` first. And a call whose arguments you could not parse still needs an answer: return a tool message describing the parse failure rather than skipping the id, otherwise you convert a recoverable model mistake into a hard 400. ## Making it structurally impossible The durable fix is not defensive checks scattered through the loop; it is a history object that cannot represent an invalid state. Practical shape: - Append the raw assistant message from the response — never a reconstruction. - Have one function that takes the assistant message plus a map of `id -> result string` and returns the full list of messages to append, raising if any id is missing from the map or any key is not a real call id. - Give the trimmer knowledge of blocks rather than messages, so its unit of eviction is "assistant turn plus its tool results". - Assert the invariant in a unit test with a fixture containing two parallel calls; the multi-call path is the one that never gets exercised by hand. ## Diagnosing it fast in production Log the outgoing `messages` array with contents truncated but roles and ids intact. Nearly every instance of this bug is visible in three seconds from that log: an assistant turn with no `tool_calls`, a tool message whose id appears nowhere else, or a call id with no answering message. Because the request is rejected before generation, it costs no tokens — so a spike in these is cheap in money and expensive in latency and user-facing errors, and it should page on error rate, not on spend. ## What a senior answer includes Name the invariant, name at least two concrete ways code violates it, and then move to prevention: echo rather than rebuild, treat the tool exchange as an atomic block in trimming, and cover the multi-call path in tests. Candidates who only say "you must include the tool_call_id" have seen the docs; candidates who mention the trimming interaction have run an agent long enough for the window to fill.