When to use this method

Use a long-horizon brief when an agent will work unattended for an extended period, coordinate parallel workers, or search through a problem where a plausible partial answer is easy to mistake for completion.

Do not use it to solve topology, runtime, or evaluator design. Those belong to multi-agent architecture, harness engineering, and evaluation. The brief owns the words that steer the run.

1. Write the success predicate first

State one condition over the returned artifact that an adversarial reader can evaluate. Include scope, quantifiers, units, populations, and boundary cases.

Weak

Improve the model and report what worked.

Specified

Produce one precommitted candidate whose paired five-seed confidence interval is strictly above the frozen baseline, with the evaluator unchanged and an independent leakage audit passed.

If the predicate cannot be stated without words such as “good,” “thorough,” or “convincing,” the task needs a scoping run before it needs a long autonomous run.

2. Name the results that do not count

The highest-leverage question is: what would a capable agent return under pressure instead of the requested result?

  • A special case when the task requires the general case.
  • A reduction to an assumption as hard as the original goal.
  • A lucky benchmark run without repeated evaluation.
  • A hypothesis, survey, plan, or status report instead of an artifact.
  • A candidate counterexample without a complete certificate.
  • An approximate result where exact satisfaction was requested.

Write the domain-specific refusal list, not a generic “partial progress does not count.” Every unnamed near miss remains an escape hatch.

3. Pair persistence with verification

Persistence pressure against a loose acceptance condition increases the reward-hacking surface. Every instruction to continue must be paired with a gate that checks the resulting artifact.

  • Use fresh-context reviewers who did not build the candidate.
  • Give reviewers concrete attack categories, not “check the work.”
  • Require modular outputs with local premises and conclusions.
  • Trace every completion claim to a file, run, log span, diff, or proof step.
  • Treat inter-agent agreement as weak evidence when workers share priors.

4. Preserve diversity in parallel search

Role labels do not create independent reasoning. Workers converge unless the orchestration policy preserves different mechanisms.

  1. Keep early workers blind to the favored route.
  2. Maintain an approach registry grouped by underlying idea, not wording.
  3. Mark a route blocked when its remaining gap is as hard as the target.
  4. Reopen blocked routes only for a materially new mechanism.
  5. Cross-pollinate after independent routes expose their real premises and gaps.

Every worker assignment needs an objective, output format, tool/source guidance, and explicit boundaries.

5. Move hard constraints into the harness

Prompt ownsDefinitions, scope, non-solutions, evidence contract, orchestration policy, return rule.
Harness ownsBudgets, permissions, network allowlists, evaluator immutability, state reinjection, sandboxing, rollback.
Evaluator ownsHeld-out checks, deterministic gates, fresh review, acceptance evidence.
Human ownsChanging the evaluator, expanding editable surfaces, production promotion, destructive actions.

Prompt-stated constraints are advisory under optimization pressure. If a rule must survive, enforce it outside every surface the agent can change.

6. The writing workflow

  1. PredicateWrite one exact completion condition.
  2. Refusal listEnumerate the likely answer-shaped near misses.
  3. DefinitionsClose ambiguities and degenerate cases.
  4. AuditList how a candidate can look correct while being wrong.
  5. Search policyPreserve independent routes and blocked-route state.
  6. EvidenceSpecify concrete artifacts and claim traceability.
  7. Return ruleGate return on the artifact, with fallback only on external budget exhaustion.
  8. Red-teamAsk how the letter can be satisfied without the intent; patch every credible answer.

Copyable task-brief skeleton

Delete blocks that do not apply. Replace every bracketed field before launch.

DEFINITIONS

[Define every load-bearing term, unit, scope boundary, and degenerate case.]

TASK

[State one exact success predicate over the returned artifact.]

SOLVABILITY

[If a complete solution plausibly exists, state that assumption. If existence is
uncertain, allow either a complete solution or a complete impossibility certificate.]

RESULTS THAT DO NOT COUNT

- [Narrowed scope or special case]
- [Reduction to an unvalidated assumption]
- [Bounded or anecdotal verification]
- [Plan, survey, or status report instead of the artifact]
- [Domain-specific near misses]

ORCHESTRATION (only for parallel runs)

Preserve early independence. Maintain an approach registry grouped by mechanism.
Mark goal-strength gaps blocked; reopen only for a materially new mechanism.
Cross-pollinate after surviving routes have exposed their premises and exact gaps.

VERIFICATION

Use fresh-context reviewers. Check every candidate for:
- [Domain-specific confounder]
- [Boundary or degenerate case]
- [Circularity or equivalent-assumption failure]
- [Leakage, metric gaming, or too-good-to-be-true signature]

REPORTING CONTRACT

Require [concrete artifacts]. Every completion claim must trace to session evidence.

RETURN CONDITION

Return only when the artifact satisfies TASK and survives VERIFICATION.
If the external budget ends first, label the result INCOMPLETE and state the exact gap.

EFFORT

[State the evidence or materially distinct approaches required before declaring the
search blocked. The runtime, not this prompt, enforces the actual time/cost budget.]

CONTAMINATION

[Define which external sources are permitted and what target answers, labels, hidden
tests, or benchmark solutions must not be retrieved.]

HARNESS BOUNDARIES

The runtime, not this prompt, enforces [budgets, permissions, evaluator locks, sandbox].

Pre-launch checklist

  1. Success predicateCan an adversarial reader decide unambiguously whether an artifact passes?
  2. DefinitionsAre load-bearing terms and boundary cases settled?
  3. Non-counting outcomesAre the likely near misses excluded by name?
  4. Auditor checklistDoes it contain domain-specific failure modes and circularity?
  5. Persistence pairingDoes every continue instruction have a verification gate?
  6. Return conditionIs return a predicate over the artifact rather than confidence?
  7. Diversity policyFor parallel runs: independence, registry, blocked routes, late exchange?
  8. Evidence contractAre concrete artifacts required and claims traceable?
  9. ContaminationIs the allowed retrieval scope explicit?
  10. Harness separationAre hard budgets and permissions enforced outside the prompt?

This is a structural self-assessment, not an outcome predictor. Passing it does not prove that the agent can solve the task.

Common gotchas

Persistence without verification
The agent optimizes the leniency in the acceptance condition.
Unanimity as corroboration
Shared priors can make agreement a diversity-collapse signal.
Fallback at agent discretion
“Return the best partial result” becomes the main escape hatch. Scope it to an external stop only.
Assume-solvable on an ill-posed task
The agent is discouraged from reaching the truthful conclusion that the premise is wrong.
Prompt-stated budgets
One-time reminders decay across a long trajectory; enforce and reinject budget state from the harness.
Over-prescription
Current models often perform worse under accumulated step-by-step instruction stacks. Specify outcomes and gates; leave the path open.