A prompt asks for one attempt at an answer. A goal with a completion condition asks the agent to hold an outcome across turns until it is actually true.
For most of the time I've used coding agents, every interaction had the same shape: I say what I want, the agent attempts it, I look at the result, I say what's still wrong, it attempts again. That loop works, and it's the loop most people still use exclusively. But it has a ceiling, because every cycle depends on me being present to notice the gap between what was asked and what happened and to re-describe it.
A goal is a different object. Instead of a request for an attempt, it's an objective plus a condition that defines when the objective is actually met — and the agent is expected to keep working, across as many turns and self-corrections as it takes, until that condition is verifiably true, not until it produces output that sounds like it might be true. The distinction sounds small in the abstract and turns out to be enormous in practice, because it moves the burden of noticing failure off the human and onto the system doing the work.
What changes operationally is where the checking happens. In the prompt loop, I am the check — I read the output, I decide if it's right, I re-prompt if it isn't. In the goal loop, the completion condition is the check, and it has to be something the agent itself can evaluate without me: a test suite passing, a specific file existing with specific content, a URL returning a specific status. If the condition can't be checked mechanically, holding a goal against it just produces an agent that's very confident it's done and just as wrong as before — the goal only helps if the condition is real and checkable, not vibes wearing a formal shape.
The practical benefit shows up on tasks that take longer than one sitting. Work that used to stall the moment I stepped away — because the agent hit a snag, made its best guess, and stopped to ask — now keeps going, because a genuinely open goal treats "I hit a snag" as a problem to route around, not a reason to end the turn. I've had agents resume a goal after a session restart and pick up exactly where the condition said they'd left off, which is not something a prompt has any mechanism to do, because a prompt has no memory of what it was for once the turn that issued it ends.
The failure mode is the mirror image of the prompt loop's failure mode. Where a prompt fails by the human forgetting to re-check, a goal fails by being armed against a condition that's too loose — "make the tests pass" when half the suite is flaky, or "get the feature working" with no operational definition of working at all. A loose goal doesn't make the agent try harder; it makes the agent decide for itself when it's satisfied, which is exactly the authority you meant to keep. Writing a goal well is mostly the discipline of writing a completion condition specific enough that satisfying it and actually being done are the same event, and that discipline turns out to be most of the actual work — the executing-across-turns part takes care of itself once the condition is right.
I don't think goals replace prompts — most of what I do in a day is still a direct ask I want one attempt at, and that's fine, that's what prompts are for. But for anything I want to survive my own attention wandering, a goal with a real, checkable condition is doing something a prompt structurally cannot: it keeps the objective alive as a thing to satisfy, rather than letting it collapse into whatever the first attempt happened to produce.