Agents And Tool Use medium
A research agent usually finishes in 8 to 12 steps, but a few runs loop 200+ times, re-issuing near-identical searches and running up large bills. Which control most reliably prevents this?
- A Remove the search tool's ability to return empty results so the model always has new information to reason over each step.
- B Add a system-prompt instruction telling the model to stop when it believes it has gathered enough information to answer.
- C Enforce host-side budgets (e.g., 20 steps, token and wall-clock caps) and end with a partial answer or escalation when hit.
- D Switch to a larger model with a longer context window so it can remember earlier searches and avoid repeating queries.
Answer: C. Enforce host-side budgets (e.g., 20 steps, token and wall-clock caps) and end with a partial answer or escalation when hit.
**Hard budgets enforced by the host** (steps, tokens, wall time) bound the worst case no matter how the model behaves. A stop instruction (B) is tempting, but a looping model is exactly the one that fails to judge when it is done. The tradeoff is that a few legitimate long tasks get cut off. Pick cap values from the observed step distribution and offer escalation rather than a silent failure.
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?