The response side: parallel calls and a string you must parse

Lesson 3 of 5 in Function Calling Deep Dive: The Wire Under Tool Use.

When the model decides to act, three things come back together: a stop reason telling you the turn ended in tool use, zero or more blocks of ordinary text, and one or more tool calls. Read the stop reason first — it is the branch in your loop, and treating “the response happened to contain a tool call” as your signal is how people end up dropping the model’s own explanation of what it was about to do.

Then read the calls. Plural, because a single assistant turn can request several tools at once — parallel tool calls — and that changes your executor from a function into a fan-out.

One assistant turn, two parallel calls — illustrative shape, not a copy of any current API reference

{
  "stop_reason": "tool_use",
  "content": [
    { "type": "text", "text": "I’ll check both accounts before answering." },
    {
      "type": "tool_call",
      "id": "call_7Kq2",
      "name": "search_orders",
      "arguments": "{\"customer_id\":\"CUS-40118822\",\"status\":\"open\"}"
    },
    {
      "type": "tool_call",
      "id": "call_9Zt5",
      "name": "search_orders",
      "arguments": "{\"customer_id\":\"CUS-40118823\",\"status\":\"open\",\"limit\":40}"
    }
  ]
}

Three things to notice, all of them consequential. Two calls to the same tool with different arguments — “same tool twice” is the most common parallel case, not an exotic one. Distinct ids (call_7Kq2, call_9Zt5) — the only way to key results back. And arguments as a JSON string, not a JSON object: note the escaped quotes.

Parallel calls are a latency win and an operational hazard in the same feature.

The win: two independent lookups run concurrently and the model waits once instead of twice. The hazard: you must return a result for every id, and in most dialects you must return them all before the model continues. Return two results for three calls and the request fails or the model reasons over a hole. Fan out with Promise.all/asyncio.gather and you also need per-call timeouts, because the slowest call now sets the turn latency, and one hung tool stalls the whole loop.

There is a second hazard that only shows up in production. Parallel calls arrive with no ordering guarantee and no transaction. The model can perfectly reasonably emit transfer_funds and send_confirmation_email in the same turn; nothing in the protocol says the email waits for the transfer to succeed. Ordering and atomicity are your runtime’s problem — either serialise the tools that need it, or design them so out-of-order execution is safe.

Look again at that second call: "limit": 40, against a schema whose maximum is 20. Which brings us to the part of the wire that most first loops get wrong.

Arguments are a string. Handling malformed arguments is your job.

In several major dialects the arguments field is a string containing JSON, not a parsed object — because the model generated it token by token and nothing guarantees it is complete or well-formed. Truncation at a token limit, a stray trailing comma, a doubled brace, an unescaped quote inside a string: all of these reach you as a JSON.parse exception, and an unhandled exception in your executor kills the run instead of the call.

Even where an SDK hands you a tidy object, something parsed it and the parse can fail — and a successful parse says nothing about whether limit: 40 is inside your declared range, whether CUS-40118823 is a customer this user may see, or whether since is a real date. So the invariant is dialect-independent: parse defensively, validate against the schema, then authorize — every call, every time. The model is an untrusted input source that happens to be on your side.

Interactive sorting exercise: Nine things that go wrong on the response side. Sort each one by where it must be handled — because getting this wrong is how a bad call becomes a dead run.

Tool: Trace Debugger — Read real tool-use turns — mis-keyed results, truncated arguments, a parallel fan-out with a missing result — and find the broken message in the Trace Debugger.

Key terms: parallel tool calls, tool result, tool-use id, tool call, least privilege

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.