Goals, Planning & Termination

Goals vs tasks vs actions: three levels, don't conflate them.

Sloppy thinking here causes a specific, common failure, so pin the vocabulary down:

• Goal — the outcome the user actually wants, often fuzzy and stated in English. "Make sure our docs don't reference the deprecated API." Success is a state of the world, not a step.
• Task — a concrete sub-objective the agent decomposes the goal into. "Find every file mentioning v1"; "decide which mentions are stale"; "fix or report them."
• Action — a single tool call. search_files("v1"). The atomic unit the loop executes.

The common failure: an agent that optimizes the action or task level and loses the goal. It diligently runs searches, opens files, edits things — every action locally sensible — and finishes having technically "done tasks" while the user's actual goal is unmet (it fixed the docs but broke a code sample; it answered the literal question but not the intended one). Keeping the goal explicit and re-checked is the antidote, and it's why the best agents periodically re-ask "does what I'm doing still serve the original goal?"

The planning spectrum.

"Does the agent plan?" is not yes/no. There's a spectrum, and the right point depends on the task's predictability:

REACTIVE  ───────────────────────────────────►  DELIBERATIVE
(no explicit plan)                          (full plan up front)

│ Pure ReAct        │ Plan-then-execute  │ Hierarchical
│ decide one step,  │ write a plan, then │ plan goals → tasks →
│ act, observe,     │ execute it step by │ replan a subtree when
│ decide again.     │ step, replan if    │ a task fails; keep the
│ No stored plan.   │ blocked.           │ rest of the plan.
│                   │                    │
│ Best when each    │ Best when the      │ Best for long, multi-
│ step's result     │ steps are roughly  │ stage tasks where a
│ genuinely changes │ knowable up front  │ late failure shouldn't
│ what to do next.  │ and order matters. │ discard everything.

The reactive end (the ReAct pattern: interleave Reasoning and Acting, one step at a time) is the simplest and the default for short tasks — it needs no plan because each observation directly informs the next move. The deliberative end writes an explicit plan first. Plans help for one concrete reason: they keep the goal in front of the model. A written plan in context is a standing reminder that resists the goal drift from Step 1. Plans hurt when the environment is unpredictable enough that the plan is wrong by step two and the model wastes effort defending a dead plan instead of adapting.

Termination: the genuinely hard problem.

Here is the asymmetry nobody warns newcomers about. Deciding the next action is something LLMs are good at — there's usually a reasonable next step and the model can find it. Deciding "I am done, and I should stop now" is something LLMs are systematically bad at, for a structural reason: the model is a next-token predictor, and "produce another helpful action" is almost always a more probable continuation than "declare completion and stop." The model's training pulls toward continuing. Left to its own judgment, an agent's two natural failure modes are stopping too early (declaring victory on a half-done goal because a plausible-looking answer is available) and never stopping (always finding one more thing to check).

A robust agent therefore never trusts the model alone to decide termination. It combines:

• An explicit completion definition — ideally checkable, not vibes. "Done" = "all v1 references are either removed or annotated as intentional, verified by a re-scan returning zero un-annotated hits." A success criterion the agent (or the harness) can test beats "the model thinks it's finished."
• A verification step — before declaring done, the agent re-checks its own work against the criterion, ideally with a read action that observes the actual end state rather than assuming its writes succeeded.
• Hard budgets — the step / token / time / money caps from the agent-loop entry. These are not the primary stop condition; they are the backstop for when the first two fail, which they will.
• An escalation exit — "if I cannot satisfy the criterion within budget, stop and hand back to a human with what I found." A clean give-up is a successful termination; thrashing until the budget burns is not.

Putting it together: a well-formed agent task.

Everything in this section converges on a checklist. A task is ready to hand to an agent when you can fill in all of these — and the act of trying to fill them in is itself the best test of whether an agent is even the right tool:

• Goal — stated as a desired end state, not a procedure. ("The inbox has no unanswered billing emails older than 24h," not "answer emails.")
• Tools — the minimal read and write actions the goal requires, with write actions scoped and rate-limited in code.
• Completion criterion — a checkable definition of done, and ideally a verification action that observes it.
• Budgets — explicit step, token, time, and cost ceilings, sized from observed traces, not guessed.
• Escalation path — what the agent does when it can't finish: who it hands to, with what context.
• Autonomy level per write action — from the autonomy ladder: which writes run free, which need approval.

If you can fill in all six, you have a well-formed agent task and the rest is engineering. If you find you cannot write a checkable completion criterion, or the goal isn't really a state, or every write action needs approval anyway — that is not a gap in your spec, it is the task telling you it wants a workflow, a chatbot, or a human. The next entry, "when to use an agent (and when not to)," is this realization turned into a decision procedure.