SkillProx: Teaching Agent Skills to Shrink, Not Just Grow

Paper: 2608.07449 Authors: Mingxuan Zheng, Yujin Zhou, Chuxue Cao, Boqin Yin, Yuyao Zhang, Jiapeng Sun, Shuaishuai Gong, Sirui Han, Yike Guo Categories: cs.AI, cs.CL

The Gap

The current mainstream for “agents that get better without fine-tuning” is text-space self-improvement. You keep a textual artifact (call it a skill, a playbook, a cheatsheet, a memory) that gets loaded into context. The agent runs a task, fails, an LLM diagnoses why, and that diagnosis becomes an edit to the artifact. TextGrad-style “textual gradients,” Reflexion-style verbal reinforcement, ExpeL, Voyager’s skill library, Dynamic Cheatsheet, and the recent context-engineering line all live in this space.

Two things in that loop are quietly broken.

First, the loop is open. The diagnoser says “you failed because you forgot to normalize units,” the edit is applied, and then the pipeline moves on to the next batch. Nobody ever checks whether that specific edit made the agent better on the tasks it was supposed to fix. So bad edits persist, and worse, the diagnoser never learns which of its own diagnoses were correct — it keeps generating plausible-sounding explanations with zero feedback signal.

Second, deletion is a second-class citizen. Existing frameworks expose “edit the text” as one operation, and removing a line is just one more way to edit. In practice this means artifacts monotonically bloat: redundant rules, task-specific overfitted hacks, and outright harmful instructions accumulate because nothing is ever measured for its individual contribution. The context window becomes a landfill, and retrieval/attention degrades.

SkillProx’s claim is that these two holes are the same hole viewed from two sides, and that the proximal-gradient template from convex optimization gives you the right shape to fill both.

PROBLEM: text-space skill evolution both drifts and bloats
   |
   +-- prior work: diagnose -> edit -> move on   (open loop, unverified)
   +-- prior work: delete == yet another edit    (no consolidation step)
   |
   v
ASSUMPTION: skill quality ~ task_loss + lambda * skill_complexity
   and the value of any single edit or line is measurable
   by re-executing with a frozen agent
   |
   v
METHOD: forward step  = diagnose, edit, RE-RUN same batch,
                        roll back regressions, report outcome
                        back into the next diagnosis
        backward step = split skill into units, leave-one-out
                        utility audit, validation-gated
                        merge / demote / remove
   |
   v
EVIDENCE: +3.0 pp average accuracy vs strongest gradient-based
          baseline; in-distribution and OOD; multiple backbones;
          ablations show the two stages are complementary
   |
   v
CONCLUSION: measured edits plus first-class deletion beat
            a larger unaudited pile of text

The Increment

One sentence: Before, a skill artifact grew by unverified LLM-proposed edits; after, every edit must survive a re-run on the batch it claimed to fix, and every surviving line must justify its own existence in a leave-one-out audit.

Core Mechanism

The framing is proximal gradient descent. In convex optimization, when you minimize smooth_loss(x) + lambda * penalty(x), you alternate: take a gradient step on the smooth part, then apply a proximal operator that pulls the result back toward simplicity (for an L1 penalty, that operator is soft thresholding — it literally zeroes out small coordinates). SkillProx maps this onto text. The forward stage is the gradient step: diagnosis-driven edits that reduce task loss. The backward stage is the proximal operator: shrink the artifact, zeroing out the “coordinates” (knowledge units) whose measured contribution is near zero or negative.

The forward stage’s distinguishing move is re-execution on the same batch. Run the agent with skill S, record score. Diagnose, propose an edit, apply it to get S', then run the agent again on that identical batch. If the score went down, roll back — the edit is discarded. Either way, the measured outcome (“your fix for the unit-normalization failure moved accuracy from 0.62 to 0.58”) is written back into the context of the next diagnosis. That turns the diagnoser from a one-shot commentator into something closer to a learner with a reward signal: it sees which of its hypotheses paid off.

The backward stage does credit assignment inside the artifact. The skill is decomposed into auditable knowledge units — discrete, individually addressable claims or procedures rather than one blob of prose. Then, with the executor frozen (same model, same decoding, nothing else changing), each unit is removed one at a time and the batch is re-run. The accuracy delta is that unit’s estimated utility. High-utility units are kept. Near-zero units get consolidated into a sibling or demoted to an archive tier instead of hard-deleted. Negative-utility units are removed outright. Finally, the whole trimmed artifact has to pass a validation gate: if the compressed skill scores worse on held-out validation, the compression is rejected. That gate is what keeps the shrink step from being a fancy way to delete useful knowledge.

    task batch B                       skill S_t = units u1..un
         |                                        |
         +-------------------+--------------------+
                             v
             [ FORWARD STEP : the "gradient" ]

    run agent(S_t, B) --------------------> score_0
         |
         v
    diagnose failures ---> proposed edit e
         |
         v
    S' = apply(e, S_t) ;  re-run agent(S', B) --> score_1
         |
         +--- score_1 > score_0 ? ---- yes ---> accept S'
         |                       |
         |                       +---- no ----> ROLLBACK to S_t
         |                                          |
         +------------> outcome record <------------+
                             |
         (fed into the NEXT diagnosis == closed loop)
                             v
             [ BACKWARD STEP : the "prox" / shrink ]

    decompose:   [u1] [u2] [u3] [u4] [u5] ... [un]
                   |    |    |    |    |
                   v    v    v    v    v
    frozen executor, leave-one-out re-runs:
        util(ui) = score(S) - score(S without ui)
                   |
      +------------+------------+-------------+
      v                         v             v
   util high                util ~ 0      util < 0
    KEEP                 MERGE or DEMOTE    REMOVE
      |                         |             |
      +------------+------------+-------------+
                   v
        validation gate: accept trimmed S only if
        held-out score is not worse
                   v
                 S_t+1

Here’s the load-bearing analogy: an aviation checklist and its two review boards.

The skill artifact is the cockpit checklist. Each knowledge unit is one line on it. The task batch is a set of simulator scenarios.

The incident review board is the forward stage. After a crash in the simulator, investigators write up a cause (“the crew didn’t cross-check the altimeter”) and add a line to the checklist. In today’s methods, that’s where it ends — the new line ships, and the board moves to the next incident. SkillProx makes the board re-fly the exact same scenarios with the amended checklist. If the crash rate goes up — maybe the extra line pushed a critical item off the pilot’s attention — the amendment is struck from the record. And crucially, the board is told the outcome of its last amendment before it writes the next one, so it stops repeating the kinds of fixes that never worked.

The checklist hygiene board is the backward stage. Checklists bloat; every incident adds a line and nothing ever removes one, until pilots start skimming. So this board takes each line, covers it up, and re-flies the scenarios with the same pilot (frozen executor — you don’t get to swap in a better pilot, or the measurement means nothing). Lines whose removal changes nothing get merged into a neighboring item or moved to the reference appendix rather than shredded. Lines whose removal improves safety get deleted — they were actively misleading. And the trimmed checklist doesn’t go into service until it passes a certification flight on scenarios the board didn’t use for trimming.

Tell someone that story and they can reconstruct the paper. The “proximal gradient” vocabulary is the mathematician’s name for “incident board plus hygiene board.”

Key Concepts

• Proximal gradient descent, without the math: Suppose you want a model that fits data *and is simple. You write down a single score: error plus a penalty on size. Rather than optimizing that mess directly, you split the work. Step one: improve the fit, ignoring size. Step two: apply a fixed shrinking rule that pulls everything back toward zero and snaps small values exactly to zero. Repeat. This is how LASSO gets sparse solutions. The key property is that the shrinking step is a separate, dedicated operation — not something you hope the fitting step will do incidentally. SkillProx’s whole argument is that prior work only has step one, and expects sparsity to emerge from a generic “you may also delete text” affordance. It doesn’t. Big caveat: text edits are not gradients and there is no proximal operator here in any formal sense, so this is a design template, not a theorem.

• Leave-one-out utility audit with a frozen executor: How do you know whether line 7 of your prompt is earning its tokens? Delete it, run the same tasks with the same model at the same temperature, and see what happens to accuracy. If nothing changes, the line is decoration. If accuracy *rises, the line was hurting you. This is just ablation, but applied at the granularity of individual statements inside a living artifact, and used as a control signal rather than a paper table. “Frozen” is the load-bearing word: if the executor changes between measurements, you can’t attribute the delta to the line. The cost is the obvious problem — auditing n units means n extra batch runs.

• Closed-loop diagnosis: A doctor who writes prescriptions and never sees the patient again will keep writing confident, plausible, wrong prescriptions forever. An LLM asked “why did this trajectory fail?” produces fluent causal stories; fluency is uncorrelated with correctness. Feeding the measured outcome of the previous edit back into the next diagnosis prompt is the cheapest possible fix: the diagnoser now has evidence about its own track record in context. Not gradient descent, not RL — just refusing to let the critic operate without a scoreboard.

Framework Shift

Before (mainstream approach):          After (this paper):

  +-------------------+                 +-------------------+
  |  run task batch   |                 |  run task batch   |
  +-------------------+                 +-------------------+
          |                                     |
          v                                     v
  +-------------------+                 +-------------------+
  |  LLM diagnoses    |                 |  LLM diagnoses    |<--+
  +-------------------+                 |  (sees outcome of |   |
          |                             |   its last edit)  |   |
          v                             +-------------------+   |
  +-------------------+                         |               |
  |  apply text edit  |                         v               |
  |  (delete = one    |                 +-------------------+   |
  |   edit among many)|                 | apply edit, RERUN |   |
  +-------------------+                 | SAME batch        |   |
          |                             +-------------------+   |
          v                                 |          |        |
  +-------------------+                 worse|          |better  |
  |   next batch      |                      v          v       |
  +-------------------+                 ROLLBACK    ACCEPT      |
                                            |          |        |
  skill over time:                          +----+-----+--------+
  [u1]                                           v
  [u1][u2]                              +-------------------+
  [u1][u2][u3]                          |  SHRINK STEP      |
  [u1][u2][u3][u4]                      |  LOO audit each   |
  [u1][u2][u3][u4][u5] ...              |  unit, merge /    |
                                        |  demote / remove, |
  monotone growth, nothing              |  validation gate  |
  ever measured individually            +-------------------+
                                                 v
                                        skill over time:
                                        [u1][u2][u3][u4][u5]
                                        [u1][u2+u4][u5]
                                        [u1][u2+u4][u5][u6]
                                        [u1][u2+u4+u6]
                                        (archive: u3, u7)

                                        grows and shrinks,
                                        every unit priced

From accumulating text to maintaining a measured portfolio of text, the core shift is that both writing and deleting now require a receipt — an observed accuracy delta on a re-run batch.

Expert Assessment

A note on calibration: I’m working from the abstract, so my read on experimental details is inference about what the setup likely looks like, not verification of tables I’ve inspected.

Problem choice: Real gap, and well-chosen within a crowded neighborhood. Context/skill engineering exploded through 2025 — cheatsheets, playbooks, agentic context engineering, evolving prompt libraries — and nearly all of it has the same two pathologies the paper names. The observation that these systems have no mechanism for *contraction is correct and slightly embarrassing for the field; we spent a decade internalizing that regularization is not optional in parameter space and then rebuilt the same optimizer in text space with no penalty term. Naming deletion as a first-class operator rather than an edit type is the paper’s sharpest contribution. That said, the ingredients aren’t new individually: accept-if-improved hill climbing, rollback, ablation-based credit assignment, and validation gating are all standard. This is a careful assembly, not a new idea.

Method maturity: Clever assembly with a bolted-on theory costume. The proximal-gradient framing genuinely organizes the design — it tells you *why you need a separate shrink step — but there’s no metric space, no operator, no convergence claim, and almost certainly no way to actually set the complexity weight lambda in a principled way. Readers should treat “proximal-gradient-inspired” as an architecture diagram, not a guarantee. The real cost concern is compute: the forward stage doubles executions per edit (run, edit, re-run), and the backward stage adds roughly one batch run per knowledge unit. On an artifact with 40 units, an audit round is 40 batch re-runs. That’s a substantial multiplier over baselines that just edit and move on. Simpler things I’d want to see ruled out: (a) plain hill climbing with rollback and no audit at all — how much of the 3.0 pp is just “don’t keep edits that hurt”? (b) a hard token budget on the skill with an LLM asked to rewrite within the budget; (c) usage-frequency pruning, which is nearly free compared to leave-one-out. The ablations reportedly cover the two stages, but “closed loop vs open loop” and “audit vs cheap heuristic pruning” are different questions.

Experimental integrity: The honest signal is that 3.0 pp average over the strongest gradient-based baseline is a modest, believable number — nobody fabricating results claims 3.0. Including OOD evaluation and multiple backbones is the right instinct, since text-space skill methods notoriously overfit to their tuning batch. Three things I’d scrutinize. First, variance: these pipelines are wildly seed-sensitive because a single LLM edit can swing a batch, and a 3.0 pp mean without multi-seed error bars is fragile. Second, compute parity: if baselines aren’t given the same number of LLM calls, SkillProx is partly buying its gain with budget, and the honest comparison is accuracy-per-call. Third, the validation gate — if the same held-out set gates every consolidation across many rounds, it’s been optimized against, and its “held-out” status is nominal. Also, “average accuracy” across benchmarks can conceal per-benchmark regressions, which matters a lot for a method whose selling point is not regressing.

Writing quality: The abstract is disciplined and the mechanism is legible, which is more than most papers in this area manage. The corner-cutting is in the objective. “Motivated by a composite objective balancing task loss and skill complexity” is doing a lot of hand-waving — the objective is never optimized, it’s a mood. The section I’d rewrite is exactly that one: state the objective, then state plainly which parts of the algorithm are principled instantiations and which are heuristics wearing the notation. Second priority: a cost-normalized results table. A paper that adds this many extra LLM calls and doesn’t foreground the accuracy/compute tradeoff invites the reviewer to assume the worst.

Verdict: weak accept — the mechanism (regression rollback plus dedicated audit-driven deletion) is genuinely useful and under-explored, but the gains are modest, the theoretical framing is decorative, and the compute overhead is the elephant the abstract doesn’t address.

Takeaways

Concrete things worth stealing, roughly in order of value-per-effort:

• Re-run the same batch after every edit, and roll back regressions. This is nearly trivial to add to any prompt- or playbook-optimization loop and it’s my bet for where most of the paper’s gain comes from. You already have the batch loaded; the marginal cost is one extra pass.
• Put the outcome of your last edit into the next critic prompt. If you’re using an LLM to diagnose failures, it is currently guessing without a scoreboard. Two lines of prompt plumbing — “your previous change was X; accuracy went from 0.62 to 0.58” — converts a fluent storyteller into something with feedback. This transfers to any LLM-as-critic setup, not just skills.
• Make your text artifact addressable. You cannot prune prose. If your system prompt, tool documentation, or memory store is one blob, no audit mechanism can attach to it. Store it as enumerated units with stable IDs from day one, even if you never audit them — this is a cheap structural decision with a large option value.
• Leave-one-out ablation as a control signal, not a paper table. Removing one chunk and re-running with a frozen model is a general credit-assignment primitive. It applies to RAG chunks, few-shot exemplars, tool descriptions, and system prompt sections. Budget it: it’s O(units) runs, so sample units or run it on a schedule rather than every round.
• A demotion tier beats binary keep/delete. Moving low-utility units to an archive that can be recalled later is strictly safer than deletion when your utility estimates are noisy — and with batch-level accuracy deltas on a handful of tasks, they are very noisy. This is a good default for any lossy-compression-of-knowledge problem.
• The framing itself: any self-improving text system needs an explicit complexity penalty and a dedicated contraction operator, or it will monotonically bloat. That’s a design rule you can carry into agent memory, documentation maintenance, and prompt libraries regardless of whether you adopt this paper’s specific machinery.