The Always-On Reasoning Era: 12 New Rules for Writing Agent Prompts

1. Why old prompt patterns stop working

If your prompts are still copied from a template written a year ago, a significant portion of those instructions are no longer “useful information” to today’s models—they are noise.

Three changes on the capability side drive this:

• Reasoning is no longer an explicit switch. The new generation of coding models built for long-horizon tasks treat deep reasoning as an always-on capability. You cannot—and don’t need to—switch it on with natural language.
• Per-task execution efficiency is rising. Producing the same deliverable now typically requires fewer round trips and less redundant output, so the defensive, drawn-out instructions written “to keep the model from slacking off” now yield almost nothing.
• Task duration is stretching from seconds to hours. The single-turn conversational style is being replaced by “long-running execution + multiple tool calls + checkpoints,” so a prompt becomes a task contract rather than a question.

This produces three typical side effects of old habits:

1. Instruction redundancy: repeatedly stressing “be careful” and “be thorough” leaves the model unable to distinguish hard constraints from emotional phrasing.
2. Squeezed reasoning budget: combined with “think again, more carefully” style instructions, even short tasks can trigger overly deep chains of thought, showing up as slower and more expensive runs.
3. Missing implicit stop conditions: without defining “what counts as done,” the model tends to wrap up at a node it considers reasonable, or repeatedly patches the same piece of code.

The paradigm shift in one sentence: from micromanaging the process to defining the result, boundaries, evidence, and endpoint.

2. The 12 new rules

Rule 1: Write “done” as verifiable acceptance criteria

This is the most important rule for autonomous agents. Don’t hand down a goal—hand down acceptance criteria.

Compare two approaches:

# Counterexample: only a goal, no endpoint
Migrate the auth system onto the standard authorization protocol.

# Positive example: goal + acceptance criteria + escalation path
Task: migrate service A's authentication system onto an industry-standard
authorization and token framework.
Definition of "done":
  1. Every protected endpoint is validated through the standard authorization
     flow, with no leftover legacy session-validation branches;
  2. All existing unit and integration tests pass, with coverage no lower than
     the pre-migration baseline;
  3. A new set of tests for token issuance, refresh, expiration, and revocation
     is added and passes;
  4. The old implementation's code paths and config entries are deleted, with no
     dangling references in the repo;
  5. API docs and deployment notes are updated accordingly.
When a business decision is needed (e.g., token TTL policy, rollout scope), pause
and check with me. Do not pick an option on your own and continue while that
decision is missing.

Acceptance criteria should meet three traits: observable (judgeable by a command or a test), decidable (no vague wording like “elegant enough”), and exhaustive (covering four facets: code, tests, docs, and config).

Rule 2: Delete the “think more carefully” prompts

In the past, “think step by step” and “consider every possibility deeply” were standard advice. On the new generation of models they are basically empty instructions—reasoning is on by default.

When you genuinely need to adjust reasoning depth, use structural parameters such as an investment (effort) tier, not natural-language persuasion. When you need faster responses, don’t write “think less” as reverse persuasion either—it interferes with the model’s self-assessment of task difficulty. The right approach is to select a lower tier and then use measured results to judge whether it is enough.

The model handles the reasoning; your prompt explains the goal that reasoning should achieve.

Rule 3: Start from the default (medium) tier, then tune by measurement

Treat the tier as a performance knob, not a value statement. An actionable tuning strategy:

Task characteristic	Suggested starting point	Metric to watch	Adjustment
Small single-file edits, formatting, comment completion	Low	First-pass success rate	Bump up only if rework rate >20%
Routine feature development, adding tests	Medium (default)	Acceptance-criteria hit rate	If consistently high, try stepping down
Cross-module refactors, defect localization, architecture decisions	High	Number of human interventions	If no improvement, roll back to avoid overpaying for a difficulty misjudgment

Principle: prove with data that deeper reasoning is needed before you pay for it.

Rule 4: Write fewer steps, more constraints

Specifying “in step one do this, in step two call that tool” means doing the model’s job for it—the thing it does better. Loosen the process and tighten the constraints:

# Counterexample: orchestrating the model's hands
First grep for all references, then edit a.py, then edit b.py, then run pytest.
# Positive example: give constraints and a result
Constraints:
  - Do not change the signatures of the public API;
  - All changes must be revertible (single commit, no formatting noise);
  - You may choose your own retrieval and verification methods, but you must run
    the relevant tests yourself after each change.
Result: deliver a minimal change set that passes all tests, and list the changed files.

Rule 5: Explicit stop conditions and escalation paths

Long-horizon tasks need a dual definition of “when to stop and who to find when stuck,” otherwise you get one of two extremes: infinite patching, or wrapping up too early.

Budget and stop rules:
  - Attempt at most 3 rounds of fixes; if the same failure stays unresolved after
    3 tries, stop and output a diagnostic report;
  - Before any operation that touches production config, permission changes, or
    data deletion, get my confirmation first;
  - If you find the requirement itself is ambiguous, first output no more than 5
    clarifying questions and wait for my answers before acting.

Rule 6: Use a structured output contract instead of a format description

Rather than describing in natural language “return JSON containing these fields,” give the schema definition directly. Example:

{
  "type": "object",
  "required": ["summary", "changed_files", "tests_run", "remaining_risks"],
  "properties": {
    "summary": { "type": "string" },
    "changed_files": { "type": "array", "items": { "type": "string" } },
    "tests_run": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["command", "exit_code"],
        "properties": {
          "command": { "type": "string" },
          "exit_code": { "type": "integer" }
        }
      }
    },
    "remaining_risks": { "type": "array", "items": { "type": "string" } }
  }
}

The value of a structured contract is that it is machine-consumable: failures can be retried automatically, missing fields can be reported precisely, and you no longer have to parse prose.

Rule 7: Give entry points to context, not the full text

Stuffing an entire repo or a whole document into a prompt is both expensive and imprecise. Provide indexes and ways to fetch data instead:

Repository root: /workspace/svc-a
Convention: to understand callers, first read docs/architecture.md and the
contract tests under test/contract/.
Do not assume any interface that does not appear in the repo.

Combined with general-purpose object storage plus retrieval/logging services, you can keep bulky material (historical archives, online log slices) external and let the model pull what it needs on demand, instead of injecting everything up front.

Rule 8: Don’t hardcode tool call sequences

The old style was “call the retrieval tool, then the execution tool, then the browser.” The new generation of models are better at choosing their own methods and loop counts. Give capabilities and permissions, not scripts:

Available tools: code search, file read/write, command execution (non-destructive
commands only), and the unit-test runner.
Selection policy: you decide the call order and count; total tool calls are capped
at 40, beyond which output current progress and the blocking point.

Rule 9: Use executable verification instead of “please check yourself”

“Please carefully check your answer” produces no decidable signal. Turn verification into a real command:

Self-check method:
  1. Run `make lint && make test`; it must end with exit code 0;
  2. Run the contract test suite against the migrated interfaces;
  3. If it fails, you may read the failure output and fix it, up to 3 rounds.
Do not assert "the logic is correct" based only on reading the code.

A verification that runs beats a guarantee that is merely stated.

Rule 10: Require verifiable evidence

The output of long-running tasks must be traceable, otherwise the cost of human review eats up the automation gains. Require the model to produce three kinds of evidence: a change list (file + line range), an execution log (command + exit code), and a decision log (which trade-offs were made and why).

This evidence lands on general-purpose capabilities: logs are written to a logging service, reports are archived to object storage, and key metrics feed into monitoring alerts, making later audits and cost attribution easier.

Rule 11: Explicitly declare boundaries and no-go zones

Negative boundaries beyond the positive requirements are the cheapest way to control risk:

Prohibited:
  - Do not modify any CI config outside of .github/;
  - Do not run commands whose semantics involve deletion, force push, or
    privilege escalation;
  - Do not add new third-party dependencies unless you first explain why in the
    report;
  - Do not modify assertions themselves in order to pass tests.

Rule 12: Govern prompts as code assets

Once a prompt enters production, it needs versioning: check it into the repo, keep a change log, and maintain a regression eval set.

Governance actions include three: deduplication (delete emphasis sentences that repeat other passages), conflict detection (mutually exclusive statements such as “be as fast as possible” and “be thoroughly detailed” must be resolved to one), and regression evaluation (fix 20–50 representative tasks, run them after every prompt change, and record pass rate, average steps, per-task token consumption, and number of human interventions). A prompt change without an eval set is just a guess.

3. The four-step migration method for existing prompts

1. Inventory: classify existing prompts by purpose (generation, review, refactoring, troubleshooting), and measure their length and repeated passages.
2. Reduce: delete all reasoning-persuasion sentences, duplicate format descriptions, and orchestration steps that duplicate the tools being called. In practice this can account for 30%–50% of the original prompt.
3. Rewrite: for each high-frequency prompt, fill in five elements—goal, acceptance criteria, boundaries, evidence requirements, and stop conditions.
4. Evaluate: compare pass rate and cost before and after the rewrite using a fixed task set, then decide whether to ship.

4. Four pitfalls to avoid

• Reading “concise” as “omit the acceptance criteria”: what you delete is fluff, not constraints.
• Forcing a low tier onto a complex task: you don’t actually save money, and the multiple rounds of rework make the total cost higher.
• Leaving security boundaries to the model’s discretion: permissions and dangerous operations must be limited on both the prompt side and the runtime-environment side.
• Changing the prompt without changing the evaluation: a refactor whose gains can’t be quantified usually gets reverted within two weeks.

5. Conclusion

Behind these 12 rules is the same shift: the stronger the model, the more humans should focus on defining “what counts as correct” rather than instructing “how to do it.” Write the completion criteria, boundaries, evidence, and endpoint clearly; delete reasoning-persuasion and step orchestration; and bring prompts into a versioning and evaluation system—do these four things solidly, and long-horizon agents become truly controllable, auditable, and reproducible. Whether you build your own agent pipeline or use the model services and agent development capabilities offered by cloud platforms such as Baidu AI Cloud, the same rules apply: define the endpoint first, then let it act.