Agents And Tool Use medium
Your team exposed 120 internal APIs as tools to a single agent. Tool-selection accuracy dropped from about 92% with the original 15 tools to about 70%, and several near-duplicate tools are often confused. What is the best remedy?
- A Add more detailed descriptions to all 120 tools so that the model has richer context for disambiguating between similar APIs.
- B Expose a small, task-relevant subset per request (via routing or tool search), merging overlapping tools into fewer ones.
- C Keep all 120 tools and raise temperature so the model explores a wider range of tools rather than defaulting to familiar ones.
- D Keep all 120 tools but order them by usage frequency in the prompt so the most common tools are seen first by the model.
Answer: B. Expose a small, task-relevant subset per request (via routing or tool search), merging overlapping tools into fewer ones.
More tools **dilute selection**. Each one adds tokens and another near-miss option, so a smaller, task-relevant set chosen by routing or search improves accuracy. Longer descriptions (A) help with one or two confusable pairs, but across 120 tools they inflate the prompt and make the selection problem worse. The tradeoff is an extra routing step that can occasionally hide a needed tool, so keep a fallback search over the full catalog.
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?