When the agent times out, don't start over

There is an error message you start seeing when you work with large models long enough:

LLM request failed.
Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config.

What this really means: the agent was doing something, took too long, and the conversation broke.

The instinct is to paste the whole task again. Start from the top. Re-explain the goal, the context, the constraints, the last thing you remember.

That is usually the wrong move.

You waste time. You rebuild the story by hand. And if the agent was in the middle of real work, you can accidentally make it repeat a step that should not be repeated.

The better prompt is shorter:

Where did you leave off? Continue from the last step before the collapse.

That sentence changes the job. You are not asking for a fresh answer. You are asking for continuity.

A timeout is not always a reset

When an agent is only chatting, a timeout is irritating. When an agent is working, a timeout is operational.

A working agent leaves traces. It may have checked logs, read files, changed a draft, started a command, ruled out one hypothesis, or reached a point where the next safe action depends on the exact state of the system.

If you restart the task from zero, you throw away that trail.

Sometimes that is harmless. Sometimes it is not.

The right recovery move is to force the agent to reconstruct the cut point:

Tell me what you already checked, what you changed, what still needs verification, and continue from there.

That prompt does two useful things. First, it asks for a status report. Second, it makes the next action depend on evidence instead of vibes.

Make the agent prove its place

A good continuation should sound boring. That is a feature.

It should be able to say:

  • this was already done;
  • this was in progress;
  • this was the last observed error;
  • this is the next safe step;
  • this is the verification still missing.

If the agent cannot say that, it should inspect the current state before touching anything.

This is the part people skip. They treat the model like it has perfect memory of the interrupted run. It does not. The model may have context, summaries, logs, or partial state. It may also have nothing useful. The agent has to check.

The phrase "continue from there" is not magic. The magic is in pairing it with evidence.

Increasing the timeout is not the whole fix

The error message suggests increasing agents.defaults.timeoutSeconds. Sometimes that is the right move. A long-running task may need more time.

But more timeout is just more rope.

If the workflow cannot recover after a timeout, a longer timeout only delays the failure. The useful improvement is not just technical. It is procedural:

  • leave checkpoints;
  • write down what changed;
  • verify before saying done;
  • resume from the last proven state.

That is how you turn a failed request into a pause.

The recovery prompt

The prompt I want close at hand is this:

You timed out. Reconstruct the last step before the collapse. Tell me what was already verified, what was changed, what remains uncertain, and continue from the next safe action.

It is not fancy. It does not flatter the model. It does not ask for a heroic comeback.

It asks the agent to behave like someone returning to a half-finished job.

Because that is the real skill here. Models will time out. Tools will hang. Context will get compacted. A process will fail halfway through something useful.

The question is whether the workflow survives the break.

If the agent can recover the last safe point and keep going, you have a system.

If it cannot, you had a long conversation and a bit of luck.

← Back to Blog