Acceptance Criteria

Acceptance criteria are a statement, written before the work starts, of what would make the result acceptable — specific enough that somebody other than the author can check it. Borrowed from software delivery, they matter more with agents than they ever did with people, because an agent will otherwise decide for itself that it is finished. That is the core problem. A model asked to complete a task and then asked whether it completed the task is being asked to grade its own homework in the same style it wrote it, and it tends to answer yes. Self-reported success is the least reliable signal in an agent system, and it is the one most dashboards are built on. Criteria that can be checked by something else — a test that runs, a schema that validates, a record that now exists with the expected values, a total that reconciles — break that circularity. Good criteria describe properties, not wording. "Cites at least one source from the supplied documents, changes no field outside the ones named, leaves the ticket in a state a human can pick up" is checkable and does not constrain how the work is done. A criterion phrased as an example output is worse than useless with a generative system, because it invites matching the shape of the example rather than satisfying the requirement. They also define what to do when the answer is no, which is the half people leave out. The run should stop or escalate rather than continue past a failed check, and the failed criterion should travel with the escalation, because a person receiving "this did not work" has to redo the investigation the system already did. The last benefit is the one that arrives quietly. Writing acceptance criteria forces the ambiguity in the request to surface before the agent runs into it, and a surprising share of tasks turn out to be underspecified rather than difficult. Where a criterion cannot be written down at all, that is usually a signal the task needs a human judgement in the middle rather than a better prompt.