Agents And Tool Use hard
An internal ops agent started with 12 well-scoped tools. After several teams exposed every internal API, it now has 140, including near-duplicates such as `search_orders` and `find_orders_v2`. Tool-selection errors tripled and per-call latency rose. What is the most effective fix?
- A Keep all 140 tools but expand every description with usage examples and negative cases so the model can disambiguate similar tools.
- B Consolidate overlapping tools and expose only a task-relevant subset per request, chosen by a router or a tool-search step.
- C Move to a model with a larger context window so all 140 schemas fit comfortably alongside the conversation and tool results.
- D Wrap each tool in its own single-purpose agent and add an orchestrator agent that dispatches every step to the right specialist.
Answer: B. Consolidate overlapping tools and expose only a task-relevant subset per request, chosen by a router or a tool-search step.
More tools dilute selection. Every extra schema costs prompt tokens on every step and adds a near-neighbor the model can confuse with the right tool. Narrowing to a relevant subset adds a routing step, and with it the risk of leaving out a needed tool, but accuracy goes up. Richer descriptions help when the catalog is small, but at 140 tools they inflate the prompt without removing the duplicates, and a larger window fixes capacity, not confusion.
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?