Quan no crear una skill: processos que calia automatitzar, no empaquetar

Esperàvem que les skills ens estalviessin feina en processos interns de l’empresa, i en força casos van fer el contrari: van afegir una capa més a una cosa que ja era confusa. Moltes skills que semblaven bona idea al principi van acabar sent complexitat innecessària damunt de processos que el que necessitaven era estar definits o automatitzats.

No va ser un error tècnic. Les skills s’activaven, l’agent seguia les instruccions i el resultat era raonable. El problema venia d’abans: havíem triat l’eina equivocada per al problema.

Per què una skill sempre sembla bona idea

Crear una skill és barat. Escrius un SKILL.md, descrius el procés, l’instal·les i l’agent ja sap fer-ho. Quan un equip ho descobreix, qualsevol tasca repetitiva sembla candidata, i la temptació es reforça perquè el resultat es veu de seguida: demanes una cosa a l’agent i la fa.

El que no es veu tan de pressa és el que has deixat de fer. Si un procés no s’havia escrit mai amb claredat, empaquetar-lo en una skill no el defineix; trasllada l’ambigüitat a un lloc on la resol el model, cada vegada, a la seva manera. I si un procés és sempre igual, ficar-lo en una skill converteix una cosa determinista en una de probabilística.

Tres eines diferents per a tres problemes diferents

Amb el temps he acabat separant tres coses que al principi barrejàvem.

Un procediment és un procés escrit per a persones: qui fa què, en quin ordre, amb quins criteris i què cal fer quan alguna cosa surt malament. Molts processos d’empresa fallen perquè ningú no l’ha escrit, i això no ho arregla cap eina. Primer cal decidir com es fa.

Una automatització és un script, un pipeline o un job que executa sempre el mateix. Si els passos no canvien i les decisions es poden expressar com a regles, un script és més ràpid, més barat i més fiable que un agent. Es pot testejar, versionar i revisar en un PR. A la feina fem servir n8n cada vegada menys per aquest motiu: amb IA un script surt en minuts i, dockeritzat, es desplega com qualsevol altre servei. La IA ajuda a escriure l’automatització, però no cal que l’executi.

Una skill té sentit quan la tasca requereix criteri i l’agent no en té: interpretar una petició ambigua, triar entre opcions segons el context, treballar sobre un domini que el model no coneix. La skill d’Illuminate n’és un bon exemple: cada consulta SQL que demana un usuari és diferent, i el que aporta la skill és l’esquema i les regles per no inventar-se taules. Això no es pot reduir a un script.

Senyals que una skill és la resposta equivocada

No tinc cap regla infal·lible, però sí algunes preguntes que ara em faig abans de proposar una skill nova.

Els passos són sempre els mateixos? Si la skill descriu una seqüència fixa sense decisions, el que estàs demanant és que l’agent actuï com un script, amb més cost i menys garanties. Escriu l’script; si cal, que l’agent l’invoqui.

Algú podria explicar el procés en cinc minuts? Si ningú no pot, la skill codificarà la confusió actual. Per exemple, una skill que digui “comprova amb el responsable si el client té condicions especials” en un procés on ningú no sap qui és el responsable no ajuda l’agent; documenta un forat.

La skill està compensant un problema d’una altra banda? De vegades la skill existeix perquè una eina interna és incòmoda o un format està mal dissenyat, i l’agent fa d’intèrpret. És més útil arreglar l’origen.

Quanta gent la faria servir? Una skill que només resol un cas que apareix dues vegades l’any ocupa el seu lloc al context de totes les sessions a canvi de molt poc.

El cost que no es veu: les skills es trepitgen

Cada skill instal·lada afegeix la seva descripció al context de l’agent, i cada descripció competeix amb les altres per activar-se. Amb poques skills no es nota. Quan un equip en va afegint sense criteri, apareixen descripcions semblants que reclamen la mateixa petició, activacions on no tocava i sessions més pesades sense que ningú hagi canviat res de concret.

En el nostre cas, el marketplace que fem servir al departament té un cicle continu de millora: hi anem afegint skills i comandes a mesura que apareixen necessitats. El que hem après és que el difícil no és actualitzar, sinó mantenir l’ordre. Cal que algú lideri què hi entra i què no, una guia de quan una cosa mereix ser una skill i una revisió que les noves no se solapin amb les que ja existeixen. Sense això, el marketplace creix i l’agent funciona pitjor.

Les evals d’activació ajuden a detectar solapaments: si una petició activa dues skills, alguna de les dues descripcions està mal acotada o en sobra una. Però la decisió de no crear una skill és anterior a qualsevol eval i és organitzativa.

El que faria des del principi

Abans de crear una skill, escriuria el procediment en un document normal. Si en escriure’l descobreixo que els passos són fixos, el convertiria en un script. Si descobreixo que ningú no sap com es fa, la feina pendent és decidir-ho, no empaquetar-ho. Només si queda una part que requereix criteri sobre un coneixement que el model no té, aquella part seria una skill, i probablement més petita del que hauria escrit al principi.

Les skills són una bona eina, i en aquesta sèrie hi ha diversos articles sobre com construir-les bé. Però el criteri d’agent skills en un equip inclou saber quan la resposta és una altra, i en processos d’empresa ho ha estat més vegades del que m’esperava. Si dubtes entre una skill i un script per a un procés concret, escriu primer l’script: si es queda curt, sabràs exactament quina part necessita criteri.