Every team has a story about the agent that shipped something no one asked for. The ticket said "improve load times," so the agent optimized a database query that ran twice a day, while the actual bottleneck sat in the client-side rendering. The instruction was "clean up the data," so it deleted every row with a null value, including the ones accounting for seasonal dips. This isn't a failure of the model. It is a failure of specification. The title asks a sharp question: when did you last tell your agent what "done" means? The uncomfortable answer is that most of us haven't, and we are only now seeing the cost of that vagueness.
We have written before about how exploring real-world computer vision deployments forces a similar reckoning, where a model trained on clean frames stumbles the moment it meets a dirty windshield. The parallel is direct. In that case, the gap was between training data and physical reality. Here, the gap is between your intent and the text you typed. The agent is not being stubborn. It is being literal. When you say "final version," it hears "last version you send," not "the version after legal reviews it." When you say "follow up soon," it hears "within the next business day," not "after the client responds to the procurement email." The tool is doing exactly what you asked. That is the problem.
What makes this tricky is that we have spent a decade being trained by tools that punish ambiguity with a prompt box. You ask an older system a vague question, you get a vague answer, and you refine. The agent, however, acts. It doesn't hand you a draft and wait. It updates the CRM, sends the email, or deletes the file. The consequence is that the cost of a vague instruction is no longer a poor draft. It is an action you have to undo. This is why the Forrester function discussion about optimizing under constraints matters here: you are not just optimizing for a correct output, but for a correct outcome under your specific conditions. The agent is optimizing for its interpretation of your words, which is a different objective function entirely.
So what do we actually tell a reader who asks us about this? Start with the mundane. Write your definition of done as if you were explaining it to a new hire on day one. Include the exceptions. Include the "unless." Spell out what you do not want. The extra minute you spend writing "archive the file, but do not delete it, and send a read receipt only to the client, not the internal team" saves you an hour of untangling a wrong action. And if you are building these systems, treat the instruction as code. You would not ship a feature without a test. Do not ship an agent without a verification step. We already know that verifying an AI's understanding with a simple check can catch errors before they become costly. The same principle applies here. Ask the agent to state its plan before it executes. If it cannot tell you what it thinks "done" means, it does not know. And if you do not know what it will do, the only safe answer is to make it ask first.