Scoping a Task for an Agent

"Improve error handling in the payment module." You launch it, go grab a coffee, and come back to a 600-line diff: the agent wrapped fourteen calls in try/except, created a hierarchy of five custom exception classes, added a retry library, and changed the log format. Nothing is wrong line by line. Nothing is usable either, because you can neither accept nor reject the whole: there is no criterion that says it's finished and successful. You throw it away, having paid the full price of generation and review for nothing.

The problem isn't the length of the prompt, it's the absence of a success condition. An agent optimizes toward a signal; if you give it none, it falls back on "produce something that looks like what was asked," which is the worst outcome: credible enough not to be rejected outright, arbitrary enough not to be reliable. Scoping a task means providing three things: an observable end state, a way to observe it, and limits on what the agent is allowed to touch. The rest — the tone, the politeness, the "please" — has no measurable effect.