When a task stalls or fails

Last updated: 2026-09-22

Short answer: first work out which state it's in — running, waiting for you, or already dead. From the outside all three look like "stopped", and each calls for the opposite response.

Telling the three apart

Running: something is moving

There's one test: is new output appearing, or is the elapsed time still advancing. If so, it's working. Some tasks go quiet for minutes at a time — reading a large file, running a test suite, waiting on an external service — and that is not a stall.

Waiting for you: it needs one answer

Here it has genuinely stopped, on purpose — it hit an action it isn't allowed to decide alone and left the question hanging.

The typical case is a one-line confirmation: "delete this file?", "run this command?". You answer, it continues.

Which actions get held, and how to configure that so it isn't annoying, is in what the approval gate is for.

If you can't tell what it's waiting for, look for a pending or awaiting-confirmation item — a task waiting on you generally does not time out and vanish; it stays.

Dead: nothing moving, nothing waiting

No new output, nothing in any pending list, and that state has lasted clearly longer than this task should take. Treat it as dead.

The first step is not to retry — it's to find out how far it got. See below.

One thing to establish before retrying

A task that stopped may have already completed part of the work, and that part may have side effects: files changed, an email sent, an order placed.

Retrying from the top means doing it again. Best case you waste the time; worst case the same thing happens twice.

So the order is:

1. Keep the previous output and log — they tell you where it stopped.
2. Check the outside state: what does that file contain now? did that record get written?
3. Then decide: rerun the whole task, or resume from where it stopped.

If the task is idempotent — running it twice lands in the same place as running it once — a retry is cheap. If it "sends another" or "buys another", establish the state first.

Failing versus stalling

Failure usually announces itself: an error, some output. Those are the easy ones, because you have a lead.

The hard ones are silent failures — no error anywhere in the run, and a conclusion that looks complete while one of the steps never happened. For those, look at whether tools were actually called and whether results had content, not at whether anything errored. The tests are in checking that it actually finished.

When to stop retrying

If the same task halts at the same point two or three runs in a row, luck is not the variable:

• What it needs doesn't exist — a filename typed wrong, a model that isn't there, an account without permission.
• The environment doesn't satisfy it — a dependency missing, the wrong version.
• The task itself is vague — it always reaches the same place before needing information from you.

In those cases another retry just repeats the failure. Take the error it stopped on and look it up, or rewrite the task description before dispatching again.

Next

• Checking that it actually finished — three kinds of silent false success
• What the approval gate is for — which actions get held
• Splitting work across agents — what parallelises cleanly