The acceptance criteria didn't disappear. They became evals.

Gartner predicts that more than 40% of agentic AI projects will be canceled before the end of 2027. Their stated reasons: escalating costs, unclear business value, inadequate risk controls. Read between the lines and the real reason is simpler. Most of these projects never had a testable definition of "done." They had a demo that looked good in a meeting.

I ran QA at scale on LLM training data pipelines at Centific before "AI PM" was a job title anyone put on a resume. The work was unglamorous: build the rubric before the model touches the data, sample real cases instead of the easy ones, and refuse to sign off until the pass rate was a number, not a vibe. That instinct is exactly what most agentic AI teams are skipping right now, and it's why Gartner's number doesn't surprise me.

Traditional acceptance criteria assumed deterministic software. Given X, when Y, then Z. You wrote it once, a QA engineer checked it once, and the feature either matched the spec or it didn't. AI breaks that model because the same prompt against the same model can produce a different answer on Tuesday than it did on Monday. A single pass or fail doesn't tell you anything. You need a distribution.

That's what an eval is: a curated set of real inputs, a scoring function, and a target pass rate the system has to clear before launch and keep clearing after every prompt edit, model swap, or upstream data change. Braintrust calls this "evals are the new PRD." Rick Pollick frames it as evals replacing acceptance criteria directly — each "then" clause in your old Given/When/Then becomes a property you score, and the full set becomes the executable spec. I'd go further: the eval isn't documentation of the spec, it is the spec. If you can't point to the dataset and the scoring rubric, you don't have requirements, you have vibes with a deadline.

Here's the sequence that actually works, in order. First, write down the specific failure modes you're afraid of, not a generic "accuracy" number. "Refuses to answer when it should" and "answers confidently when it should refuse" are different failures with different costs, and they need different test cases. Second, pull your eval set from real production inputs or realistic near-misses, not the ten prompts that always work in a demo. Third, write the scoring rubric before anyone writes a line of prompt, and make it something a second person could apply and get the same score. Fourth, set the target pass rate with the team that will own the postmortem if it's wrong, because a number nobody was willing to defend in the room isn't a real number.

This is also where the PM's job actually changes, not just the vocabulary. Writing a PRD used to mean describing behavior in prose and trusting engineering and QA to interpret it consistently. Writing an eval means the PM has to be precise enough that a scoring function can execute the requirement. That's a harder skill than most PM training covers, and it's the one the market is now paying for. Job postings mentioning AI evaluation experience aren't asking for a buzzword. They're asking whether you can turn "it should feel helpful" into a rubric someone can run against 200 cases and get a pass rate out of.

Go back to the Gartner number with that lens. Forty percent of agentic projects aren't getting canceled because the underlying models are too weak. They're getting canceled because someone eventually asked "how do we know this works" and there was no answer waiting. An eval is that answer, written down before launch instead of invented during the incident review.

Treat the eval like you'd treat any other acceptance criteria: owned by the PM, agreed before build starts, and non-negotiable at ship time. Skip that step and you haven't shipped an AI feature. You've shipped an experiment with a launch date, and Gartner already told you how those end.