Look at the latest releases of the major coding agents. They all added some variant of /goal or /objective or /plan-first in the last six months. The marketing language for these commands is upbeat — “structured work,” “explicit alignment,” “goal-oriented agents.” The actual reason they exist is less flattering: the agents don’t know when they’re done.
A year ago the pitch was that you would describe a problem and the agent would decompose, plan, execute, and stop. The first part worked. The last part — knowing when to stop — turned out to be the unsolved one. So you got loops. Refactors of refactors. Helper functions for helper functions. Three days of credit burn on what was a thirty-minute task.
Why the goal command is good design
Because it makes the failure mode explicit. The agent will only stop when it can answer “did I do the thing the user asked for?” — and that question requires the user to write the thing down in a stable, referenceable place that the agent can return to. That’s what /goal is. A spec the agent can compare its work against.
If you treat the goal command as a workaround, you’ll skip it and pay for it in tokens. If you treat it as an interface, you’ll start writing better goals — and your reviews of AI work get cheaper too, because you have a contract to compare the diff against.
The bigger pattern
A lot of “agent intelligence” wins of the last two years are actually wins on stop-condition design. Tool-call limits. Iteration caps. Cost ceilings. Required user confirmations. These look like guardrails. They are more like grammar — they let the agent say a sentence instead of a run-on paragraph.
The agent that asks you for a goal isn’t admitting weakness. It’s admitting that the goal is the part that has to come from you, and the rest will follow.