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.
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 sThe 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: nobodyNo 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 anywayThat 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 promptKeep 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 guardKeep 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.