Skip to content

The “I cannot” your agent is not allowed to say, and the 88 credits it cost us

We think an agent’s honest “I cannot” is a product feature, not a model weakness. In one of our pipelines, forbidding it cost 3 restarts, 17 runs and 88 credits for zero accepted results. What fixed it for us was structure, not a friendlier prompt.

agents · ai-products · evals · reliability · process

An agent that can say “I cannot do this” is worth more than one that always delivers. That is our view, and this piece is the bill behind it.

In one of our internal generative pipelines, forbidding the honest empty answer did not make the failure go away. We bought a plausible substitute for it instead, at full price: 3 full restarts, 17 agent runs and 88 credits. Accepted results: zero.

The number: 59.5%

A new benchmark measures exactly this failure. AgentAbstain tests whether tool-using agents recognize when to abstain instead of producing a fabricated or partial result.

AgentAbstain, as reported by its authors

paired tasks            263   (a should-act task + a should-abstain variant)
sandbox environments     42   (executable)
frontier models          17
agent harnesses           4
best paired accuracy  59.5%

Two findings matter more than the headline.

First, the authors report that the ability to abstain is largely independent of general task-solving ability. In our reading, a stronger model will not close this gap on its own.

Second, they name a failure mode: post-hoc abstention. The agent takes an irreversible action and only afterwards notices the contradiction that should have stopped it.

So “can the agent do the work” and “does the agent know when not to” are two separate measurements. Our read: the first one gets demoed, and the second one gets billed.

The bill: 88 credits for nothing

Here is our own version, from a pipeline that generates short videos.

one short video, generated end to end

full restarts             3
agent runs               17
credits spent            88
  of which one step      64   (the same four prompts, reissued twice)
accepted results          0

the same video, storyboard written by a person

time to storyboard       ~30 min
credits spent            29
result                   usable, 36.5 s

The 64 credits are the instructive part. The rejection was routed to the one step in the pipeline that was not allowed to change prompts. So it sent the same four prompts again. Twice.

The model was not the problem

The root cause was in the written rules. The visual guidelines forbade faces, people, letters, interface and speech in generated footage. The brief asked for a video with a character.

guidelines:   no faces, no people, no letters, no interface, no speech
brief:        a video with a character
              -> unbuildable as specified

who was allowed to say so:   nobody

No step in the pipeline had the right to report that the brief and the guidelines contradicted each other.

We would put it this way: each rule was reasonable alone, and together they made the video impossible. Our pipeline was not stupid, it was obedient, and here obedience was the more expensive of the two.

Three layers of the fix

Our view is that a line in a prompt saying “feel free to push back” is not a fix, and that the right to say no has to be built into the structure, in three places.

1. Find the sentences that close the exit

Start with the text. Search your instructions for lines like “never ask the human” and “never return empty.” Then read your style guide for constraints that make the requested thing impossible. In our experience, such a pair is where a stuck agent hands you filler instead of a report.

While you are there, check where a rejection goes. Ours went to a step that could not act on it. A “no” has to reach someone who can change the thing being refused.

2. Remove the fake escape hatch, keep the honest one

Not every “I cannot” is honest. In our pipeline, the dishonest version was a card that said, in effect, “generate this yourself.”

a rule against “generate this yourself” cards

day 1            rule stated in the agent’s instructions (prose only)
next 24 hours    5 outputs still reached the human check with such cards
  of which       3 were output types with an automatic generator allowed
                 -> the agent picked the manual option anyway

That is a reverse test, and you can run it on your own system. Take away the agent’s option to ask a person, and every place the automation was quietly leaning on people stops being a polite request and becomes a visible failure. In our pipeline, the hidden manual paths survived exactly as long as the agent had somewhere to escape to.

Our rule of thumb follows from it: a rule in the instructions is a suggestion, and a rule the schema rejects is a rule. Stating the ban in prose did not stop the cards, so we moved it out of the prompt:

where the ban lives now

plan schema      admits only generators that have an executor
                 -> an invalid plan goes back to the agent to redo
configuration    grants each output type only those generators
code             strips scenes with a manual generator, a missing asset
                 or no prompt

Keep the honest path, though. An agent that genuinely has nothing it can produce should still be able to say so in plain words. In ours, an output with nothing producible reaches a person as plain text, not as a chore.

3. Make “we produced nothing” deliverable

We think this is the layer teams get wrong in good faith. We were adding a completeness guard to stop unfinished work from reaching a person. Ours would also have stopped the one message a person most needed: “we produced nothing.”

Our escalation path deliberately sends an output with not a single scene to a person, so they can read that nothing could be produced. The new guard would have trapped that output “in progress” permanently.

The exemption is explicit and narrow:

move to the human check:
    if escalated:   waive the completeness guard
    else:           require it

ship the result:
    always require the completeness guard

Keep an exemption like this narrow enough to buy exactly one thing, the delivery of bad news. Ours never helps anything ship.

FAQ

Will a newer, stronger model fix this? In our reading, not on its own. The AgentAbstain authors report that abstention ability is largely independent of general task-solving ability, and the best result across 17 frontier models and 4 harnesses was 59.5% paired accuracy.

Isn’t “never return empty” a sensible default? We think it is sensible on the happy path and expensive everywhere else. In our pipeline it did not remove the failure. It hid the failure inside output that looked finished, and cost 88 credits for zero accepted results.

How do I find where my automation secretly depends on people? Run the reverse test. Remove the option to ask a person and watch what breaks. When we stated that rule, the next 24 hours still brought five outputs with “generate this yourself” cards, three of them where an automatic generator was allowed. The breakages are your real list of dependencies.

Doesn’t an exemption on the completeness guard create a loophole? Only if it reaches downstream. Ours applies to one transition, the move to the human check. It never applies to shipping the result.

Where does post-hoc abstention hurt most? We would look first wherever an action cannot be undone. The benchmark describes the agent taking the irreversible action and only then noticing the contradiction. Put the “should I act at all” check in front of those actions, not behind them.

Related case

The same principle runs through Holt, our language-learning product. An independent validator gates every practice card before a learner sees it, and a card that fails never ships. We think of that refusal as part of the product, not a gap in it.

Read the case at iloblique.com/holt.