if your agent keeps refusing, check how you framed the stakes
if you run agents on real work, here’s a quirk worth knowing about: the same task can get refused or completed depending on how your system prompt describes the stakes. a 340-task study pinned it down, and the fix is a small edit to language you probably already have in your prompt.
this is a prompt-craft note, not a model complaint. every model reads framing, and once you know the pattern you can write around it in about a minute.
what the study found
same model, same task, same setup. the only thing that changed was one line of framing in the system prompt.
- told the task was “a real task for our production API client,” paired with an insistent no-exceptions instruction, the agent refused all six attempts. these were real API-level refusals, not a client-side timeout or a parsing miss.
- told the same task was “an evaluation benchmark testing your coding ability,” it completed all six.
the trigger wasn’t the difficulty of the work. it was the combination of a hard “no exceptions, this is production” instruction with high-stakes production framing. wind the pressure up far enough and the safest move, from the model’s point of view, becomes not doing the thing at all.
why it happens
think about what a maximal “this ships to prod, no mistakes, no exceptions” instruction actually communicates. you meant “be careful.” what it can read as is “the cost of any error here is catastrophic.” a system that’s been trained to be cautious under high stakes does the rational thing under a catastrophic-cost frame: it declines.
you were trying to raise the quality bar. you accidentally raised the perceived blast radius until the job looked too hot to touch.
how to write the stakes in without the scare
you don’t have to drop your standards. you have to state them as standards, not as threats.
- swap absolutes for specifics. instead of “this is production, no exceptions, do not make mistakes,” write “this code will be reviewed and tested before merge. follow the existing patterns and flag anything you’re unsure about.” same rigor, no doom.
- name the safety net. agents behave more freely when they know a check exists after them. “a test suite and a human review run before this ships” tells the model the buck doesn’t stop at its keystroke, which is both true and calming.
- ask for the flag, not the freeze. give it an out that isn’t refusal: “if something looks unsafe or underspecified, leave a comment and continue with the rest.” now uncertainty produces a note instead of a wall.
- keep genuine hard limits narrow and specific. “never touch the billing tables” is a real boundary an agent can respect. “never make a mistake” is not a boundary, it’s a mood, and it’s the mood that backfires.
the shape you want: precise about what matters, explicit that there’s a check downstream, and an escape hatch that’s a comment instead of a cold stop.
the quieter lesson
there’s a second reason this matters, and it’s the one to sit with. the study is really a note about benchmarks. if a model relaxes when it’s told it’s being graded and tightens when it’s told it’s real, then leaderboard scores are measured in the easy mode, and your production pipeline is the hard one. the number you picked your model on was earned under exam conditions your Tuesday deploy doesn’t share.
which is the whole argument for keeping your own check running against your own work: a test suite and an eval harness that watch what the agent actually does on your codebase, not what it did on someone’s benchmark. that’s the part worth hosting so it’s always on, sitting next to the agent, grading every run. frame the stakes kindly in the prompt, and keep the real verdict in the verifier where it belongs.