Your AI agent timed out. Is it safe to try again?

Welcome to FDE Field Notes, the newsletter from FDEInterviews. We work through practical engineering problems and give you something to try.

An AI agent can do more than answer a question. It can use software tools to create a task, send an invitation or update an order. Once it can change another system, it needs a way to tell whether that change actually happened.

Imagine asking a personal agent to create a follow-up task after a customer call. It finds the right customer, chooses the right owner and sends the request. The customer-management system saves the task.

Then the connection drops. The agent receives a timeout.

A timeout does not prove the action failed

The agent hasn't received a usable answer. That leaves two possibilities: the task wasn't created, or it was created and the reply never arrived. Sending another create request could leave the customer with two tasks. Reporting success would be a guess.

The useful state here is unknown.

An agent chooses its next step from observations. If its tools turn every timeout into “failed,” the next step may be a reasonable response to the wrong information. A better prompt won't recover the missing receipt.

The return arrow is where this example breaks. Everything on the service side succeeded. Recovery asks what happened to the original action.

Give the action an identity that survives the conversation

Before sending the request, the application should persist an operation ID alongside the exact intended task and the authorization to create it. In this example, that ID is fup-42. A retry of that same operation keeps the same ID; a distinct new task gets a new one.

If the service supports an idempotency key, it can recognize a repeated request and avoid creating another task. That promise has conditions: the same operation and parameters, within the service's documented scope and retention period. A key saved only in your own database cannot make a remote API deduplicate anything.

After a lost reply, use the service's supported recovery mechanism: look up the original operation, or retry it under its idempotency contract. Check that the returned receipt matches the intended customer and task. A lookup returning no result may still be inconclusive if the original request is running or the lookup lags behind writes. If you can't establish the outcome safely, keep it unresolved and hand it to a person.

This is part of the agent harness: the application code that controls tools, keeps durable state and verifies results. Chat history can help an agent understand the conversation. The service receipt establishes what happened to the task.

Turn the failure into a requirement

“The agent creates follow-up tasks” leaves a lot undecided. A more useful acceptance condition is:

If the service creates a task but its response is lost, restarting the agent must recover the original task without creating a duplicate. An unconfirmed outcome must remain unresolved.

You can define and test the outcome before choosing a model. In a local test service, save the task, then deliberately drop the reply. Restart the worker using its persisted state. Check the service records: one task, the original operation ID, and a receipt that matches the requested change. Repeat with a service that cannot establish the outcome; this time, the expected result is a handoff, not a success message. Repeatable scenarios like this are a starting point for an agent gym, where you can inspect an agent's actions and their consequences before it touches a customer system. Both linked explanations are public.

That is a useful slice of an agent-driven development lifecycle: customer requirement, explicit acceptance condition, implementation, executable check, then release evidence. A coding agent can help implement the recovery path. The check gives its reviewer something concrete to inspect. Passing this fixture proves the behavior of that fixture; the real service's recovery contract still needs integration testing.

Try this in your next design review

Pick one action your agent can take: create a task, send an invitation or update an order. Write down what would prove that it happened. Then ask what survives if the worker stops one line before saving that proof.

---

Keep learning

For a practical next step, build a minimal harness. It opens with a free account. The self-contained Python project compares a loop that accepts a completion claim with one that checks the result. It uses recorded decisions, so you don't need a model API key. This tests the completion check; it is a separate exercise from the lost-reply scenario above.

If the tool boundary is new to you, the Tool / Function Calling concept explains how a model's proposed arguments become an application action. It opens with a free account. The agent explanation and harness lesson linked earlier are public.

For a longer study path, the Autonomous ADLC for FDEs guide connects requirements and specifications to tests, recovery and release decisions. The download is Premium; contents and preview pages are public.

If you're working through an agent design with a colleague, forward this example and compare where each of you would record the outcome. Reading a forwarded copy? The free-account project above is a good place to start.

Thanks for reading,

Team FDE Interviews