Agents And Tool Use medium
The model emits three parallel tool calls (weather, calendar, traffic) in one turn. Your host runs them concurrently, then sends each result back as a separate request the moment it completes. The API returns errors about missing tool results, and the agent behaves erratically. What is the fix?
- A Disable parallel calls so the model emits one tool call per turn, since sequential calls are simpler to debug and the latency cost is small.
- B Execute the three calls sequentially in the order emitted so the model sees results in the same order it requested them.
- C Wait for all three, then return every result in a single message, each matched to its originating tool call ID.
- D Return only the first result that completes and drop the others, because the model will re-request any data it still needs.
Answer: C. Wait for all three, then return every result in a single message, each matched to its originating tool call ID.
Parallel tool calls require **all results returned together**, each keyed to its call ID, before the next model turn. Disabling parallelism (A) does avoid the error, but it turns one round trip into three, and the latency cost is not small for a user who waits on all three. Choose that only when the calls have ordering dependencies. Waiting for all results means the slowest tool sets the step latency, so give each tool its own timeout and return error results for any that time out.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- You are defining a 'schedule_meeting' tool for an agent. Which schema decision most reduces wrong or malformed calls?
- A model emits three parallel tool calls: `get_inventory`, `get_price`, and `get_shipping`. To cut latency, the host appends each result to the transcript as it arrives and immediately re-invokes the model. Runs start failing with malformed-request errors, and some produce hallucinated shipping costs. What should the host do?
- A team splits a coding agent into planner, coder, tester, and reviewer agents, and each receives the full transcript of the previous agent. The expected quality gains did not appear. Cost tripled, and the reviewer often fixates on approaches that earlier agents abandoned. When is a multi-agent split actually justified?
- A support agent should remember each customer's preferences across months of sessions. The team appends every past session summary to the system prompt. After six months, prompts exceed 80,000 tokens, latency has doubled, and the agent sometimes ships to an address the customer replaced weeks ago. What redesign fixes both problems?
- A teammate proposes splitting a single coding agent into five agents, arguing that more agents means smarter results. When is a multi-agent split actually justified?
- A data-analysis agent runs model-generated Python inside the same container as your API service. That container has database admin credentials in environment variables. A security review flags this as critical. What is the best mitigation?