Agents And Tool Use medium
Your team adds function calling to a support assistant. In testing, the model returns a well-formed tool call to `create_ticket` with valid arguments, and the conversation ends there. No ticket ever appears in the tracker. What is the most likely cause?
- A The model lacks network egress permission to reach the ticketing API, so its outbound HTTP request was silently dropped.
- B The tool schema's required fields were missing, so the provider rejected the call before forwarding it to the ticketing API.
- C The host never executed the emitted call or returned a result; the model only produces the structured request.
- D The tool call was streamed over SSE and the final chunk was lost, so the provider never committed the side effect.
Answer: C. The host never executed the emitted call or returned a result; the model only produces the structured request.
A tool call is a **structured request emitted by the model**. The **host** must parse it, run the real API call, and send the result back so the loop can continue. Option A is tempting because it assumes the model makes network calls itself, which it never does. The tradeoff is that the host owns execution, permissions, and errors. That is extra work, but it is also what makes validation and approval gates possible.
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?