Cuándo no crear una skill: procesos que necesitaban automatizarse, no empaquetarse

Esperábamos que las skills nos ahorraran trabajo en procesos internos de la empresa, y en bastantes casos hicieron lo contrario: añadieron una capa más a algo que ya era confuso. Muchas skills que parecían buena idea al principio terminaron siendo complejidad innecesaria encima de procesos que lo que necesitaban era estar definidos o automatizados.

No fue un fallo técnico. Las skills se activaban, el agente seguía las instrucciones y el resultado era razonable. El problema estaba antes: habíamos elegido la herramienta equivocada para el problema.

Por qué una skill parece siempre buena idea

Crear una skill es barato. Escribes un SKILL.md, describes el proceso, lo instalas y el agente ya sabe hacerlo. Cuando un equipo descubre esto, cualquier tarea repetitiva parece candidata, y la tentación se refuerza porque el resultado se ve enseguida: le pides algo al agente y lo hace.

Lo que no se ve tan rápido es lo que has dejado de hacer. Si un proceso nunca se había escrito con claridad, empaquetarlo en una skill no lo define; traslada la ambigüedad a un sitio donde la resuelve el modelo, cada vez, a su manera. Y si un proceso es siempre igual, meterlo en una skill convierte algo determinista en algo probabilístico.

Tres herramientas distintas para tres problemas distintos

Con el tiempo he acabado separando tres cosas que al principio mezclábamos.

Un procedimiento es un proceso escrito para personas: quién hace qué, en qué orden, con qué criterios y qué hacer cuando algo sale mal. Muchos procesos de empresa fallan porque nadie lo ha escrito, y eso no lo arregla ninguna herramienta. Primero hay que decidir cómo se hace.

Una automatización es un script, un pipeline o un job que ejecuta siempre lo mismo. Si los pasos no cambian y las decisiones se pueden expresar como reglas, un script es más rápido, más barato y más fiable que un agente. Se puede testear, versionar y revisar en un PR. En el trabajo usamos cada vez menos n8n por este motivo: con IA un script sale en minutos y, dockerizado, se despliega como cualquier otro servicio. La IA ayuda a escribir la automatización, pero no tiene por qué ejecutarla.

Una skill tiene sentido cuando la tarea requiere criterio y el agente no lo tiene: interpretar una petición ambigua, elegir entre opciones según el contexto, trabajar sobre un dominio que el modelo no conoce. La skill de Illuminate es un buen ejemplo: cada consulta SQL que pide un usuario es distinta, y lo que aporta la skill es el esquema y las reglas para no inventar tablas. Eso no se puede reducir a un script.

Señales de que una skill es la respuesta equivocada

No tengo una regla infalible, pero sí algunas preguntas que ahora me hago antes de proponer una skill nueva.

¿Los pasos son siempre los mismos? Si la skill describe una secuencia fija sin decisiones, lo que estás pidiendo es que el agente actúe como un script, con más coste y menos garantías. Escribe el script; si hace falta, que el agente lo invoque.

¿Alguien podría explicar el proceso en cinco minutos? Si nadie puede, la skill va a codificar la confusión actual. Por ejemplo, una skill que diga “revisa con el responsable si el cliente tiene condiciones especiales” en un proceso donde nadie sabe quién es el responsable no ayuda al agente; documenta un hueco.

¿La skill está compensando un problema de otra parte? A veces la skill existe porque una herramienta interna es incómoda o un formato está mal diseñado, y el agente sirve de intérprete. Es más útil arreglar el origen.

¿Cuánta gente la usaría? Una skill que solo resuelve un caso que aparece dos veces al año ocupa su sitio en el contexto de todas las sesiones a cambio de muy poco.

El coste que no se ve: las skills se pisan

Cada skill instalada añade su descripción al contexto del agente, y cada descripción compite con las demás por activarse. Con pocas skills no se nota. Cuando un equipo va añadiendo sin criterio, aparecen descripciones parecidas que reclaman la misma petición, activaciones donde no tocaba y sesiones más pesadas sin que nadie haya cambiado nada concreto.

En nuestro caso, el marketplace que usamos en el departamento tiene un ciclo continuo de mejora: vamos añadiendo skills y comandos a medida que aparecen necesidades. Lo que hemos aprendido es que lo difícil no es actualizar, sino mantener orden. Hace falta que alguien lidere qué entra y qué no, una guía de cuándo algo merece ser skill y una revisión de que las nuevas no se solapan con las que ya existen. Sin eso, el marketplace crece y el agente funciona peor.

Las evals de activación ayudan a detectar solapamientos: si una petición activa dos skills, alguna de las dos descripciones está mal acotada o sobra una de ellas. Pero la decisión de no crear una skill es anterior a cualquier eval y es organizativa.

Lo que haría desde el principio

Antes de crear una skill, escribiría el procedimiento en un documento normal. Si al escribirlo descubro que los pasos son fijos, lo convertiría en un script. Si descubro que nadie sabe cómo se hace, el trabajo pendiente es decidirlo, no empaquetarlo. Solo si queda una parte que requiere criterio sobre un conocimiento que el modelo no tiene, esa parte sería una skill, y probablemente más pequeña de lo que habría escrito al principio.

Las skills son una buena herramienta, y en esta serie hay varios artículos sobre cómo construirlas bien. Pero el criterio de agent skills en un equipo incluye saber cuándo la respuesta es otra, y en procesos de empresa lo ha sido más veces de las que esperaba. Si dudas entre una skill y un script para un proceso concreto, escribe primero el script: si se queda corto, sabrás exactamente qué parte necesita criterio.