Agents And Tool Use medium
An agent's `issue_refund` tool calls a payment service that sometimes takes over 30 seconds. The agent loop treats the timeout as a failure and retries, and several customers have now been refunded twice. What is the correct fix?
- A Generate an idempotency key per logical action, persist it with the step, and have the refund service deduplicate on it.
- B Disable automatic retries for all tools in the loop and ask the model to decide whether the previous attempt succeeded.
- C Raise the tool timeout so that slow refund calls finish before the agent loop considers the step failed and retries.
- D Instruct the model in the system prompt to check conversation history and never call issue_refund twice for the same order.
Answer: A. Generate an idempotency key per logical action, persist it with the step, and have the refund service deduplicate on it.
A timeout does not tell you whether the side effect happened, so retries are only safe when the downstream service deduplicates on an **idempotency key** tied to the logical action. Raising the timeout (C) shrinks the window but does not close it, because network failures can still cut off a call that already succeeded. The cost is storing keys and threading them through the stack. Plain retries without keys are fine only for read-only or naturally idempotent tools.
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?