Long-Running AI Agent Prompts: 12 Practices for Reliable Execution

Long-running agents have moved from “answer a question” to “push a piece of work forward.” Code refactors, source review, multi-step approvals, and cross-system verification can span many rounds of tool calls. On the model side, reasoning is often enabled by default, and outputs tend to be action-oriented rather than conversational. If the prompt still looks like it was written six months ago—repeatedly asking the agent to think, listing vague attitudes, and never defining what “done” means—you are doing work the model can already do while omitting the constraints it actually lacks. The result is usually not smarter answers. It is longer trajectories, more tokens, hesitation at key forks, or the agent stopping to ask for instructions before the task is closed.

The 12 practices below are not private switches for one model. They are a general prompt structure for autonomous agents. The core shift can be summarized in one sentence: manage less of how the agent thinks, and specify more about outcomes, boundaries, evidence, and end states.

1. Write “done” as an acceptance checklist

The most important rule is not to hand over a bare verb phrase. If you tell a coding agent to “migrate authentication to token validation,” it may change the entry point, leave the old implementation in place, skip tests, forget the documentation, and still consider the work complete. Completion criteria should be checkable items: all relevant entry points use the new path; existing tests pass; the new path has coverage; the old implementation is removed or explicitly deprecated; documentation and configuration examples are updated. Pause only for blockers that require a human product decision.

The value of this writing style is that it gives the agent a stopping function. Without a stopping function, it either declares success too early or keeps searching without bounds to be “safer.” The acceptance checklist is also a review aid: a human does not need to reread the entire trajectory, only compare the evidence against the checklist.

2. Do not micromanage reasoning in natural language

Phrases such as “think carefully,” “step by step,” “consider every possibility,” and “do not rush” have low value in systems where reasoning is enabled by default, and their side effects are obvious. They encourage longer internal monologue and more self-checking without stating the goal that checking should serve. Depth should be determined by task difficulty and latency budget, not by stacked adjectives. The prompt should state what reasoning must achieve: find call sites that break compatibility, list uncovered branches, and flag forks that require human decisions. Leave the process to the model and keep the goal with the human.

3. Start with medium effort, then adjust based on results

For long tasks, do not begin by demanding exhaustive search, and do not write “think less” just to save cost. Medium effort suits most refactors, investigations, and documentation syncs: first produce a runnable minimum closed loop, then go deeper based on failure evidence. If results keep cycling through the same class of error, increase effort or narrow the scope. If the work is only formatting, renaming, or adding comments, explicitly request a short path with little exploration. Effort is a resource dial, not a rhetorical style.

4. State scope and non-goals clearly

Agents are most likely to “optimize along the way” in adjacent code. The prompt should include both in-scope and out-of-scope items. In scope might be a specific authentication module, a set of interfaces, or a class of configuration. Out of scope might be billing, large permission-model changes, unrelated dependency upgrades, or UI redesign. The more specific the non-goals, the fewer irrelevant diffs and review noise you get. If small cleanup is allowed, limit it to “changes necessary to pass tests.”

5. Require evidence, not confidence

Telling an agent to “ensure correctness” is almost impossible to execute. Require reviewable materials instead: which files changed, a summary of key diffs, which checks were run, which checks were not run and why, and remaining risks. For research tasks, evidence is the mapping between sources, excerpts, and conclusions, not stronger wording. A completion claim without evidence should be explicitly treated as incomplete in the prompt.

6. Define blockers and ask timing in advance

Autonomy does not mean never asking questions. Limit questions to points that are truly irreversible or under-specified: interface tradeoffs that break compatibility, missing secrets or permissions, conflicting business rules, or unreachable external systems. For everything else, proceed with reasonable defaults, record assumptions, and continue. The question format should also be fixed: one question, two options, their respective impact, and your recommendation. This prevents the agent from pulling the human back into the driver’s seat with an open-ended essay.

7. Set checkpoints for long trajectories

Do not expect one prompt to carry a multi-step workflow from beginning to end. Provide checkpoints by stage: understand the current state, make the minimal change, verify, clean up, and update documentation. State the output of each stage and the conditions for entering the next stage. If something fails, stop and fix it in the current stage; do not carry red checks into a broad refactor. Checkpoints localize failure and make it easier for a human to take over mid-task.

8. Write tool use as policy, not slogans

“Use tools freely” and “use as few tools as possible” are both too coarse. Better instructions are: read before editing; reproduce the failure before patching; avoid meaningless repetition of the same command; perform external search only when local material is insufficient; do not confirm for the sake of confirmation. If the environment has tests, static checks, or preview mechanisms, specify their priority. Policy reduces trial and error better than vague advice to “be efficient.”

9. Constrain output shape for downstream consumption

The reader of a long-running agent is often another person or another automation layer. Specify the structure of the final response: completion status, change summary, verification results, assumptions, and open questions. Intermediate process can be brief, but do not bury the only conclusion inside a long stream of reasoning. If a patch, checklist, or table is required, explain what the fields mean. Structured output lowers handoff cost and helps you judge whether the agent actually checked against the completion criteria.

10. Handle uncertainty and compatibility explicitly

Migration tasks should state compatibility requirements: whether old clients must still work, whether configuration should be dual-read, and whether failures can be rolled back. When uncertain, default to reversible, small-step, observable actions, and write assumptions into the result. Do not let the model invent interfaces, parameters, or performance numbers when evidence is missing. Mark items as pending confirmation rather than writing guesses as facts.

11. Calibrate with failure examples, not attitude words

Instead of saying “be rigorous,” give a counterexample: changing one call site while leaving the old implementation in place is not done; claiming tests passed without running them is not done; deleting an entry point that users still use without explanation is not done. One or two failure examples close to the repository change behavior more than ten vague requirements. Positive examples should also be short: show what “done” looks like, not the writing style you prefer.

12. Treat prompts as versioned operating contracts

A prompt is not one-off copy; it is the agent’s operating contract. Keep it with task templates in the repository: goal, definition of done, scope, evidence, asking rules, and checkpoints. Every time the agent stops early, over-edits, or repeats work, write back a constraint instead of adding a harsher tone in the chat. A shorter contract is often better—remove outdated thought-management sentences and keep the boundaries that still prevent incidents.

A sample structure can be compressed as follows, replacing the bracketed content for each task:

• Goal: Complete a reversible change.
• Done: List four to six checkable items; the task may end only when all are met.
• Scope: Touch only module X; no unrelated upgrades.
• Evidence: Diff summary, checks run, and reasons for checks not run.
• Ask: Stop only for irreversible decisions or missing permissions, and provide options.
• Path: Reproduce first, then make the minimal change, then verify, then clean up.

The problem with the old habit is that it writes prompts as remote control for the thinking process. The new habit writes prompts as acceptance contracts. The model handles reasoning and action; the human defines what done means, where the agent must not cross, what counts as proof, and when it must stop. Rewrite prompts in that order, and long tasks usually become shorter, cheaper, and less likely to hand control back halfway through.