Coding agents solve early and stop late, and your gateway sees less than you think
Coding agents often get the fix right on the first edit, then keep going for another third of the run. That is the core finding of Termination Lag (https://arxiv.org/abs/2611.14960), one of two agent papers in Friday's Nov 13 arXiv batch that are really about money and control. The authors ran five models across two frameworks and three SWE-bench sets, recording and testing every distinct patch the agent produced along the way.
In 38% to 82% of successful runs, the first source edit was already correct. Everything after that is lag. On SWE-bench Verified and Multilingual, post-solution steps make up a median 35% to 37% of the run for Qwen3-Coder and 54% to 60% for Laguna-XS.2. The extra steps are mostly verifying and exploring. And in 1% to 8% of cases the agent undoes its own correct patch and finishes wrong. So you pay for the extra tokens and sometimes they make the answer worse. If cost per finished task is the number that matters, knowing when to stop is a cheaper win than a smarter model.
The second paper, guardscope (https://arxiv.org/abs/2611.15223, code at https://github.com/VulcanLab/guardscope), asks a question every team with an agent gateway should ask. An agent has 15 ways to take an action, and a runtime control only sees the ones that cross the spot where it sits. guardscope predicts coverage from source code, then classifies every action actually executed as checked, bypassed or prevented, against kernel-level ground truth, across eight deployment topologies. It was tested with Microsoft's agent governance toolkit and agentgateway. The pitch is that vendors should publish a kernel-verified coverage claim instead of a feature list.
Read together, the two papers say the same thing from opposite ends. Telling an agent to stop or to stay in bounds is not enough, you need a measured check outside the model. One is a stopping rule backed by tests, the other is a coverage number backed by the kernel. The agent is usually not the weak part. The loop around it is.
← Back to all articles
In 38% to 82% of successful runs, the first source edit was already correct. Everything after that is lag. On SWE-bench Verified and Multilingual, post-solution steps make up a median 35% to 37% of the run for Qwen3-Coder and 54% to 60% for Laguna-XS.2. The extra steps are mostly verifying and exploring. And in 1% to 8% of cases the agent undoes its own correct patch and finishes wrong. So you pay for the extra tokens and sometimes they make the answer worse. If cost per finished task is the number that matters, knowing when to stop is a cheaper win than a smarter model.
The second paper, guardscope (https://arxiv.org/abs/2611.15223, code at https://github.com/VulcanLab/guardscope), asks a question every team with an agent gateway should ask. An agent has 15 ways to take an action, and a runtime control only sees the ones that cross the spot where it sits. guardscope predicts coverage from source code, then classifies every action actually executed as checked, bypassed or prevented, against kernel-level ground truth, across eight deployment topologies. It was tested with Microsoft's agent governance toolkit and agentgateway. The pitch is that vendors should publish a kernel-verified coverage claim instead of a feature list.
Read together, the two papers say the same thing from opposite ends. Telling an agent to stop or to stay in bounds is not enough, you need a measured check outside the model. One is a stopping rule backed by tests, the other is a coverage number backed by the kernel. The agent is usually not the weak part. The loop around it is.
Comments