Agents And Tool Use hard
An agent occasionally loops, calling `search` with near-identical queries, and one overnight run took 400 steps. The team proposes a 25-step cap. Some legitimate tasks also call a slow tool that can return 50,000-token results. What stop design is most robust?
- A Host-enforced budgets on steps, tokens, and wall time plus repeat-call detection, ending in a structured partial result or escalation.
- B A system-prompt instruction to stop when progress stalls, trusting the model's judgment so long legitimate tasks are not cut off.
- C The 25-step cap on its own, since every step costs roughly the same, so a step limit bounds total tokens and wall time proportionally.
- D The 25-step cap, followed by an automatic restart from a fresh context, since loops are usually transient sampling noise.
Answer: A. Host-enforced budgets on steps, tokens, and wall time plus repeat-call detection, ending in a structured partial result or escalation.
A step cap does not bound tokens or time when individual tool results are huge or slow. Robust **stop conditions** layer step, token, and wall-time budgets enforced by the host. The cost is that some legitimate long tasks hit a limit, so the exit should return partial progress or escalate rather than fail silently. Auto-restart looks resilient but re-runs side-effecting steps and can loop forever, so it is safe only for read-only agents.
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?