How to Resume an AI Agent Task After It Stops

An agent stops mid-task for one of four reasons, and the right way to resume depends entirely on which one it was. It hit a context limit. It hit a tool or permission error. It finished what it thought you asked. Or it stalled, looping on the same failing step. Typing "continue" works for exactly one of those four, and makes two of them worse.

So the first move on resuming an AI agent task is not resuming. It is reading the last thing it did.

Work out which stop you are looking at

Check in this order, since the diagnosis is usually visible in under a minute.

The expensive mistake is treating context exhaustion as a stall, or a stall as context exhaustion. One wants a fresh start with a clean brief. The other wants a different plan.

Context exhaustion: hand over, do not continue

This is the most common stop on a long task, and "continue" is the worst available response to it. The agent has lost the early part of the session, so it continues from a partial picture and produces work that contradicts decisions it no longer remembers making.

Treat it as a handover between two engineers. Before you start a new session, write the state down, from the repository rather than from the agent's summary.

TASK: Migrate the billing module from Stripe's v1 to v2 API.

DONE (verified in the diff, not claimed):
- src/billing/client.ts    v2 client, tested
- src/billing/webhook.ts   signature verification updated
- test/billing.test.ts     4 new cases, all passing

NOT DONE:
- src/billing/invoice.ts   still calls v1 createInvoice
- src/billing/refund.ts    untouched

DECISIONS ALREADY MADE (do not revisit):
- Keep the v1 types as aliases rather than renaming call sites
- Idempotency keys stay as they are, out of scope

CONSTRAINTS:
- Do not modify any existing test
- Run `npm test -- billing` after each file

NEXT: invoice.ts only. Stop and report before touching refund.ts.

Four sections, and the one that saves the most time is the decisions list. Without it, a fresh session re-litigates choices you already made, which is the signature of a bad resume: work that is not wrong but is not what the previous session was building. Assembling this from git diff rather than from the agent's last message is the discipline that matters, for the reasons in how to tell if an agent finished the task.

If this is happening repeatedly, the task is too large for one session. Prevention lives in keeping an agent from losing context and splitting a big task properly.

Tool failures: fix the world, then re-issue one step

Here resuming is legitimate and simple, as long as you repair the cause first.

A missing binary, an expired token, a sandbox blocking a host, a command that needs a flag it was not given. The agent is not confused; its environment is wrong. Fix the environment, then re-issue the single step that failed rather than the whole task.

One caution: check what it did in response to the failure before you fix anything. Agents sometimes route around a blocked tool in ways you would not sanction, such as writing a file directly instead of using the migration command, or stubbing a function it could not test. Read the diff for the period after the error, not just before it.

Stalls: stop, change the approach

Three attempts at the same thing with the same result is not a pause. It is a signal that the plan is wrong, and resuming is the one thing guaranteed not to help.

Stalls have a few recognisable shapes:

• Fixing a test by changing the test, failing, changing it back.

• Re-reading the same files looking for something that is not there.

• Alternating between two fixes, each breaking what the other fixed.

• Rebuilding repeatedly against an error from a stale artefact.

In every case the useful intervention is information, not encouragement. Give it the piece it is missing: the actual error text from your own run, the file it has not read, the constraint it is violating without knowing. Then restate the task more narrowly. If you cannot name what it is missing, you have the answer about who should do the next step.

Premature completion: name the gap with evidence

It said done. It is not done. Resume by being specific in a way that cannot be misread.

Not: "that's not finished".

Instead: "src/billing/refund.ts is unchanged and still calls v1.refunds.create. Update it to v2, do not modify any test, and report the diff for that file alone."

Naming the file, the symbol and the constraint produces a bounded second attempt. Vague dissatisfaction produces a broad one, which is how a small gap becomes a large diff.

Checkpoint so you can resume an AI agent task cheaply

Most of the pain in resuming is pain you can prevent at the start.

1. Commit before the agent starts. A clean base turns "what did it change" into one command and makes abandonment free.

2. Commit at milestones during long tasks. Even throwaway commits. They are the checkpoints you resume from.

3. Ask for a stop-and-report between phases. "Do invoice.ts, then stop" beats discovering six files in that phase two went wrong.

4. Keep standing constraints in a file. Repository conventions belong in AGENTS.md, not in a prompt you retype at every resume.

5. Write the handover before you need it. On any task over about twenty minutes, keep a running done-and-not-done list. It costs a minute and converts a context-limit stop from a setback into a paragraph.

A task that cannot survive being stopped and resumed is a task that was scoped too big. The fix is upstream, and some of it is in the tool itself: see how to pick among AI coding tools for which ones checkpoint well.

Frequently asked questions

Does "continue" ever work?

Yes, for a clean tool failure you have fixed, and for a stop between phases that you asked for. For context exhaustion and for stalls it reliably makes things worse.

Should I start a new session or keep the old one?

New session for context exhaustion, since the old one's problem is its full context. Same session for a fixed tool error or an agreed pause, where the context is an asset.

How do I know what it finished, if I cannot trust the summary?

From the repository. git diff --stat, which git documents as generating a diffstat summary, plus your own test run and the test diff. Build the handover from those three and the summary becomes a convenience rather than a source.

What if resuming keeps producing conflicting work?

You are almost certainly missing the decisions section in your handover. A fresh session will re-decide anything you leave unstated, correctly by its own lights and wrongly for your codebase.

Can I avoid this by using a bigger context window?

It raises the ceiling and does not remove it, and long contexts bring their own accuracy cost, as in the lost in the middle problem. Checkpointing scales better than context does.