Your agents aren't underperforming.
Your requirements are.

The best predictor of whether an agent produces useful work isn't the model. It's the quality of the task definition the team handed it.

The pattern shows up wherever agents reach real delivery work. Same model and same tooling across every team, and output quality still varies widely. Seniority doesn't explain it, and neither does which workflow has the newest framework. The difference lives in the ticket. A task that arrives with written acceptance criteria comes back as mergeable work. A task that arrives as two lines and a link to a Slack thread comes back as work that looks finished and isn't.

That variance reads as an agent problem. It isn't. For years, weak requirements were survivable because a human on the receiving end quietly repaired them. Someone asked the clarifying question in standup, inferred the unstated constraint, knew which conventions the two-line ticket assumed. Call it the invisible repair layer, the accumulated gap-filling that engineers and product managers perform on every underspecified request, unbilled and unrecorded. Agents didn't create a requirements problem. They removed the layer that was hiding the one you already had.

The repair layer

A requirement handed to an experienced human has never been a complete specification. It's a pointer to one. The rest gets assembled on the receiving end, from context the organization never wrote down. Memory of how the last similar request went, the hallway conversation that scoped it, an unwritten rule that this product surface never touches that data class. Intent arrives in shorthand, and the executor reconstructs the full requirement before building against the reconstruction.

Reconstruction is real work, but it has a property that kept it off every ledger. It's distributed across hundreds of small moments and none of them is billed. A clarifying question gets absorbed in standup. A constraint inferred correctly costs nothing visible at all. From the org's side, this looks like delegation working, when what's happening is that its specification defects are being caught and patched, one at a time, by the most expensive people it employs.

Because the patching is silent, requirements discipline was never really tested. A two-line ticket and a rigorous spec produced similar outcomes, so the organization learned that the two-line ticket was sufficient. What looked like sufficiency was subsidy.

The subsidy explains a pattern most delivery orgs will recognize. Every earlier attempt to enforce requirements discipline quietly died. Ticket templates with mandatory fields got filled with "see thread." Definition-of-done checklists decayed within a quarter of being introduced. Not because teams were careless, but because the discipline never had a forcing function. An unfilled field cost nothing anyone could see, since the repair layer covered it. The subsidy only holds, though, while the thing executing the request is the kind of thing that repairs what it receives.

Compliance without repair

An agent is not that kind of thing. Where a human fills a gap with the requester's probable intent, an agent fills it with something plausible, and plausible is a much larger space than intended. The agent doesn't push back on the two-line ticket and doesn't flag the ambiguity it resolved on your behalf. It complies. It builds exactly what was specified, including the parts that were specified by omission.

Compliance produces a distinctive failure signature, quiet and confident. A human working from a bad spec surfaces the badness early, usually in the form of a question. An agent working from a bad spec delivers a finished-looking artifact, structured, plausible, and wrong in ways that take a careful reviewer to find. The cost of an underspecified request used to be a thirty-second interruption. Now it's an audit.

Which is where the repair work went. It didn't disappear when the agents arrived. It moved downstream, out of cheap clarifying questions and into expensive review cycles and rework. The same underspecified sentence costs more after the agent rollout than before it.

The trust cost moves with it. After the second confident artifact turns out to be wrong, teams stop delegating consequential work to the agent and route it back to humans, keeping the agent for the low-stakes tasks where a wrong answer doesn't matter. The rollout stalls at exactly the work that justified the spend, and the stall gets attributed to the agent.

The wrong line item

That attribution is where budgets go wrong. From the executive seat, the observable facts are that the org paid for agent tooling and the output is inconsistent. The natural read is a capability gap, and the natural response is to spend against it. A newer model, a different framework, another orchestration layer. The spend is legible. It has a vendor, a line item, and a demo.

Specification quality has none of those. It was never a budget line because the repair layer absorbed its costs invisibly, smeared across the salaries of everyone who ever fixed a vague request on the fly. An organization can't see that it has been underinvesting in requirements for a decade, because the underinvestment never produced a failure it could attribute. It produced thirty-second interruptions, and nobody escalates those.

Downstream costs are just as hard to attribute. A review cycle that runs long here, a sprint reworked there, a rollout quietly narrowed to low-stakes tasks. None of these has a single owner or a line item, and each reads as normal delivery friction. The one visible artifact in the whole chain is the model, which is why the model absorbs the blame and the budget.

So the model gets upgraded and the variance persists, because the variance was never in the model. Teams inside the same company, on the same stack, keep producing opposite outcomes, and the difference sits in an artifact nobody is measuring, the task definition. The org is tuning the executor while the defect is in the instruction.

What a complete requirement is

The teams on the right side of the variance treat the requirement itself as a deliverable, with its own definition of done. In that discipline, a task isn't ready for an agent until it carries explicit success criteria, stated constraints, named non-goals, and the context a human executor would have absorbed ambiently. Which systems are in scope, which conventions apply, what the last attempt got wrong. The simplest version is a single rule. No task goes to an agent without a written check the output can be verified against. It reads as overhead. It's the whole difference.

Writing requirements at that standard is slower per task, and the teams doing it are faster per delivered outcome, because the expensive part of agent work was never the generation. It's the loop. Specify, review, discover the ambiguity, respecify. A complete requirement collapses the loop. An incomplete one runs it three or four times, with a review cycle in every pass, and the review is performed by the same senior people whose time the agent was supposed to buy back.

There's a compounding effect the per-task view misses. Specification is a skill, and teams that practice it build a library of reusable context, documented conventions and standing definitions of done that carry from task to task. Their marginal requirement gets cheaper. The teams still delegating in shorthand pay full price for the ambiguity every time, which is why the gap between the two widens every quarter rather than closing on its own. One side's specification cost declines with use. The other side's recurs on every task, with no termination date.

Senior engineers have always tolerated vague requirements, the objection goes, so expecting rigor now is a regression to bureaucracy. But the tolerance was never free. It was the repair layer, priced into engineering salaries and paid on every request. And the rigor isn't process for its own sake. It's the same information the repair layer was supplying all along, relocated from individual memory into an artifact that can be reused, reviewed, and handed to any executor. Agents didn't raise the standard for requirements. They started charging the true cost of not meeting it.

Which reframes what an agent rollout tests. The model's capability is identical in every team that licenses it. What varies, and what the rollout exposes, is how much of the organization's operating knowledge exists in written, verifiable form, and how much of it was living in the repair layer all along. Requirements quality is the leading indicator of agent ROI, and it's measurable now. Ten tasks handed to agents last month, counted for whether each carried a check the output could be verified against.

Most orgs won't run that count. They'll keep measuring the model, because the model has a benchmark and a vendor to hold accountable, and the requirement has neither. The repair layer is gone either way. What's left is the question it was covering for. Whether your organization ever knew how to say what it wants. Most haven't found out yet.