2608.07449-SkillProx: Self-Evolving Agent Skills via Proximal Textual Gradient Descent

Introduction to the show: ident: Paper Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "SkillProx: Self-Evolving Agent Skills via Proximal Textual Gradient Descent".

Jane: The paper was written by Mingxuan Zheng, Yujin Zhou, Chuxue Cao, Boqin Yin, Yuyao Zhang et al. from Hong Kong University of Science and Technology and Macau University.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Paper summary: Tom: So we finally get to see what happens when you stop trusting your skill patches just because they look plausible. The paper treats skill evolution like an optimization problem with a forward pass and a backward pass, but every step happens in text.

Jane: And the key difference from earlier work is that they re-run the skill after each patch, on the same batch, and only keep the patch if performance doesn't drop. That seems like an obvious sanity check, yet none of the existing methods actually do it.

Lu: Right, SkillGrad and SkillOpt commit a diagnosis directly as a patch without checking what it does in practice. The paper calls that open-loop, and their trace shows it matters: in one run, eight out of twenty-two attempted edits regressed hard accuracy and had to be blocked.

Meng: And the backward stage is the more surprising piece to me. They decompose the evolved skill into auditable knowledge units, then remove each unit temporarily to measure its marginal utility on a validation split. If a unit's removal helps, they consolidate or delete it — but every realized edit still has to pass a hard validation gate.

Jane: The case study is clean evidence for that. They compress one skill by only 3 point 12 percent, removing a single over-specific section, and hard accuracy on the out-of-sample evaluation jumps from 46 percent to 54 percent. Eight tasks flip from fail to pass, and none flip the other way.

Tom: So that's the "proximal" part — a discrete analogue of shrinkage, where they control skill complexity instead of letting it grow forever. And the forward stage gives them outcome-grounded feedback for future diagnoses, not just a one-shot semantic check.

Lu: Exactly. The paper's own ablation says that removing Prox costs 2 point 5 points on SpreadsheetBench, while removing the closed-loop diagnosis costs 1 point 5. So the shrinkage stage is carrying a bit more weight, but they're complementary.

Meng: And across all backbones, SkillProx averages about three points better than the strongest gradient-based baseline. What impresses me most is the OOD robustness — SkillOpt collapses on WikiTQ and HiTab, down to 26 percent and 16 percent on the 4B model, while SkillProx stays competitive or best.

Jane: Let's bring Lalam in. What do you make of this as a bigger trend?

Lalam: I think it's part of a shift toward agents maintaining their own procedural memory on disk instead of retraining weights. What SkillProx adds is a maintenance layer — a way to audit, prune, and consolidate that memory so a skill doesn't become a junk drawer of half-remembered task solutions.

Tom: And that's why the backward stage matters — it treats deletion as a dedicated operation, not just one generic edit among many. Preventing bad additions and actually shrinking accumulated content are two different problems, and this paper tackles both.

Jane: The detailed analysis on τ is nice too. At a threshold of −0 point 001 they get 52 point 3 percent accuracy with 25 point 7 percent compression, and even at 74 point 9 percent compression accuracy stays at 51 point 0 percent. So you can shrink a skill a lot before you start hurting it.

Meng: Which also explains why the 4B model ends up with a 45 percent longer final skill than the 27B model — mostly from extra reference files. The closed-loop gate and the Prox compression act as an external filter that disproportionately regularizes the smaller model.

Lu: For me, the broader lesson is that textual skill evolution needs measurement at both ends. You need execution feedback to verify forward updates, and you need utility auditing to clean up what accumulates. The paper gives a concrete framework for both, and the numbers suggest it works.

Tom: And that's probably the most useful thing to take away for people building agents in the wild. Skills are already a practical way to give agents knowledge, and this shows you can evolve them safely — with a gate and a shrink step — rather than just letting them balloon.

Page 1 of the paper: Jane: So earlier we talked about skills as lightweight textual artifacts that agents load into context. Page one gets into why those artifacts go wrong. The paper says most systems take an LLM-generated diagnosis, treat it as a valid update direction, and commit the patch without ever checking whether it actually works. It calls that an "unverified forward update".

Tom: So they just trust the model's explanation of what went wrong?

Lu: Exactly. There's no re-execution on the same task batch, so the outcome never feeds back into the next diagnosis. And the second problem is the mirror image: iterative patching makes the skill grow without any mechanism to reassess accumulated knowledge. The paper gives a concrete example where removing one negative-utility unit improves accuracy from 46 percent to 54 percent.

Jane: Wait, removing stuff makes it better? That sounds counterintuitive.

Meng: That's the motivation for the "backward" stage. The skill gets decomposed into auditable knowledge units, and each one's contribution is estimated by a frozen leave-one-out utility audit. Then the method selectively consolidates, demotes, or removes units that don't earn their place.

Tom: So the idea is to prevent bad edits upfront, and then go back and clean up what's already accumulated?

Lu: Right. And that's exactly the central question posed on page one: how can outcome-verified forward diagnosis be coupled with structure-aware backward refinement, so the skill's capability and its structure co-evolve. The rest of the paper is basically the answer to that.

Page 2 of the paper: Tom: This page is where SkillProx actually gets built. Remember we were complaining that earlier methods just patch the skill and hope for the best? Here the forward step re-executes the patched skill on the same batch before committing anything.

Jane: And it's a pretty simple gate. The candidate edit is accepted only if hard accuracy and mean cell accuracy don't drop. The paper even says the first candidate with a strict hard-accuracy gain terminates the search early.

Tom: So they run the skill, try an edit, run it again, and compare. If it doesn't help, they roll back to the previous snapshot and try a different edit, up to three attempts. That's a genuinely different discipline from open-loop patching.

Jane: What I like is the feedback loop. A rejected attempt feeds its measured changes and the attempted direction into the next diagnosis. So the diagnostician learns from what didn't work, not just from what the skill text sounds like.

Tom: That's the closed-loop part. But then page four also introduces the backward stage, right?

Jane: Exactly. Once forward evolution stops, they parse the skill into auditable knowledge units, like L2 sections and L3 reference files. Then they do leave-one-out ablation on a fixed validation set: remove one unit, run the skill, and see if performance goes up or down. A negative utility means removing that unit actually improves things.

Tom: So the paper puts it concretely: a positive value means removing the unit lowers performance, a negative value means the ablated version performs better. And the utilities are measured once and frozen, so they don't get recomputed during the later search.

Jane: Right. Then candidates are picked only if their cell utility is below minus 0 point 001, which is a pretty strict threshold. The ordering also matters, because they sort ascending by cell utility and break ties with hard utility, so the most harmful content gets processed first.

Tom: That connects directly to the motivation we saw earlier, where deleting a redundant section moved accuracy from 46 percent to 54 percent. Here it becomes an explicit, structured mechanism rather than a lucky cleanup.

Jane: So forward stage brings in new knowledge that's actually verified, and the backward stage prunes what turned out to be dead weight. They work on different timescales, which is the whole point of the framework.

Page 3 of the paper: Tom: So they finally take the method apart on this page. The headline for me is that removing the Prox cleanup stage hurts more than removing the closed-loop diagnosis. The full system gets 54 point 5, without the diagnosis it drops to 53, and without Prox it drops further to 52.

Jane: Wait, I'd have guessed the reverse. The forward loop is what catches bad edits in real time.

Tom: That's what I thought too, but the numbers say otherwise. Their interpretation is that Prox needs a well-optimized forward skill to shrink. If you run the backward cleanup on a poorly evolved skill, there's not enough useful knowledge to consolidate, so compression has less to work with.

Jane: Then the two stages are truly complementary, not just additive. They also report the lowest variance with both stages, plus or minus half a point. That suggests the combination makes the runs stable across seeds, which matters for reproducibility.

Tom: Now the tau sweep is the other new piece on this page. They vary the candidate threshold and plot compression against accuracy, and here's the striking part: at their default setting they get 52 point 3 percent accuracy while cutting the skill by 25 point 7 percent. Even at 74 point 9 percent compression, accuracy only falls to 51 point 0.

Jane: So a lot of the skill text was redundant or even harmful. I assume the curve turns downward somewhere, though.

Tom: It does, past roughly eighty percent compression. They're explicit that tau is a threshold-induced trade-off curve rather than a strict regularization path. You get a Pareto frontier where you can pick a compression level without sacrificing much accuracy.

Jane: Then the model size comparison — that's a nice practical detail. The 4B model ends up with a skill about forty-five percent longer than the 27B model, mostly in reference files, while the main skill files are nearly identical in length.

Tom: Exactly, both main files hover around fifteen thousand characters. But the 4B writes twice as much reference content, which the paper reads as smaller models needing more supplementary guidance. And the 4B also gets compressed more aggressively, about twenty-nine percent versus nineteen for the larger model.

Jane: That fits the update dynamics from earlier — smaller models write to the skill more often and get rejected more at the gate. On this page they add that within the 27B runs, longer final skills correlate negatively with accuracy. So the extra text isn't earning its keep.

Tom: Which is a useful reality check for anyone building agent skills. You want the skill to be exactly as long as it needs to be, and this method gives you a way to find that point empirically instead of guessing.

Page 4 of the paper: Tom: Page ten is where the paper finally shows you the two concrete failure modes that motivated the whole design, and honestly, the examples are striking.

Jane: Oh good, because the method section was pretty abstract. What did they actually observe?

Tom: In the forward case, they watched an open-loop training run hit a bug with a sequential scan where the reference value keeps changing. The diagnosis looked reasonable, so the skill just wrote a meta-instruction saying "trace a concrete example before coding," plus a template with the threshold 1 point 10 hard-coded into it.

Jane: And that template had negative utility when they measured it?

Tom: Exactly. The leave-one-out audit gave it a cell utility of minus 0 point 0337 and hard utility of minus 0 point 0556. The closed-loop version learned something different: update the reference to the current value after each qualifying event. That formulation flipped the sign to plus 0 point 0495 and plus 0 point 0474.

Jane: So the same underlying mistake produced completely different knowledge depending on whether you re-executed the patch before committing it.

Tom: Right, and the difference is actionability. "Trace carefully" doesn't change behavior, but "update the reference after each event" does, so the gate can actually test it.

Jane: Then the backward motivation shows why re-execution alone isn't enough, doesn't it?

Tom: It does. Even the closed-loop skill still contained two negative-utility units, and the instruction "trace a concrete example before coding" showed up in four separate sections, with utilities ranging from plus 0 point 1038 all the way down to minus 0 point 0337.

Jane: So the same sentence can be genuinely useful in one place and actively harmful in another. That's a mess.

Tom: The Prox stage found five candidate units in that run, but only one edit actually passed the validation gate. It removed the task-specific template and consolidated the transferable principle into a positive-utility section.

Jane: And that one accepted edit compressed the skill from 29,129 characters to 28,219, which is about 3 point 12 percent, and pushed validation cell accuracy from 96 point 05 percent to 99 point 73 percent? That's a huge jump for such a small change.

Tom: It is, and I love how they summarize the division of labor at the end of the page: closed-loop forward is online update verification, and backward Prox is post-training utility refinement. One decides how knowledge gets introduced, the other decides what survives after accumulation.

Jane: That really clarifies why you need both stages, rather than just one clever trick.

Page 5 of the paper: Tom: Page thirteen gives us the ten-seed comparison on Qwen3 point 6-27B, and the headline isn't really the average gain. Closed-loop evolution improves hard accuracy by 1 point 1 points on average, but the standard deviation drops from 2 point 50 to 1 point 51, and the worst seed climbs from 46 to 49. That's the stability story.

Jane: So the real win is that the bad runs get rescued, not that the good runs get better.

Tom: Exactly. Seed eight is the clearest case: it's the weakest open-loop run at 46 hard accuracy, and closed-loop brings it to 51. The paper notes that result sits right near the closed-loop mean, so it's lifting the lower tail, not stretching the upper bound. They also flag a negative 0 point 80 correlation between open-loop accuracy and improvement, but they immediately caution that this is partly mathematical coupling.

Jane: Good, because that number would be easy to over-read. Then they get into the process difference, which is more concrete: open-loop commits every patch without re-executing the updated skill, and all ten patches in the seed-eight run were committed blindly. Closed-loop re-executes the same four-task batch after each patch and only accepts if hard accuracy doesn't drop and cell accuracy stays within a tiny tolerance.

Tom: And the gate trace from that run shows 22 attempted edits with 8 regressions blocked, and one entire iteration got reverted. So that's direct evidence the mechanism actually catches bad edits.

Jane: The other thing that stands out is feedback. Open-loop diagnosis gets no outcome signal at all, so later diagnoses can't learn from what failed earlier. Closed-loop injects both a within-iteration rejection context and a cross-iteration prior of the last six accept or reject records.

Tom: Right, so the diagnosis itself is evolving along with the skill. That's what makes the forward loop closed in a real sense, and it connects back to the earlier discussion of unverified updates. Here we see the update gate working in practice, with specific numbers from a specific run.

Page 6 of the paper: Tom: This page gives the concrete numbers from that seed 8 case study. We see the single accepted Prox edit reduce the complete skill by 3 point 12 percent, from 29,129 to 28,219 characters. Validation cell accuracy improved from 96 point 05 percent to 99 point 73 percent.

Jane: Did validation hard accuracy stay put through that?

Tom: It stayed at 94 point 74 percent. Then on the independent OJ evaluation, hard accuracy went from 46 percent to 54 percent. Mean cell accuracy went from 74 point 71 percent to 77 point 97 percent. That's the kind of jump that explains why removing Prox in the ablation cost us 2 point 5 points.

Jane: The table lists eight tasks flipping from fail to pass, and none going the other way.

Tom: Each row spells out the behavioral difference. One task now determines debit/credit sign direction correctly. Another handles cutoff times crossing midnight. Another identifies the true data range B3:B36. These are the spreadsheet behaviors you'd hope a skill would teach.

Jane: And they're honest about what this does and doesn't prove.

Tom: Right. They note the OJ conditions are independent generations at temperature 0 point 7, not paired rerolls, so you can't say the edit alone caused each transition. They even exclude one fail-to-pass because it was an API error in the pre-Prox condition.

Jane: So the strong claim stays local.

Tom: Exactly. Validation-gated Prox removed a negative-utility template and consolidated the transferable principle. It did that without degrading validation performance. That's the part they can defend.

Page 7 of the paper: Tom: Page 19 is where the paper shows the actual prompts that run the forward loop, and the momentum agent is the one that caught my eye. It reads the batch diagnoses plus a memory file from previous iterations, then turns each failure into a pattern—the prompt literally says "a pattern is a class of mistake or success, not a task instance."

Jane: That means the skill doesn't learn a fix for one spreadsheet, it learns a fix for a whole category of spreadsheet problems. And the momentum agent keeps a "remedy_log" that's append-only history, so it remembers what was tried before and what actually worked.

Tom: The patcher prompt then takes that pattern record and insists on iterating by pattern, not by task. It tells the model to group overlay entries sharing a pattern, brainstorm two to three candidate remedies, and apply the simplest edit that generalizes.

Jane: Wait, so the patcher is allowed to brainstorm multiple options? That's a big step beyond just writing down the first diagnosis that comes along.

Tom: Exactly. And it explains why the closed-loop gate works so well—you're not just testing a random edit, you're testing one of several deliberately chosen remedies. The prompt also orders the patcher to prefer extending an existing section over creating a new one, which keeps the skill from ballooning in size.

Jane: There's a hard structural rule in there too, though. The patcher is told never to put task-specific columns, rows, filenames, or constants into the main skill file, and every reference file must have exactly one L2 pointer.

Tom: Right, that's what makes the leave-one-out audit possible in the backward stage. Each reference file is a cleanly separable unit, so you can remove it and measure the effect without breaking the rest of the skill.

Jane: The prompt even tells the patcher to read back all changed files after editing and repair broken pointers, orphaned references, and duplicate sections. That cleanup step keeps the skill structurally valid, which the validation gate depends on.

Tom: And that's the engineering behind the results we saw earlier—the lower variance across seeds and the consistent gains. It's a very deliberate way of forcing the model to consolidate knowledge rather than accumulate every diagnosis as a new rule.

Jane: What strikes me is how much of the method lives in these prompts. The forward-backward framework is the math, but page 19 is where the framework becomes executable instructions.

Conclusion: Tom: So putting it all together, SkillProx is really about treating a skill as something you can optimize rather than just write once and hope for the best.

Jane: Exactly. The forward loop checks whether an edit actually helps before keeping it, and the backward loop cleans out the knowledge that turned out to be dead weight.

Tom: That combination is what makes the gains hold up across different models and even on out-of-distribution tasks, which is the part I find most impressive.

Jane: Me too. The skills were only trained on spreadsheets, yet they still helped on WikiTQ and HiTab. That suggests the method is capturing genuinely transferable procedures, not just memorizing task patterns.

Tom: And there's a nice practical angle, too. Smaller models benefit disproportionately because the gate and the pruning step act as an external filter they wouldn't have on their own.

Jane: That's a big deal for deployment. You can get better behavior from a cheaper model without any weight updates, just by giving it a better-maintained skill file.

Tom: It also reframes how we think about skill growth. Bigger isn't better; the paper shows that carefully shrinking a skill can improve accuracy while cutting a quarter or more of its text.

Jane: Right, the compression–accuracy curve is striking. You can remove a lot of redundant content before performance ever starts to dip.

Tom: So the takeaway really is that self-evolving agents need both verification and consolidation, not just endless patching. SkillProx gives a clean framework for both.

Jane: And the authors are releasing the code, so other people can build on it. That should accelerate a lot of follow-up work in agent memory and skill management.

Tom: Great note to end on. Thanks to everyone listening, and we'll be right back with the next paper.