Small Models, Smarter Recovery: Four Papers Reshaping Coding Agents

The bottleneck moved from writing code to picking tools

My team's coding agent worked fine with about 40 tools in its registry. Around 900 it started reaching for grep when it should have called the symbol-index service, and re-reading files it had already read. The model wasn't worse at writing code. It was worse at choosing.

That experience lines up with what the ToolBench work reports (arXiv:2610.31483). Once an agent operates over a corpus of more than ten thousand tools, selection becomes the central bottleneck. At that scale you cannot stuff every description into context, so you retrieve. But a relevance-based retriever ranks by similarity, and similarity is not need. The tool the task actually requires may rank twentieth because its description uses different vocabulary than the user's instruction.

The current fix is to let a strong model drive the retriever: decompose the instruction, look at retrieved candidates, pick. That works, and it costs commercial API money on every step of every multi-step instruction. The interesting result is that you can train a small open model to do the same job with reinforcement learning.

Key numbers8B parameters for the RL-trained selector, small enough to serve on one 24GB GPU. 402B parameters for Llama-4-Maverick, the model it beats on ToolBench. 4.8 score points of average gain from RIPPLE across four repository-level benchmarks. 12 equation-discovery problems where persistent-agent search recovered more ground-truth structures.

An 8B model that out-selects a 402B one

The recipe is straightforward once you accept the framing: tool selection is a policy problem, not a retrieval problem. Train the model to decompose an instruction and choose among retrieved candidates, reward it on whether the final tool set was right, and let RL handle the rest.

Two claims in that paper matter more than the headline benchmark. First, the trained model transfers across retrievers. Swap BM25 for an embedding retriever and the policy still works, because it learned to read candidate descriptions rather than memorize a ranking function. Second, it generalizes to new tool corpora in different domains, which is the difference between a demo and something you can deploy against a customer's own API catalog.

Approach	Handles 10,000+ tools	Cost per instruction	Knows what the task needs
All descriptions in context	No	Highest token bill	Yes, in principle
BM25 or embedding top-k	Yes	Cheap	No, ranks by similarity
Commercial LLM driving retriever	Yes	Per-call API price	Yes
RL-trained small selector	Yes	One small-model call	Yes

Practical read: an 8B model means one GPU, predictable latency, and no per-token bill from a vendor. If your agent runs thousands of instructions a day, the selection step stops being a line item and becomes infrastructure.

Quick take: tool selection is now a trainable skill you can own with an 8B model, not a capability you rent from a frontier lab.

Skills need a gearbox, not a bigger library

The second paper (arXiv:2610.31461) asks a question that most skill-library work skips: once you've retrieved a skill, how coarse should the execution be?

The same coding task can be solved three ways. Fire primitive tool calls one at a time. Run a macro skill that packages the whole procedure. Or start with the macro and fall back to primitives when it fails. Prior work studies how agents retrieve, compose, or synthesize skills before execution. Adaptive Skill Granularity treats granularity as an action-abstraction policy conditioned on task structure, execution state, and whether a macro has already failed.

The system has two parts: a feature-based controller that picks the granularity, and a finite-state executor that handles recovery.

The finding that should change how you build skill libraries: fixed macro execution is efficient when it applies and brittle when it doesn't. That's obvious in hindsight and expensive in production. A macro that matches 70% of tasks looks like a win until the other 30% fail silently, because nothing in the system knows how to step down a level.

What I like about this framing is that it treats a skill as an execution abstraction you can verify and recover, not just a document you can retrieve. Their evaluation protocol uses verifier-defined success and process metrics like macro adoption, route match, transition correctness, and failure recovery. Those metrics tell you where the routing policy is wrong. A success-rate number alone won't.

Persistent agents beat one-shot mutation

Evolutionary program search with LLMs keeps the shape of a genetic algorithm and uses the model as the variation operator. Standard setup: feed parent programs and their scores into a single request, get a candidate back, evaluate it.

AgenticEvolve (arXiv:2610.31326) changes the unit of work. Each island is run by a persistent agent. Between evaluations, that agent designs and runs experiments on the candidate program instead of immediately proposing a mutation. The ablation is clean: a No-analysis configuration with experimentation disabled, otherwise identical.

Across two heuristic design tasks and three LLMs, the experimentation-enabled version produced better programs than both No-analysis and OpenEvolve on hidden and unseen instances. It also reached the baselines' final quality with far fewer evaluations at comparable cost. On twelve equation-discovery problems, it recovered the ground-truth structure of more equations than No-analysis and the existing LLM and genetic-programming baselines.

The cost claim is the one to scrutinize. "Comparable cost with fewer evaluations" means experimentation is eating the budget you saved on candidate generation. That's a good trade when evaluation is expensive and analysis is cheap. If your fitness function is a 40-second test suite and your agent spends 40 seconds experimenting, you've gained nothing. Match the configuration to which side of that ratio you're on.

The critique-to-action handoff gap

The sharpest problem statement across all four papers is in RIPPLE (arXiv:2610.31276): a long-horizon agent can observe a failure, generate a plausible critique, and then continue down the same incorrect trajectory. The model produces the words of recovery without the action of it.

I've watched this happen. The agent says the test failed because the import path is wrong, then edits an unrelated file. Critique quality is not the gap. The handoff from critique to corrective action is.

RIPPLE trains recovery as a process rather than an outcome. A prefix-only teacher provides recovery supervision using only what was observable at that point in the trajectory, with no access to future actions or terminal outcomes. That teacher's guidance gets distilled into the policy. RL then assigns credit separately to three stages: triggering reflection, diagnosing the problem, and taking corrective action. Local validity signals gate the trajectory advantage, so an intermediate recovery decision doesn't inherit a terminal outcome it had no part in.

The result: a 4.8 point average improvement over the base policy across four repository-level software-engineering benchmarks, with no auxiliary critic needed at deployment. Removing the critic matters. A paired critic model doubles your serving footprint and drifts independently of the policy.

The ablations are where the practical detail lives. Recovery gains concentrate in two conditions: the prefix contains enough diagnostic evidence, and the repository state stays reversible within the remaining budget. When either condition fails, extra recovery training buys you very little.

What trips people up

Training the selector on one retriever's top-k. If you always sample candidates from your production retriever at k=20, the policy learns that retriever's quirks, not tool semantics. The transfer claim in the ToolBench work only holds if you vary the retriever and the candidate pool during training. I learned this one by shipping a model that fell apart when we swapped BM25 for a dense index.

Awarding terminal reward to every step. If the final test result flows back into the reflection trigger and the diagnosis and the fix as one signal, the model can't tell which decision was good. Stage-aligned credit is the whole point of RIPPLE. Gate your advantages locally or don't bother.

Leaving macro skills permanently on. Fixed macro execution has the best cost profile when it matches and the worst failure mode when it doesn't. Wire the fallback before you wire the optimization, and log route match so you can see the mismatch rate.

Running experiments without a per-candidate budget. A persistent agent that can call tools freely between evaluations will. Cap the experiment budget per candidate, or one island will consume the whole run while the others sit idle.

Trusting success rate as the only metric. Macro adoption, transition correctness, and failure recovery tell you why something failed. A single success number tells you that it did.

What I'd wire up first

If I were rebuilding the agent from the earlier paragraph, the order would be: retriever-agnostic selector trained with RL, then a granularity controller with an explicit macro-to-micro fallback, then recovery training, then evolutionary search on top.

That order is deliberate. Selection errors dominate everything downstream, so fixing them first makes every later metric cleaner. The granularity controller needs a verifier you trust, which means you need per-task success definitions before you need routing logic. Recovery training only pays off where the trace contains diagnostic evidence and the workspace is reversible, so it belongs after you've confirmed that condition holds in your domain.

Search comes last because it's the most expensive per unit of gain, and the AgenticEvolve results suggest its advantage shrinks when your evaluation loop is cheap relative to your analysis loop.

One thing to remember

All four papers point at the same shift: the interesting decisions in a coding agent happen before and after the model writes a line of code. Which tool, at what granularity, with what recovery path. Those are policy problems, and policy problems can be trained on small models.

The Bottom Line

If your agent's tool registry is past a few hundred entries and you're paying a frontier model to pick tools, train an 8B selector with RL instead. The transfer-across-retrievers property means you're not locking yourself into one index, and one GPU is cheaper than a per-call bill at any real volume.

If your macro skills fire often but fail silently, don't expand the library. Add a granularity controller with explicit macro-to-micro recovery and start logging route match. Fixed-granularity execution is efficient right up until it isn't recoverable, and that's where the cost shows up.

If your agent critiques its own failures and then repeats them, stop tuning the critique. Train stage-specific credit with local validity gating, and check first that your traces carry diagnostic evidence and your repo state is reversible. Without those two conditions, recovery training is a rounding error.

Sources

• Training Small Language Models for Transferable Tool Selection: arXiv:2610.31483v1
• AgenticEvolve: Evolutionary Program Search with Persistent Language Model Agents that Design and Run Experiments: arXiv:2610.31326v1
• Adaptive Skill Granularity for Coding Agents: Runtime Routing and Macro-to-Micro Recovery: arXiv:2610.31461v1
• RIPPLE: Recovery Internalization through Process-Level Policy Learning and Effect-Aware Credit for Long-Horizon Agentic Coding: arXiv:2610.31276v1