Il presupposto che una skill sia una skill, indipendente dal modello che la esegue, non regge. In un'analisi su sette modelli e tre benchmark, i ricercatori hanno individuato 103 coppie compito-skill in cui la stessa skill migliora GPT-5.6-luna di 31,1 punti ma degrada Gemma-4-E4B di 8,8 punti. Il divario non è un semplice effetto di scala: è un problema di eseguibilità.

Il dato più rilevante è un altro: nell'86% dei casi in cui i modelli deboli falliscono, il requisito violato era già scritto nella skill. Non è quindi una questione di conoscenza mancante. Il modello sa cosa dovrebbe fare, ma non riesce a tradurre quella guida in azioni. Questo cambia il modo in cui va progettata la self-evolution degli harness: non basta aggiungere istruzioni o arricchire le skill, bisogna riformularle in base alle capacità dell'esecutore.

Per affrontare il problema, i ricercatori hanno distinto quattro aree di fallimento: tool execution, context management, instruction following e verification. Da queste diagnosi hanno distillato una meta-skill fissa, usata come guida per l'adattamento. Un rewriter esterno più capace, Kimi-K3, ha adattato le skill senza bisogno di prove di esecuzione. Il risultato sui tre esecutori deboli è un miglioramento compreso tra 5,1 e 14,1 punti rispetto alle skill originali. In un loop di self-evolution a cinque round, in cui ogni modello rivede le proprie skill a partire dalle traiettorie di esecuzione e dal feedback di un verificatore, la meta-skill ha portato a miglioramenti finali tra 2,0 e 5,1 punti su sette esecutori, da Gemma-4-E4B a Kimi-K2.5.

La tesi che emerge è che le skill non sono artefatti portabili tra modelli, ma componenti che vanno "compilati" per l'esecutore. Nei framework per agenti, questo sposta il problema dal prompt engineering a una pipeline di adattamento: la skill generica diventa un input, il profilo di capacità del modello un vincolo, la skill adattata l'output. Per chi distribuisce agenti su modelli più piccoli in contesti self-hosted o con vincoli di risorse, l'implicazione è diretta: non si può riusare lo stesso catalogo di skill che funziona su un modello di fascia alta sperando che basti abbassare la temperatura o ridurre il contesto. La differenza non è solo quantitativa, ma qualitativa nell'esecuzione.

C'è anche un effetto di secondo ordine. L'approccio descritto usa un rewriter esterno più capace per adattare le skill. In un deployment on-premise questo introduce una domanda di architettura: l'adattamento deve restare sotto il proprio controllo, oppure è accettabile che una parte della pipeline dipenda da un modello esterno? La risposta non è neutra rispetto alla sovranità dei dati, perché le skill e le traiettorie di esecuzione possono contenere dettagli operativi sensibili. Una meta-skill fissa e verificabile, come quella descritta, è più semplice da audire rispetto a un processo di riscrittura completamente libero, ma non elimina il vincolo: se il rewriter è esterno, i dati gli passano comunque davanti. Per chi valuta questi trade-off in un contesto on-premise, AI-RADAR mette a disposizione framework analitici su /llm-onpremise.

Il messaggio strutturale per l'ecosistema è che la self-evolution degli harness non può essere trattata come un'unica routine valida per tutti. La variabilità tra esecutori è un problema di design, non un rumore da eliminare. Chi sviluppa framework per agenti dovrà probabilmente separare il piano della competenza dal piano dell'esecuzione: la prima può essere condivisa, la seconda va adattata al modello. È una distinzione che ricorda, per analogia, la separazione tra rappresentazione intermedia e ottimizzazione per architettura nei compilatori. Non è un dettaglio accademico: decide se un agente basato su un modello piccolo può svolgere un compito reale o fallire nonostante sappia esattamente cosa gli viene chiesto.