Deja de construir agentes, empieza a construir habilidades: cuatro reglas de los ingenieros de Anthropic

Los dos ingenieros detrás del formato Agent Skills en Anthropic, Barry Zhang y Mahesh Murag, han dejado de construir un agente separado para cada tarea. Su razonamiento es simple: el agente subyacente resultó mucho más polivalente de lo esperado, así que basta con vestir el mismo cuerpo con conocimientos específicos de cada trabajo. Para mí, esta es la corrección de rumbo más práctica del último año.

La analogía del teléfono lo resume en una línea: el modelo es el procesador, el runtime del agente es el sistema operativo, y la habilidad es la aplicación. Nadie ensambla un teléfono separado por aplicación; instalas la aplicación adecuada en el mismo dispositivo. Como Claude Code ya lee archivos, escribe código y llama a herramientas, el mismo cuerpo sirve para todo, desde presentaciones hasta investigación de empresas, y solo cambia la habilidad adjunta.

La primera regla es mi favorita: dejar de hacer que el modelo resuelva de nuevo problemas técnicos ya resueltos. El equipo vio a Claude reescribir casi el mismo script de Python desde cero cada vez que daba formato a diapositivas, lo quemaba tokens y producía un resultado distinto en cada ejecución. La solución fue almacenar el script funcional dentro de la carpeta de la habilidad para que las ejecuciones posteriores usaran directamente el archivo probado. El principio DRY del software, trasplantado aquí. Mi taller sigue el mismo patrón: nunca dejo que un script que produjo un resultado que me gustó se pudra dentro de un chat. La receta del vídeo coincide: guardar el script en la carpeta scripts de la habilidad, actualizar SKILL.md para que las ejecuciones futuras usen ese archivo, y luego ejecutar la misma tarea dos veces y comparar las partes importantes. La prosa circundante puede seguir variando, pero la pieza crítica ya no es una suposición nueva, es código probado.

La segunda regla resuelve el descubrimiento: cuando se acumulan decenas de habilidades, ¿cómo elige el modelo la correcta? La respuesta es una carga por etapas llamada divulgación progresiva: Claude primero ve solo el nombre y la descripción de cada habilidad, los metadatos YAML. Cuando la redacción de una solicitud coincide con una descripción, se lee el SKILL.md completo de esa habilidad, mientras los archivos complementarios grandes esperan en la carpeta hasta que sean realmente necesarios. Las instrucciones irrelevantes nunca inflan el contexto de trabajo.

Pero este mecanismo vive o muere según la claridad de las descripciones. Dos descripciones vagas como ayuda con contenido y producción de activos de marketing obligan al modelo a lanzar una moneda al aire. Una descripción fuerte indica el trabajo más las formulaciones reales de los usuarios que deberían activarla. La triple prueba del vídeo es práctica: una solicitud de activación obvia, la misma solicitud redactada de otra forma, y una solicitud no relacionada que nunca debe activarla. Una habilidad que no se puede encontrar, mejor que no exista.

La tercera regla hace permanentes las correcciones: cada ciclo de corregir-y-cerrar-el-chat tira una lección a la basura. Decir solo arréglalo repara el resultado pero deja el proceso roto. En su lugar, se pide al modelo que rastree el origen: dónde buscó, por qué falló, si hay que actualizar el enrutamiento o la habilidad. Un proceso erróneo significa actualizar las instrucciones, una voz o ejemplos faltantes significan añadir un archivo de referencia, un error repetido significa añadir una regla de bloqueo explícita. Luego se vuelve a ejecutar la misma tarea para verificar la corrección.

Aquí se traza un límite honesto: ninguna habilidad puede hacer que un modelo más débil rinda como uno más potente, porque cada modelo interpreta las instrucciones de forma distinta. Lo que viaja es el proceso. Como Agent Skills es un formato abierto, la misma carpeta puede probarse en runtimes compatibles, y donde falle hay que cazar supuestos ocultos. El anuncio del estándar abierto de diciembre de 2025 formalizó esta portabilidad.

La cuarta regla, presentada como la más importante: una habilidad nunca debe entregar su primer intento al usuario. Terminar el setenta por ciento de un trabajo y dejarle a un humano un archivo mal formateado y sin fuentes es el fallo más común. La cura consiste en incorporar en la habilidad las comprobaciones que ya conoces: renderizar las diapositivas visualmente y corregir desbordamientos, contrastar las afirmaciones de investigación con fuentes primarias y eliminar lo que no se pueda probar, leer los borradores con ojos de principiante y de escéptico. Mi patrón favorito se anuda en una frase: definir primero los criterios de aceptación, construir la versión uno, inspeccionarla con el método adecuado, corregir cada problema encontrado, hacer una segunda pasada, y retener el resultado hasta que se cumplan los criterios. Lo que no se pueda verificar debe declararse abiertamente. Donde existe una métrica de éxito objetiva, los agentes siguen trabajando hasta alcanzarla. Así, la primera mirada del usuario nunca es la primera mirada del modelo, es su cuarta o quinta.

En resumen, el panorama es nítido: guardar el código probado, hacer que cada habilidad sea descubrible con una descripción precisa, convertir las correcciones en instrucciones duraderas, verificar con evidencias antes de entregar. Juntas, las cuatro reglas convierten un agente polivalente en un asistente que sabe cómo trabajo yo. Esa es también la frase de cierre del vídeo: no construyas el agente, sino cómo el agente trabaja para ti.

También corresponde algo de contexto: Agent Skills se anunció en octubre de 2025 para Claude Code, se explicó mediante un ejemplo real como la edición de PDF, y se compartió en un repositorio público. El concepto se extendió a otras plataformas, incluido Codex. Así que el vídeo no describe la idea de un solo canal, sino un patrón que se convirtió en práctica de la industria en cuestión de meses, con las cuatro reglas como su forma destilada.