12 Prompt Rules for Long-Running AI Agents

Why Prompt Design for Long-Running Agents Is Changing

For agent models that run long tasks, the focus of prompt design is moving from “control how the model thinks” to “define what counts as done.” Developers used to fill prompts with instructions such as “think carefully,” “analyze step by step,” and “consider every possibility,” trying to micromanage reasoning in natural language. In newer models, reasoning is often on by default, and platforms also expose settings for reasoning effort, tool use, and stage checks. Stacking more process instructions often does not improve quality. It tends to create three problems: higher token use, slower responses, and agents that stop before the task is actually finished.

Prompt design should therefore center on four ideas: outcomes, boundaries, evidence, and endpoints. A prompt is no longer a remote control for thinking. It is a task contract, an acceptance standard, and a governance interface. The 12 rules below are a practical reference for prompts used with long-running agents.

Twelve New Rules

1. Define “done” in a verifiable way

The most important rule for an autonomous agent is to write “done” as a checklist that can be verified, not as a vague task statement. Do not only say “migrate the authentication system to a unified authentication protocol.” State the completion criteria: every authentication endpoint uses the unified protocol; existing tests all pass; new authentication flows have test coverage; the old authentication implementation has been removed; related documentation has been updated; and the agent pauses to ask only when a blocker truly requires a human decision.

This lets the model break the task into checkable items and look for evidence after each one. Without a definition of done, an agent can mistake “the code was changed” for “the task is finished.” With an acceptance checklist, the system can judge delivery from tests, diffs, logs, and documentation status.

2. Stop micromanaging the model’s thinking

Instructions such as “think carefully,” “reason step by step,” and “consider every possibility” may have helped older models, but they are often unnecessary when reasoning is enabled by default. Natural language cannot precisely control reasoning depth, and excessive demands can produce long, low-value process descriptions.

A better approach is to leave reasoning depth to the platform’s reasoning-effort setting. The prompt should only describe what reasoning is for, such as “identify risks,” “verify evidence,” “list blockers,” or “compare the tradeoffs of two options.” If you want faster responses, do not write “think less.” Adjust the effort setting, and measure success rate, latency, token use, and the rate of human intervention.

3. Start at medium effort and tune from results

Long-running agents should not default to the highest reasoning effort. Medium effort usually balances quality, speed, and cost, and it fits most coding, knowledge work, and multi-step workflows. Lower effort for format conversion, simple retrieval, and fixed-template filling. Raise effort gradually for high-uncertainty work such as architecture migration, complex research, and cross-module debugging.

Set a baseline before tuning: task completion rate, test pass rate, average latency, token use, number of human interventions, and failed retries. Change one variable at a time instead of rewriting the prompt by feel. Higher effort is not automatically better. It should match task risk and the cost of verification.

4. State boundaries and what must not be done

The more autonomous the agent, the clearer its boundaries must be. The prompt should define the allowed change scope, forbidden actions, permission limits, data sensitivity, external-dependency constraints, and rollback requirements. For example: only the authentication module may be changed; the database schema must not change; no new external service may be introduced; every change must be reversible; and sensitive data unrelated to the task must not be read.

Boundaries do not weaken autonomy. They shrink useless exploration. On a long task, a model may widen its edits in order to “finish the goal,” which adds risk. Saying what not to do is as important as saying what to do.

5. Require an evidence chain and a verification loop

Every completed item needs matching evidence. Ask the model for structured evidence: the completed item, the verification method, the result, where the evidence lives, and remaining risk. “Existing tests pass” should include a test-result summary. “The old implementation was removed” should include a diff or search result. “Documentation was updated” should point to the relevant section. Without evidence, the agent must not claim completion.

An evidence chain sharply reduces “hallucinated completion.” For a long-running agent, acceptance should not rest on the model’s own statement. It should rest on outputs that can be reviewed. Stable evidence formats also make later automated audits and regression checks easier.

6. Define when to pause and how to ask

Long tasks need an explicit pause policy. Common blockers include a product decision, insufficient permissions, repeated test failures, a budget about to be exceeded, a data conflict that cannot be resolved automatically, and an unavailable external dependency. The prompt should tell the model to pause only when it is truly blocked, and to explain the problem, what it already tried, the options, and the decision it needs from a person—all at once.

Without pause conditions, the agent may ask too often and lose efficiency. Without an escalation path, it may make high-risk decisions on its own. A clear escalation path lets autonomy and control coexist.

7. Use structured context instead of redundant instructions

Organize the prompt in sections: goal, background, constraints, definition of done, available tools, output format, pause conditions, and budget limits. Provide only necessary context. Drop low-information lines such as “you are an expert” and “please be careful.” A long context is not a high-quality context. Redundant text dilutes the constraints that matter.

A structured template can look like this:

task: Migrate the authentication module to a unified authentication protocol
definition_of_done:
  - All authentication endpoints use the unified authentication protocol
  - Existing tests pass
  - New flows have test coverage
  - The old implementation is removed
  - Documentation is updated
boundaries:
  - Do not change the database schema
  - Do not introduce new external services
  - All changes must be reversible
evidence:
  - Attach a verification method and result for each completion item
pause_conditions:
  - A product decision or additional permission is required
  - Verification fails twice in a row
output:
  - Change summary
  - Evidence list
  - Risks and follow-ups

8. Work in stages without removing autonomy

A long task can be split into discovery, planning, implementation, verification, and delivery, with an output and a checkpoint for each stage. Stage structure should not become a sequence of step-by-step commands. State the stage goal, the stage gate, and the deliverable, and let the model choose the concrete steps.

Stage gates are for quality control. Examples: the planning stage must list risks and map them to acceptance criteria; during implementation, run the relevant checks after each sub-item; at delivery, summarize evidence and remaining risk. This keeps a long task from drifting without taking away local autonomy.

9. Constrain behavior with tools and observability

Agent behavior should be bounded by tool permissions and observability. The prompt can require the model to read relevant files before important edits, run verification after changes, cap retries when a tool call fails, and emit a status summary at the end of each turn. On the system side, record the tool-call trace, duration, failure reason, and key outputs for audit and regression.

Observability is not a later patch. It is part of the prompt contract. When the model knows that key actions will be logged and checked, it is more likely to produce reviewable evidence instead of a vague conclusion.

10. Require an auditable decision record

Ask for a short decision log, not a long chain of thought. The log should include the goal, key assumptions, the chosen option, evidence, risks, and follow-ups. For example: “Chose option A because existing test coverage is more complete; the risk is compatibility of the old interface; the follow-up is to add a compatibility test.” This summary is easier for people to review and for later debugging, and it avoids unnecessary process detail.

Decision records should line up with the definition of done. Every high-risk decision should have evidence or be explicitly marked as an assumption so it can be checked later.

11. Set budgets for tokens, time, and tool calls

Long-running agents need budget limits. The prompt should state the maximum number of turns, the maximum number of tool calls, a time budget, a token budget, and a cost threshold. When a threshold is reached, the model should first summarize progress, evidence, and remaining risk, then ask whether to continue. The point of a budget is not to make the model “think less.” It is to bound exploration and stop unbounded retries.

Set budgets by stage: allow some retrieval during discovery, limit repeated verification during implementation, and focus delivery on organizing evidence. Combined with the reasoning-effort setting, this produces a more stable balance of quality and cost.

12. Version prompts and run regression evaluation

Treat prompts like code: version numbers, change history, an evaluation set, metrics, and a rollback plan. Every prompt change or model-configuration switch should run a regression evaluation that compares completion rate, test pass rate, human-intervention rate, average latency, token use, and failure types. For critical tasks, use a small-traffic comparison to confirm that the new prompt does not introduce regressions such as stopping early, editing too widely, or missing evidence.

Parameterize the prompt template so the goal, definition of done, boundaries, and evidence requirements stay separate and are easier to reuse and audit. Only prompt versions that pass evaluation should go to production.

How to Put This into Practice

The point of these 12 rules is not a longer prompt. It is a better contract. Teams can adopt them in this order: first, build a definition-of-done template for each task type; second, remove process-style thinking instructions and use reasoning effort plus outcome standards instead; third, add boundaries, evidence, and pause conditions; fourth, connect general observability such as logs and monitoring alerts; fifth, version prompts and run regression evaluation.

The advantage of a long-running agent depends on balancing autonomy and control. Upgrading the prompt from “control of thinking” to a “task contract” lets the agent deliver more reliably across coding, research, knowledge work, and multi-step workflows, while cost, quality, and risk stay measurable, auditable, and open to improvement.