Agents Do Not Push Back

A twelve-task plan went out. What came back was exactly what it asked for. That was the problem.

The plan had nine defects in it. Not typos. Sequencing that would not hold. Assumptions that did not survive the data model. Tasks that were coherent alone and incoherent together.

All nine got built, faithfully. Nobody stopped. Nobody asked. An independent review found every one of them later. I had written every one of them.

Handing a bad spec to a person goes differently.

The friction nobody paid for

Give a flawed plan to a senior engineer and something happens in the gap between reading it and starting it. They frown. A question comes back, technically about task four, actually about whether you thought this through. Sometimes they just build it correctly and mention the discrepancy in the pull request. Same service, better manners.

Nobody designs that. It emerges. The person receiving the instruction holds their own model of the system, and your instruction contradicts it, and the contradiction is uncomfortable.

The discomfort is involuntary. That is what made it reliable.

Agents have none of it. Compliance is the product. A good one executes an incoherent plan with the same care it brings to a sound one. The output is clean, tested, well formatted, and wrong in precisely the way the instructions were.

So the review step everyone thinks of as checking the work was quietly doing a second job. It was checking the instructions. That job only becomes visible once it stops happening.

The small version, same shape

A donation flow made the point again at lower stakes.

The spec covered a checkbox letting a donor cover the processing fee. Frozen, handed to an executor, returned as a clean implementation.

The fee calculation ignored the checkbox. You could toggle it and the amount would not move.

The executor did what the spec said. The spec described the control, described the calculation, and never adequately tied them together. A person building it would have tripped over that in five minutes, because a person clicks the box and watches nothing happen.

Caught in review, fixed the same day. But I want to be precise about who failed there. I did, at spec time. And the pipeline had no step in it capable of noticing.

Two projects, different stacks, different weeks, same hole. Once is an anecdote. Twice is the shape of the thing.

The wrong lesson is to delegate less

The reflex is to pull work back. Do it yourself, or slow the handoff down until it feels like the old thing. That trades away most of the value to solve a problem with a cheaper fix.

The fix is to move the adversary earlier.

Reviewing output was the habit. Reviewing the plan is the requirement. A spec now gets a hostile read from a fresh context, one that was not present for the conversation where the author convinced himself, and whose only job is to find what breaks.

Not a rubber stamp. An attempt to make the plan fail on paper. Failing on paper is much cheaper than failing across twelve implemented tasks.

Nine of nine came out of exactly that kind of pass. The number is what settled the argument. The plan had felt solid when it went out. Asked to guess at defects beforehand, I would have said one or two, and been wrong by a factor worth sitting with.

The reviewer cannot be the author

A second rule came out of a portal build running several agents in parallel. The coordinator commits. The implementers do not.

Part of that is practical. Concurrent agents in one checkout fight over locks and make a mess. The durable reason is separation. The thing that writes should not be the thing that certifies.

When both are agents, collapsing those roles is trivially easy, because they are all just calls. Nothing about the setup resists it.

In a human org this separation is expensive and political. It needs enough people, and it needs one of them willing to tell a senior person their plan is wrong. Most orgs are not good at that. It is why bad specs ship constantly.

With agents it costs a prompt. The awkward part, where someone risks a relationship to say the thing, does not exist. Nobody has to be brave for the review to happen. That is the real upside hiding inside this problem, and it is underrated. An adversary on every plan is now affordable, not just on the important ones. The only reason to skip it is habit.

What the signal looks like now

The signal I trust least is a delegated task that comes back smooth.

Smooth is not bad. Smooth used to carry information and no longer does. It used to mean the plan survived contact with someone who knew things. Now it means the instructions were followable, which is a much lower bar, and one that bad instructions clear all the time.

So the question about a clean delivery is no longer whether it worked. It is who in the loop was in a position to be confused, and whether anyone checked.

For a while the answer was nobody. Nine defects showed up to prove it.