How to Keep a Coding Agent On Task for Hours

Quick answer
Long agent runs work when the task is narrow, the verification is automated, and progress is committed at checkpoints.
Write the plan to a file the agent can read, so compaction does not erase the objective.
Commit after each verified step, so a failed attempt costs one step instead of the whole run.
State the stop condition explicitly: which tests pass, which files are untouched, and what counts as blocked.
Set a token or time budget, because an agent with no limit will keep trying approaches after the point where a human would stop.

What makes a task suitable for a long run?

A narrow scope, a fast automated check, and no irreversible actions. Refactors, test backfills, dependency upgrades with a lockfile, and mechanical migrations fit. “Improve the codebase” does not, because there is no point at which it is done.

The check is the key property. If the agent can run a command that tells it whether the last step worked, it can iterate. If correctness requires a human to look at a page, the run will drift toward whatever is easy to observe.

How do you structure the run?

Write the plan to a file, then work step by step: implement, verify, commit with a specific message, update the plan file. The agent rereads the plan after compaction, and you get a history you can bisect if the result is wrong.

Keep the working tree clean between steps. A long run that accumulates uncommitted changes has no safe rollback point, and a failure late in the run forces a review of everything at once.

# Run plan: upgrade the test runner

1. [ ] Update the dev dependency and lockfile
2. [ ] Run the full suite, record failures
3. [ ] Fix config-only failures
4. [ ] Stop and report any behavioural failure

Done when: npm test exits 0 and package-lock.json is committed.
Do not touch: src/, migrations/.
Budget: stop after 45 minutes and report progress.

How do you stop it from expanding the task?

Name what is out of scope, in the same place as the plan. Agents add value: they fix an unrelated bug they noticed, refactor a function they had to change, or update a dependency. Each diversion makes the diff harder to review and the run harder to evaluate.

Give it a way to report instead of act. “If you find an unrelated issue, append it to NOTES.md and continue” converts a distraction into an artefact you can triage later.

How do you know when to intervene?

Watch for repeated attempts at the same failure, a plan file that stops changing, or a diff that grows without a passing test. Those are the signals that the loop has stopped converging.

Intervene with a steer if the direction is right, and stop the run if it is not. The cost of a stopped run is the work since the last commit; the cost of an unattended bad run is a review of everything it touched.

Where this bites vibecoders
A generated “long task” prompt usually says to keep going until the feature is complete, which is an instruction to expand scope. Replace it with a checklist that has a terminal state and a list of files the agent must not touch.

Where AI coding assistants get this wrong

Giving the agent a goal with no definition of done.
Letting uncommitted changes pile up across many steps.
Skipping the plan file, so compaction erases the objective.
Allowing the agent to fix every unrelated issue it notices.
Running without a time or token budget.
Leaving the run unattended with production credentials available.

Checklist

Write the plan to a file before starting.
Define the verification command and the done condition.
List the files and directories that are off limits.
Commit after every verified step.
Set a time or token budget and a reporting point.
Review the run’s diff before merging anything.

FAQ

How long can an agent realistically run unattended?

It depends on the harness and the task, but the limit is usually the task’s clarity rather than the clock. A narrow task with a fast test can run for a long time; a vague one drifts within minutes. Start with short runs and extend only when the check is reliable.

Should the agent commit its own work?

For long runs, yes, with a clear message per step. It gives you rollback points and a readable history. The risk is noise, so require a message convention and squash before merging if the project prefers a single commit.

What if the plan file and the code disagree?

Stop and reconcile. Either the plan is stale and should be updated with the decision that changed, or the code drifted from the intent. Continuing with both in place guarantees a confusing diff.

Does a monitor help?

Some harnesses now expose a monitor view or telemetry for a running agent, which helps you see progress without reading every message. It does not replace a stop condition; watching a run that has no definition of done only tells you it is still running.