hardAI Engineering

How should an agent handle tool errors, timeouts and retries?

Q: How should an agent handle tool errors, timeouts and retries?

**TL;DR.** Split responsibilities: the **runtime absorbs transient faults** (backoff retries on timeouts/429s, idempotency keys for writes) while **semantic errors go back to the model** as actionable tool results so it can correct course. Cap consecutive failures and total steps; never leak stack traces or secrets into model-visible errors. tool fails classify error <polygon class='d-arrow' points='160,105 167,113 157,11

1.2k views

Understand the problem

Resilience inside the loop: which failures the model should see and which the runtime should absorb.

error-handlingretriesagentsresilience

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Stuck? AI Nudge Available

Get a conceptual hint to guide your logic without spoiling the final implementation.

Study the solution

The solution is waiting

Give it an honest attempt first — then compare your thinking with the full walkthrough.

Read the code

Execute-with-policy wrapper

async function runTool(call: ToolCall): Promise<ToolResult> {
  try {
    const out = await retryTransient(                 // backoff for 429/5xx/timeout
      () => tools[call.name](call.input),
      { attempts: 3, idempotencyKey: call.id },
    );
    return ok(call.id, summarize(out));               // compact, context-friendly
  } catch (e) {
    if (isTransient(e)) return err(call.id, "Service unavailable, try later or use another approach.");
    return err(call.id, toActionable(e));             // "date must be YYYY-MM-DD" — no stack traces
  }
}

Join the discussion

Discussion (0)

No responses yet. Be the first to share what you think.

What should you log and trace in an LLM application?

How do you sandbox an agent and enforce least-privilege tool access?