A goal is not a prompt. A goal is an acceptance contract.
In the past, we wrote prompts, and telling the model "what to do" was enough. Now that agents can do the work, the bar is higher—you have to tell it "how to verify when it's done", "under what circumstances to stop", and "where the boundaries are". A goal without acceptance criteria is a guessing game; a goal without pause conditions will make the agent burn tokens in an infinite loop.
A good task goal keeps the agent working steadily toward the established result across multiple rounds of exploration, stops when the evidence meets the bar, and pauses at decision points to wait for human judgment.
One-off tasks vs persistent goals
| One-off task | Persistent goal | |
|---|---|---|
| Pattern | Request → Work → Result → Wait | Work → Check → Continue or Complete |
| Applicable to | A single well-defined task | Multi-turn exploratory tasks with an uncertain path |
| Completion | Task execution finished | Evidence verifies the goal is achieved |
When to use persistent goals
Should use: Performance optimization, flaky test investigation, dependency migration, bug investigations that need reproduction, multi-step refactoring, benchmark-driven tuning, research tasks that need to produce a final artifact.
Do not use: Single-line changes, brief explanations, code review, one-off Q&A. Slogan-style goals ("make the code better", "refactor it a bit") are also unsuitable.
Applicability conditions:Persistent goal + verifiable completion line + a path requiring multi-turn exploration。
Seven elements
- Outcome: the state that should be true when the work is complete
- Verification: the tests / benchmarks / artifacts / command output that prove the result
- Constraints: the things that must not degrade during the work
- Boundaries: where writing is allowed, where touching is forbidden, the range of available resources
- Iteration policy: how much to change each time, what checks to run after changing, how to choose the next step
- Stop when: what evidence, when it appears, declares the goal achieved
- Pause if: under what circumstances to pause and wait for a human decision (rather than continuing to guess blindly or declaring failure)
Writing template
/goal [期望结果]
Verification: [用什么证明完成了]
Constraints: [不能改什么 / 不能退化什么]
Boundaries: [允许写哪里 / 禁止碰哪里]
Iteration policy: [每次改多少，改完跑什么检查，如何选下一步]
Stop when: [证据证明完成]
Pause if: [什么情况下暂停等人工决策]
The difference between Stop when and Pause if: Stop when is a positive completion signal (all tests green, benchmark meets the bar), while Pause if is a decision point requiring human intervention (discovering that two approaches each have pros and cons, needing confirmation on whether to accept a trade-off, external dependency blocking requiring human action). Don't declare completion as soon as you hit a difficulty—pause when you should pause, complete when you should complete, report a blocker when you should report a blocker.
From weak to strong
Performance optimization
Weak:/goal Improve performance
Strong:
/goal Reduce p95 checkout latency below 120 ms
Verification: checkout benchmark 报告 p95 低于 120ms，且 correctness suite 全绿
Constraints: 不退化 correctness suite 任何测试，不修改公开 API
Boundaries: 仅修改 checkout service、benchmark fixtures 和相关测试
Iteration policy: 每次迭代记录改了什么、benchmark 结果、下一最佳实验方向
Stop when: p95 连续 3 次 benchmark 低于 120ms 且 correctness suite 全绿
Pause if: benchmark 无法运行、或连续 5 次实验无改善、或需要动到公开 API
Key difference: the strong goal names theResult (<120ms), verification method (benchmark), constraints (correctness suite, API), completion signal (meeting the target 3 times in a row), and pause point (5 times with no improvement). Even if latency drops from 180ms to 135ms, the goal is still not complete; if latency meets the target but tests fail, the goal is also not complete; when there is no improvement for consecutive attempts, pause rather than blindly continuing.
Research reproduction
Weak:/goal Reproduce Buehler et al., "Deep Hedging"
Strong:
/goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging"
Verification: 产出分级报告——confirmed（精确复现）/ approximate（近似结果）/ blocked（阻塞项）/ uncertain（不确定项）四层分类
Constraints: 仅使用论文公开材料和本地资源，不做未经证实的结论宣称
Boundaries: 允许使用论文材料、公开数据集、本地计算资源
Iteration policy: 逐一尝试每个 headline 结果，验证输出，记录证据等级
Stop when: 所有 headline 结果分类完毕，报告覆盖四层分级
Pause if: 关键数据不可获取、计算资源不足跑完整实验、论文方法有歧义需判断
Key difference: a strong goal defines the evidence standard (four-tier grading), preventing "seemingly feasible" artifacts from becoming overclaimed conclusions.
Core discipline
- Define acceptance criteria first, then start working. What counts as complete? What evidence can prove it? What signal indicates it is time to stop?
- Goals should be narrow enough to audit, broad enough to explore. "Fix this test" may be too narrow (the problem is in an upstream dependency), while "improve the entire system" is too broad (there is no audit surface).
- Distinguish three stop signals; do not confuse them. Stop when means complete, Pause if means waiting for a person, and only report blocked when there is truly no way forward. Do not use pause to impersonate completion, and do not use completion to impersonate blocked.
- Exhausting the budget ≠ completing the goal. When reaching the token limit, summarize progress and blockers and identify next steps, rather than marking it complete.
Reverse interview: let AI help you converge on requirements
When you are not sure how to write a goal, the most useful technique isto have AI reverse-interview you—you only know what you want to do, and AI helps you ask out all the acceptance criteria, boundary conditions, and pause rules.
Step 1: Submit a vague task and let AI ask follow-up questions
/plan Help me turn this vague task into a strong coding agent goal.
Interview me for missing success criteria, verification commands,
constraints, boundaries, iteration policy, stop conditions, and pause
triggers. Then draft a final /goal ... command.
Or the Chinese version:
/plan 帮我把这个模糊任务转成高质量的 coding agent 目标。
请反问我：验收标准是什么、用什么命令验证、有什么约束不能碰、
边界在哪、迭代策略、什么证据算完成、什么情况要暂停等人。
最后生成一份完整的 /goal 命令。
Step 2: Answer AI's follow-up questions
AI will ask one by one:
- "How many milliseconds exactly is the 'fast' you mean?"
- "What test will be used to verify it?"
- "What must not be changed during performance optimization?"
- "After how many consecutive failures should it pause?"
Step 3: Review the generated goal
Check the tightening tension: are the success conditions measurable? Do the pause conditions cover common sticking points? Are the boundaries clear? Then copy and execute.
This is the engineering standard in the Agent era—requirements are no longer "guess what I want," but "let's write the acceptance contract clearly together."