UpdatedAug 6, 2026

Agent: Recover from Tool Failure

Question Variations

"How does an agent distinguish a timeout from a failed action?"
"What state must survive an agent restart?"
"A travel-booking tool times out after possibly reserving a flight. How should the agent recover?"

Why This Is Asked

This tests whether a candidate can make an agent recover safely from ambiguous external side effects. Interviewers assess durable workflow state, idempotency, bounded retry, reconciliation, and honest user-visible status.

Key Concepts

Durable state: Persist workflow step, inputs, and external operation IDs.
Idempotency: Use stable operation keys and query status before retrying.
Bounded recovery: Limit retries and escalate unresolved ambiguity.
User visibility: Report pending or failed state instead of fabricating completion.

Question Variations

“How does an agent distinguish a timeout from a failed action?”
“What state must survive an agent restart?”
“A travel-booking tool times out after possibly reserving a flight. How should the agent recover?”

Answers by Technology

+ Add Variant

System DesignImprove this answer ✏️

Expected Answer

I persist the workflow step, normalized inputs, idempotency key, and external operation ID before calling the booking API. A timeout means the outcome is unknown, so the agent queries status with the stable key before retrying. Retries are bounded, unresolved ambiguity becomes a visible pending state, and recovery survives process restart. That prevents a polite but incorrect claim of success or a duplicate reservation.

Why It Matters

External side effects can succeed even when the agent never receives a reply.

Common Mistakes

Retrying with a new key: It can create duplicate bookings.
Keeping state only in context: Restart recovery becomes impossible.

Follow-up Questions

What survives restart? (Answer: Step state and external operation identities.)
What does timeout mean? (Answer: Outcome is unknown, not necessarily failed.)