The Problem: When Simple Tasks Become Major Undertakings
The department I lead relies heavily on code generation by coding agents, and it's not unusual for us to have tasks that take considerably longer than their scope would suggest. In fact, I've seen multiple cases where tasks ran for dozens of sessions without reaching completion or producing the deliverable we had requested.
Our development process requires extensive journaling of coding sessions. Having reviewed some of those logs, I noticed a recurring pattern: agents were turning fairly simple problems into much larger undertakings instead of simply fixing what they had been asked to fix. They often expanded the scope, modified code, or proposed improvements that were absolutely not part of the original instructions. The result was that coding agents went through session after session, consumed tokens, and delivered the requested result much later than necessary.
Another problem I noticed was that, on one occasion, agents attempted to modify files that were write-protected because they contained critical system components. Instead of reporting that they could not make the requested changes, they tried to find a workaround. They treated this unexpected restriction as yet another problem they had to solve. In this particular case, this cost us an additional two hours, and millions of tokens were wasted.
All these instances made me think about something we perhaps take for granted when it comes to agents. We expect them to be good at solving problems, and we evaluate them on that basis. But do we give much thought to how capable they are of deciding when to act, when to stop, and when to persist? How well can agents actually make these decisions?
What Does the Research Tell Us?
It turns out that this very topic was the focus of a research team led by Thibaud Gloaguen, who, together with his colleagues, published an article in May 2026 entitled Coding Agents Don't Know When to Act. The researchers investigated how well agents make decisions about when to take action. More specifically, they examined what they called the agents' action bias: the tendency to modify code in response to a task, even when no modification is necessary.
To investigate this, the research team created FixedBench, based on 200 real-world issues from SWE-Bench Verified. They first applied the original fixes to the code and then gave coding agents the corresponding tasks, presenting them as if the issues had not yet been resolved. Under these testing conditions, agents made unnecessary changes to executable code in 35–65% of cases. That is, even though the reported problems had already been fixed, agents still attempted to fix them in response to the instructions they were given.
Next, the researchers instructed agents to verify whether the reported issue was still present before deciding whether further work was necessary. This markedly reduced unnecessary changes. But there was an unfortunate consequence: the instruction also increased the rate of abstention. Agents sometimes decided not to proceed even when there was still an actual task to complete.
It turns out that instructing agents to abstain is a double-edged sword. It does reduce the rate of unnecessary changes, but it does not necessarily make agents better at judging whether they should continue working or whether further action is indeed required.
Knowing When to Stop: A Second Study
There is also a more recent study, Knowing When to Stop: The Evidence-Action Gap in Coding Agents published in October 2026, and its authors investigated almost the same problem I had encountered. The team led by Tianyu Chen looked into whether agents have a tendency to continue working even after encountering sufficient evidence that the task at hand requires external assistance.
For their test, they developed ImpasseBench, which introduced obstacles into otherwise quite solvable repair tasks. Some obstacles were persistent barriers, while others were temporary failures. In experiments that involved persistent barriers, 34% of baseline runs exhausted their 80-step budget, even though the execution traces contained enough evidence that further autonomous attempts were unlikely to succeed.
Then the authors introduced an explicit escalation tool and gave agents instructions to use it. Agents could persist or request help. The proportion of runs exhausting the budget dropped from 34% to 6.7%, even though the results varied considerably between different models.
Another finding was that persistence in solving a task can become quite dangerous. Some agents attempted to work around access restrictions. They tried to access protected credentials or even modify the tests. Even though none of those attempts succeeded, the problem was that the agents made those attempts in the first place.
When the researchers looked at the escalation reports, they found that, of the 3,149 rated tickets they examined, 35.7% failed to fully describe the agents' progress. This closely resembles another problem we sometimes have in our development. The agents sometimes generate fairly poor handoffs that do not allow us to clearly see what has been done or verified.
But stopping too early and escalating to an external assistant can also be problematic. Some agents did this when encountering temporary failures that could have been solved by another attempt.
It turns out it's not enough to make agents more willing to stop. What's important is to help them distinguish when further work is necessary, when no changes are needed, and when an extra effort is no longer justified.
What Can We Do in Practice?
In our department, we have developed a set of instructions that enable our agents to make better decisions about abstention, persistence, or escalation.
First of all, one instruction that we added to our harness helps agents figure out which changes are necessary. It literally sounds like this:
Before making code modifications, assess whether the requested outcome is already satisfied using the available evidence. If it is, provide supporting evidence and complete the task without changing code. If the evidence is inconclusive, report that uncertainty. Do not introduce unrelated improvements to justify the task.
Very important for us is to make sure that verification and reporting are proportional to the complexity and risk of the task. If we require extensive checks and overly detailed reports, we only add unnecessary overhead to many simple tasks, which still constitute a large amount of the work our department does.
One other measure for us was to set better acceptance criteria. This is not new; we have already been working on it for months. So this is only an additional instruction that, in our case, is as follows:
Do not expand the scope to address problems unless they are necessary for correct and safe completion. Report them separately.
Finally, to address the problem of over-persistence and help agents recognize authorization boundaries, we have come up with the following instruction:
Treat deliberately protected files and paths as authorization boundaries. Do not attempt to work around them. Do not bypass them without explicit authorization. If the task requires access outside the permitted scope, stop the affected work and report the restriction.
Now, these are the changes that we are experimenting with, and so far, we have found the results quite positive. However, the complete evaluation of these changes is still outstanding.
Sources
Gloaguen et al., Coding Agents Don’t Know When to Act (May 2026); Chen et al., Knowing When to Stop: The Evidence-Action Gap in Coding Agents (October 2026). The charts adapt results from these papers under CC BY 4.0; the escalation report in chart 4 is illustrative.
0 Comments